See also some discussion in T7804.

(I lean toward "Recipe Book" instead of "Quick Create".)

T8682 describes another recipe, if [body][does not contain]['magic word'], [block commit] to let you create warnings/prompts when committing.

From T11878, these patterns aren't obvious:

• Write condition "(A and B) or C" by writing these rules:
  • Rule X: When all of: condition A, condition B; do nothing.
  • Rule Y: When any of: rule X, condition C; do stuff.
• Write "state A transitions to state B, being in state B does something" by writing these rules:
  • Rule X: When all of: object is in state A; move to state B.
  • Rule Y: When any of: rule X, object is in state B; do something.

From T12771:

Global Rule for Differential Diffs
When:
[ Repository ] [ does not exist ]
Take these actions:
[ Block diff with message ] [ "Repository unrecognized. See https://helpful-docs.com/repository-help for details." ]

See PHI242. SR Latch:

Set the latch:

When:
[ State is X ]
[ Flag Y is not set ]
Take actions:
[ Set flag Y ]
[ Cause side effect ]

Reset the latch:

When:
[ State is not X ]
Take actions:
[ Unset flag Y ]

This attempts to cause some side effect (send an email, add a comment, fire webhook) only when an object changes into a particular state, then stop sending email while the object remains in that state, then send another email if the object leaves and returns to that state later.

Today, the "flag" probably needs to be implemented with a dummy subscriber or a custom field. T12799 might add more options eventually. This use-case is wildly off-label.

See T7789 and D18827. Block Git LFS in some repositories:

When:
[ Commit uses Git LFS ] [ is true ]
[ Repository ] [ is not ] [ List of Repositories where LFS is Allowed ]
Take actions:
[ Block commit with message ] [ "Git LFS is not allowed in this repository." ]

Also, while it's on my mind, all repositories should probably have this rule today:

When
[ Change is enormous ] [ is true ]
Take actions:
[ Block commit with message ][ "This change is too large to be processed." ]

"Change is enormous" means we can not execute Herald rules on it because the diff text doesn't fit in memory (currently, more than 1GB of diff text or more than 15 minutes to pull the change out of the VCS).

We should probably make this a repository-level, default-off setting like "Allow Dangerous Changes" since this is currently something of an attack vector. For example, you can sneak LFS changes past the rule above (if it is acting alone) if you do this:

• Add an LFS object.
• Add a 1.5GB text file.
• Push the commit.

Herald will currently give up on processing this commit, so it won't be blocked by commit rules.

At least in theory, this isn't an especially realistic attack vector because an attacker needs to make a lot of "noise" to exploit it, but our defaults should be set up better. I'll file something specific about this.

See PHI612 and elsewhere; using "Take action [the first time this rule matches]" isn't always obvious but is usually a better fit than "When [ thing is created ]" and interacts much better with drafts.

See also PHI1987, which is another motivation for the "diffs with no revision" rule from T12771.