I discussed the WMF situation in particular in more detail with @rush898 on IRC, and it looks like T6211 is a good path forward for the "security" case.

In T6207#77543, @epriestley wrote:

Today:

• Users with access to the Phabricator host can destroy the rule with bin/remove destroy Hxxx.
• You can deactivate the rule by disabling the user's account.

How about this:

We're unlikely to expand the role of administrative power here, administrators intentionally have very little power. See:

Any update on this? @20after4 are you still working on this?

There's no technical barrier to implementing this, it just won't work some of the time since we don't have the context. I'm generally a bit skeptical about the value of these rules, but reasonable use cases aren't totally unthinkable. T5029 may make it practical more of the time.

Correct.

We already have "Commit is a merge" for pre-commit. But I think you wanted it for post-commit?

Closed by commit rP2f4addc67113.

◀ Merged tasks: T6030.

✘ Merged into T4754.

◀ Merged tasks: T6025.

◀ Merged tasks: T5983.

✘ Merged into T5274.

The rule should identify closed revisions:

It does, but the revision is already in a closed status, so it doesn't count when performing the rule (or at least it didn't when we started using it). The exact sequence is something like this:

Does the cherry-pick not have "Differential Revision: ..." in the commit message?

It'd be nice if this could detect based on the commit content (hashing it), rather than explicitly only allowing one commit per accepted revision.

Let's make this check the state the revision had before we acted on it:

◀ Merged tasks: T4897.

✘ Merged into T5854.

Thanks, we'll try it.

This should be fixed by 0b5fcb3 (Jul 26), which came a few days after the version you upgraded to (Jul 21). If you upgrade past that and still have issues, let us know.

If needed, I'll hang around in #phabricator during central European working hours.

I realize I'm still missing a piece: I thought you could do that in Herald but apparently not: adding a comment to a task when a rule matches. This would be needed to not just blindly re-assign the task to the author but also add some context.

Very interesting, thanks much @epriestley.

You should also be able to put #project in the email body now I think, but that's not really the same use case.

Tentatively, my plan for this is just to let you set several "bugs" addresses, and then use Herald rules to do all the routing. We already have "is newly created" and "content source", so we'd just have to add "receiving email address", and then you could write a rule like:

This can be built as a custom Herald action (which will eventually be documented; see T5194). Drop this in src/extensions/ and then the "Reassign to author" action should be available in "Global" Maniphest Herald rules.

• Maniphest projects should work now.
• Maniphest CCs won't work until T5604.
• Diffusion is mostly updated but the initial interaction still isn't (T4896).
• Haven't touched Pholio, this is still an easy fix that we just haven't gotten around to.

Couldn't you just have "Always" as default then? Not having to do an extra action is always better than forcing your users to do so.

Use an "Always" condition.