Why not require GD outright? Seems like a drop in the bucket with all other requirements and leads to confusion later like with projects or macros

I think the NUX case is fairly tricky. I need to look at the code, but I'm thinking something like:

I think you can use imagecolorallocatealpha($img, $r, $g, $b, $a) to do it for you. Note that alpha is 0-255, not 0-1.

If it's not simple, I can probably fake border colors with builtin colors we use.

I'm fumbling with GD, I did try solid color borders, which work fine, but are overkill (millions of options). I wanted to go back to RGBA, but not finding a good reference on converting rgba(255,255,255,.4); into a GD friendly color.

I'm going to get this to being able to build a real file, and hand it over unless you think the rest is trivial. Not sure how this would need to work in the NUX case. Generate an image when PhabricatorUser is triggered? What about old defaults?

crc32 would be fine in this use case too since the requirements are so lax. My version isn't particularly robust either, but should get the job done.

Works great!

Oh is crc32 bad?

Actually, may have found something on "the google". bbs

Since I'm not a real programmer, getting stuck on how to assign something by username. I presume we want every chad to get the same pre-built avatar if possible. I could just randomize it, but that seems not really beneficial.

Ok, first part is checked in and seems reasonable. https://secure.phabricator.com/uiexample/view/PhabricatorFilesComposeAvatarExample/

It looks like we currently allow usernames to begin with _, ., and - (PhabricatorUser->validateUsername()), but maybe just do a ? for anything-except-numbers-and-letters?

A-Z and 0-9 is all we need here? Gotta remember user @0

It'd look something like this:

Honestly I'm fine with 6600 uniques out of the box. I think beyond that people can update their image. Mostly I'd like it for individual conversations (tasks with newbies), so I don't expect collision in those cases.

Googling around I can find programmatically generated lists of 256 colors x 26 letters = 6600. We can also make background shapes. 4,5,6,7,8 sided. This would give us 33k uniques.

We can draw letters in GD, but I suspect they won't look very good compared to letters from Photoshop (bad antialiasing, limited font choices, weird alignment/kerning issues), so I'd guess it's not worth bothering and we might as well just jump straight to using generated images like Projects.

Shapes x Colors x Letters seems most clear, but will have some collisions. I can mock something up. The letters would be generated images like in Projects? Or can this be all GD? I think that assumes fonts.

I think D17374 covered everything I wanted to cover.

This has been implemented and in use for a while, so closing and will finish up smaller tasks in backlog.

Thanks! I believe I broke this in D15165, a little more than a year ago.

I understand bot users don't get email but I totally mis-typed one and I realized it "too late" and would love to be able to change it even if it doesn't really matter

This isn't a bug. Here's an example of why the proposed behavior is dangerous:

I'm going to merge this into T11357. We can provide a "Delete File Data" transaction type when we implement a third-generation file.edit API.

This is working as intended, and not a bug. Administrators can not bypass policies. See the User Guide: Account Roles documentation:

This was filed a while ago, but it's not clear to me why this is useful -- no obvious reason to want to do this springs to mind.

Just as a note: I had this happen again on another very low-power instance (same file storage backend, encryption enabled etc), but with the latest HEAD, simply reloading with Ctrl+R after the webserver timed out the request made it continue and work perfectly. So yes, this is fixed it seems.

D16271 probably either fixes or moots this.

I can't really reproduce this, exactly, I think (?), but I suspect I can fix this and T8124 by just making this code simpler.

In T11307#185338, @epriestley wrote:

T10907 is also sort of adjacent.

T10907 is also sort of adjacent.

Yeah, T8124 is definitely the error user-facing I saw when this occurred, except there's no possible way to edit your profile pic at that point as the exception takes up the whole page.

T8124 is probably adjacent.

What I found interesting about this bug is, I've had some obvious high latency with this storage engine - but incremental storage uploads for large files work fantastic in every use case I've tried, e.g. cancelling requests and all kinds of stuff. I guess this 'magical' default profile picture creation can't use the 'resume upload' mechanics?

No problem, thanks for the followup!

@epriestley - this is caused by a downstream patch which intentionally excludes sprints from the displayed groups.

Will try to get more details for you from colleagues.

I can't reproduce this. Here's what I did:

Just found another account disabled couple days ago which also says that doesn't belong to any projects, but some projects list him as a member. So the issue is in current version still present.

Appears resolved and accounted for.

These changes are live on this install:

After D15959, user.search should support "find all non-disabled human users", likely with parameters in this vein:

I think T5953 is a better fit for that in the upstream.

FWIW is something like user.edit on the table? We'd like to be able to pre-create users with specific information such as 'real name', and a particular external account linked.

To further elaborate:

To install:

Alright, let me sketch out the "missing X account" thing.

For the "you don't have external account X linked", it might be easiest to just fork and implement it as an extension that pops a notification bubble? I can give you an outline of how to do this, but I don't think there's really much to gain by providing a formal extension point since you just need a one-liner in PhabricatorStandardPageView, fork-wise. The downside to this approach is that you could only dismiss it by linking an account (dismissal of the HTTPS warning would be impossible, and dismissal of the timezone warning would not be generic), but maybe that's fine.

Maybe a good way to attack this is to discuss specific notifications. I think the use cases we're aware of are:

Yes - my comments were meandering in nature. Sorry, should have made that
clear.

Our main interest has to do with "please fix your timezone" and "please link your external accounts". That is, action oriented, high priority, requests. The FYI or MOTD style prompts are secondary.

This should realistically wait until the we get rid of the old default homepage and everything is driven through dashboards.

Something somewhat related potentially depending on the implementation you'd imagine is "bulletins". Where you have a user base, and as the operator of the system you want to communicate something to folks in the tool where it's relevant (for example, to aid discovery of a new feature that was added that we think people want to use, or strongly suggest a best practice etc).

The driving use case for this fell through, and I no longer plan to pursue it.