Ref T10319. This adds a basic means of generating default profile images for users. You can generate them for everyone, a group of users, or force updates. This only generated images and stores them in files. It does not assign them to users.
Details
Details
- Reviewers
epriestley - Maniphest Tasks
- T10319: Generate unique? profile images for each new user
- Commits
- rP3a868940c759: Add a profileimage generation workflow for the cli
bin/people profileimage --all to generate all images.
bin/people profileimage --users chad to generate a user.
bin/people profileimage --all --force to force rebuilding all images.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| scripts/people/manage_people.php | ||
|---|---|---|
| 9–12 | Since we'll probably add more stuff, maybe make this help text generic: "Manage user profiles and accounts" or similar. | |
| src/applications/people/management/PhabricatorPeopleManagementWorkflow.php | ||
| 32 | Ideally, make sure that we loaded a user for each username. As written, I think profileimage alinkern bartty claire will "work": as long as you provide at least one valid username, we'll just ignore the invalid ones. Better would be to fatal explicitly before doing anything: "user alinkern is not a valid user". | |
| src/applications/people/management/PhabricatorPeopleProfileImageWorkflow.php | ||
| 10 | Maybe **profileimage** --user __username__ or similar since running it without arguments doesn't work so it isn't a great example? | |
| 14–18 | I think this is unused / doesn't work? | |
| 66 | I think it would be OK to auto-regenerate if the version was old, too. | |
| 73–77 | For consistency, prefer to format messages as full sentences (with punctuation) and quote parameters/usernames/etc where reasonable: - Generating profile image for %s + Generating profile image for "%s". | |
| 78–83 | I don't think this is possible -- getUserProfileImageFile() always throws on error and never returns null, I believe? | |
| src/applications/people/management/PhabricatorPeopleProfileImageWorkflow.php | ||
|---|---|---|
| 66 | Oh, I thought maybe we didn't want to force people to get a new image if we alter the formula? | |
Comment Actions
Hmm, I guess we could go either way. I could see people liking their v1 images (or missing them if we overwrite them).
If we don't think we'll ever force-upgrade we could drop the version thing entirely, my thinking was just that we've doubled the size of images every ~6 months so they'll probably be 9600x9600 soon and we might want to force-upgrade the old blurry ones.
Comment Actions
force-upgrade
Er, "auto-upgrade" I guess. If we probably wouldn't automatically rebuild default images for users (for example, when we make them bigger or tweak colors) we don't need the version stuff at all.
If we use the version stuff in the generate-at-Query-time logic we should probably use it here too, though, so that administrators can do that work ahead of time and avoid slow pages.