The scenario in which this index would be needed is far from being normal. The patch D26027 that would benefit for it, is able to avoid that query in 99% of cases (it only needs such query when you want to destroy a profile picture, AND that picture was manually un-attached... why was it manually un-attached? by a spam click? by a faulty mouse?). So, the normal scenario is too small and unclear to justify a new index.

Again, expanding a PhabricatorFileAttachment to support a destruction engine to post-pone its destruction does NOT work as intended (as it's still destroyed very after the file) since the destroyObjectPermanently() is always supposed to be executed BEFORE the extensions.

OK I've explored the proposal n. 1 about expanding PhabricatorFileAttachment to support PhabricatorDestructibleInterface, but I'm just moving the problem there. The attachment is still immediately nuclearized BEFORE the extensions can do things.

When you destroy a PhabricatorFile, it seems this happens:

It seems it's necessary to be able to "get the user from a profile picture". This is not easy, since the user seems not mentioned in any obvious way from the file object, as already stated in T15407.

Plus, making the file editable by the author is the cure of T15814, so, moving that as parent task.

If we allow authors to destroy their images, we should also avoid 404 errors on them. So, the new subtask T16074.

Do you know for sure (did Fabio explicitly say so)

seems manually uploaded by an user, but it's not

This is different than T15814: Files: reduce number of orphan transformed files

Uhm this is a damn rabbit hole.

Trying the ManiphestTransactionEditor leads to a dead end. Added personal notes about it...

Uh I've found a workaround.

Ouch. Indeed my last comment had no sense. I was meaning T15941.

Ops I've closed this by mistake. We closed just T15564 👍

Can this be resolved? If not, what exactly is left in this task (apart from separate T15803)?

Ops I've closed this by mistake. We closed just T15564 👍

(Damn Phorge that auto-claims also for wontfix)

Maybe we can wontfix this. The current "workaround" D25485 by @waldyrious is just great and effectively fixed the super-confusing root problem.

As a general rule, I prefer the have the abstractions as much as possible, to allow extensions to do things.
In this case, an abstraction would also make this feature easier to enable/disable, which I think is desired.

Chris has asked me to pick this up as he'd like to see this implemented.

Ok, I'll improve it, because I still have a lot to learn about Phorge and its source code, otherwise I'll fix those issues myself

If there is an issue in Phorge then please provide steps to reproduce in Phorge. Please also strip unneeded full quotes which make comments hard to read. Thanks!

In T15056#21737, @danielyepezgarces wrote:

T391929 In that task on Wikimedia Phabricator, I had put some issues

Steps to reproduce the bug:

• Enable the "Dark Mode (Experimental)" theme in Wikimedia Phabricator.
• Go to the Phabricator Workboard.
• Click on any button that has a dropdown menu.

And with these steps you can see the error like the images I have attached

I just checked that the issue can be replicated in the Accessibility workboard, on the Affects-Wikimedia workboard it looks good