In D20927, I implemented a policy rule like this:

./bin/user create

You can automate at least some administrative actions...

(You can automate at least some administrative actions at an "omnipotent" power level with bin/conduit call --method user.edit nowadays, too, although accountadmin operated with interactive prompts so it's unlikely anyone automated on top of it.)

From T13222, MFA on related flows should generally be updated.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

$table = new PhabricatorUser();
$cache_path = 'progress.json';

I just deleted the users above and am backing away from D19933, at least for now, since it doesn't feel like an especially great fit for either secure or admin.

On admin, basically every user with a blurb is abusive. I've just disabled the field as a coarse reaction.

I'm planning to banish these users from secure. This is mostly: polish (?) SEO bots; printer fax spam; and "security researchers":

A couple of narrow ideas here:

I don't currently plan to make "Disable User" any more granular than it is. If you have a use case where you want multiple administrator levels and to allow administrators at a certain level to act downward but not upward, you might be able to do something like have an enforcer-bot account which users can instruct to disable one another. The enforcer-bot itself could act via the API.

In T9041#240610, @epriestley wrote:

"Disable User", specifically, is now granular.

"Disable User", specifically, is now granular.

I made this public since I've disclosed/discussed this elsewhere, including an indirect reference in the Spaces documentation, and I'm going to schedule it alongside some other stuff.

As @avivey suggests, the remaining cache can be cleared with:

You need to clear some caches too - ./bin/cache purge - but I'm not sure which; And then hard-refresh the in the browser.

Another variation of this is that "Mailing List" users' addresses also can't be edited from the web UI.

Thanks, I'll just keep an eye on this ticket and switch whenever I need to.

Right, you can't user.search for the currently logged-in viewer. If you don't need to know this (you already know the right username or PHID) and were just using user.whoami for convenience you could switch today, but, e.g., in arc we rely on identifying the logged-in viewer with a Conduit call.

I assume based on your comment there isn't a good replacement for whoami until viewer is available on search? (aka I'll keep using whoami until viewer is available as an input to search)

Behavior above sound right? I'll shoot you a diff...

not intentional

Actually, I misread D17678, which just replaced the grey dot with a violet dot in all cases.

I think it does, but only if you ever don't have a profile picture:

Wasn't this supposed to show up as an option in "Edit Profile Picture"?

You can adjust it if you like at https://secure.phabricator.com/source/phabricator/browse/master/src/applications/files/builtin/PhabricatorFilesComposeAvatarBuiltinFile.php;7626ec0ce10e5a9665d84622259e073744c9872d$130

This would be totally great, if our corporate username policy didn't mandate that all usernames start with the same letter 😂

Beautiful and timely fix. Thanks!

True story, I built these because of @jmeador

I dropped the cache, looks like they're working.

I presume these will pop in as cache expires?

rolling.

🍞 🐦

fancy 👑

I think bin/cache purge --purge-user will do it (but for every user). There's no way to do it for just one user, I don't think.

is there a simple way to reset the cache?

Something like:

I have a bad version that makes a file the first time getDefaultPictureURI is called and one doesn't exist. But it uses unguarded writes and feels hacky,

@epriestley not sure what I need to do next here on this or D17430

Yeah everywhere I look at doing this seems exceedingly hacky. Writing a profile image the first time PhabricatorUser->getDefaultPictureURI doesn't seem right, but I don't seen any other lazy way of doing this outside of user creation.

In T10319#213871, @epriestley wrote:

• Generate the image in the Query, not when the user is created (helps with old users and not having to update a ton of different ways users can get created, and not generating these as side effects during unit tests).

In T10319#158305, @cburroughs wrote:

Yeah I think having some bin/profileimage script for pre-generation would be good for admins like here so you can pre-run the migration separate from enabling.

Yeah, I just want to find a way product side to always ensure good profile images are used. I'm fine having some fallback, if 100% needed, but it makes me really uncomfortable having different experiences or lessened experiences if avoidable.

(And, if our behavior is "confusing fatal", that could prevent new installs from getting far enough to even see the setup warning saying "install gd".)

I think all the other requirements are usually builtin (we "require" them only because it's possible to remove them, and some distros occasionally do for kind-of-maybe-questionable reasons) but I think it's basically like requiring your car to have tires.