Having to use SQL to change ownership, then delete them, is a crappy workflow

Phab admins don't have SQL access so that's not the workflow either foar admins.
sudo /srv/phab/phabricator/bin/remove destroy F12345678 on iridium is, but that is unrelated to being an admin. Proposing to close this task as invalid.

In T168182#3357883, @Aklapper wrote:

Having to use SQL to change ownership, then delete them, is a crappy workflow

Phab admins don't have SQL access so that's not the workflow either foar admins.
sudo /srv/phab/phabricator/bin/remove destroy F12345678 on iridium is, but that is unrelated to being an admin. Proposing to close this task as invalid.

That's the workflow being used by some opsen, presumably due to them not being aware of other options

That aside, having to do it on shell at all is crap, and plain stupid

This should be reported upstream, It is a valid idea that would link well to their push for anti-spam work they were doing not too long ago.

I'm relatively sure that upstream isn't planning to make deletion possible via the web. The reason it's done via CLI is to prevent the possibility of destroying data. In our case it probably makes sense for admins to be able to delete certain things. When dealing with a major spam/abuse incident, however, the CLI is the most efficient way to implement countermeasures and cleanup work.

We can build some custom tools, as well. We don't have to follow the same data retention policies as upstream dictates.

Can't we "force hide" the files like MediaWiki does upon deletion?

In T168182#3358031, @Reedy wrote:

That aside, having to do it on shell at all is crap, and plain stupid

I feel the same and I've proposed the same for Pastes. Sorry for my ignorance but IMHO it is more risky to use CLI or direct db access to delete something than to hit a web button. A misconfigured CLI command can wipe out the entire Phabricator, a "delete" button on files deletes that file only.

I think @mmodell is correct that maybe we should think on something for our own use rather than to force all Phabricator installs elsewhere to adapt to our model. Thanks.

In T168182#3479492, @MarcoAurelio wrote:

A misconfigured CLI command can wipe out the entire Phabricator, a "delete" button on files deletes that file only.

For clarification, I might share the perspective/attitude but not the argumentation. Running sudo /srv/phab/phabricator/bin/remove destroy is far away from running sudo rm -rf / and the parameters allowed to pass to the first command are a restricted list.

Recently (in relation to dealing with WP0 abuse) I've been dreaming of a "when disabling this Phab user account, also delete all of their file uploads" checkbox though.

@Aklapper: I could probably make a tool which manually deletes all files associated with a given account, that we can run from the CLI at least. Building a GUI for it might be overkill I think?

I'm also not apposed to giving phabricator admins a way to do this form the GUI, however, that will be more work to implement.

In T168182#3487481, @mmodell wrote:

@Aklapper: Building a GUI for it might be overkill I think?

Indeed.

I could probably make a tool which manually deletes all files associated with a given account, that we can run from the CLI at least.

Yeah. But as long as Gerrit patch #368775 remains deployed and no new issues show up you shall not spend any time on this. :)

Well, if (when) it becomes a problem (again), we can do a rough estimate based on https://xkcd.com/1205/ and then decide how to proceed ;)

Just bookkeeping -- this is upstream as https://secure.phabricator.com/T7593.

I briefly toyed with a "banish" operation (see https://secure.phabricator.com/D19933) that meant "this user is bad, disable them and hide all their content", but it felt un-ripe at the time.

@epriestley: I've implemented something similar in RollbackTransactionsWorkflow which is actually quite thorough - it reverses each transaction for a given user.

It does not address this task, however.

EDIT: actually it's nothing like the code in https://secure.phabricator.com/D19933 heh