Page MenuHomePhabricator

Provide some way for administrators to remove/reset a user's profile image
Open, WishlistPublic


In Wikimedia Phabricator we sometimes experience vandalism (as our policies are pretty liberal).


  1. A Phab user uploads and sets an {offending | NSFW | copyrights/license violating} image as their Phab profile image.
  2. (Unrelated: I disable the user account via the web interface, due to the user's vandalism actions.)
  3. I ssh onto the Phab instance and run sudo ./phabricator/bin/remove destroy F11729470 to delete their uploaded image.
  4. I go to /file/query/all/ to also find the ID of the corresponding image called profile, created by Phab. (Slightly cumbersome, but okay.)
  5. I run sudo ./phabricator/bin/remove destroy F11729471 to delete the corresponding profile image.
  • Expected outcome:**

The image on the profile gets reset to some default fallback image, or displays nothing, or is broken, or... well, anything that makes their image not get displayed anymore in people's web browsers.

  • Actual outcome:**

The image is still displayed on the user profile and I don't know how to get it removed. Meh.

Event Timeline

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

At least, doing what you did plus that appears to break the image in my test.

epriestley triaged this task as Wishlist priority.EditedDec 13 2017, 1:30 PM
epriestley added a subscriber: epriestley.

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

$ ./bin/cache purge --caches user

In some other similar cases (where data is deleted manually from the CLI instead of via UI tools), you may need to purge other caches using this tool, most commonly the general or remarkup cache. It is broadly safe to just purge everything with bin/cache purge --all. At least today, all the caches this command purges are readthrough caches, so the worst outcome from purging too much stuff is a small performance cost while they rebuild.

(Also, you normally should not need to use sudo to execute bin/* commands, although it's possible that this is required in your environment. There isn't too much downside to using sudo, but if we have some terrible bug in some future version of Phabricator it might do a little more damage with sudo than without.)

Eventually, we should probably have real tools for quarantining, but (as elsewhere) this is very difficult to prioritize because it only affects open source installs.

In this particular case, the ideal flow would probably allow the edit itself to be quarantined into an approval queue. This implies a two-phase commit (user proposes a change, administrators approve it) for all edits against all objects. This is conceptually an enormous undertaking, although we could conceivably hold/serialize/store transactions instead of changing objects to exist in multiple states. See also T11440.