D20427 is a similar change, that deprecates the "Commit is on autoclose branch" field. This fields is now always true by definition, because Herald does not run until a commit is reachable from a permanent ref (previously called an "autoclose branch").

This is effectively mooted by changes in T13277.

I think this is effectively resolved by T13277.

Internally, see PHI1165 for nine pages of me complaining about this.

I think this is more or less at the end of the line in terms of actionable work that doesn't make more sense being scoped in elsewhere.

Currently, the SES adapter extends from the Sendmail (PHPMailerLite) adapter. I'd like to fix this.

Currently, the SES adapter extends from the Sendmail (PHPMailerLite) adapter. I'd like to fix this.

As tends to be par for the course, this is turning into a bit of a rabbit hole.

I'm considering pushing this forward since MFA is getting an update (see T13231 and adjacent tasks).

With D11419 implemented, is it possible to now allow Herald rules to be triggered on a cron (even a very simple 'daily' option would be good)?

The root use case here was a desire for a better sense of how often certain rules were firing, and we improved the push logs instead to address this more directly (D19555, D19556, D19557).

On SMS MFA, Reddit got bitten recently by SMS having poor security properties:

I'm going to look at improving the push logs a bit to show which rule blocked a push to address the actual use case in PHI765, which makes this more of a distance nice-to-have.

I think the following change to src/applications/herald/controller/HeraldRuleController.php line 672 (as of 185c28f307e4) should provide an immediate improvement to at least indicate that they are different rules:

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.

Okay. For the sake of 100% clarity it would be nice if the timeline story did show why the action was taken as it isn't immediately clear (unless you've read the documentation of course) why it was removed.

I'll make a note on T12455, but we might be able to render this timeline story more clearly, e.g. "X added project Y (which automatically removed Z, a subproject)" but I think this is likely fairly natural/obvious in most cases and I'm not sure if it's trivial to completely explain in the timeline.

Ah, that would certainly explain it. Sorry for the noise - when entering this I did wonder if I had missed something as it didn't make sense that a name collision would be able to cause this.

"Plasma on Wayland" is a subproject of "Plasma".

Sorry, the only way to influence feature development is through a support pact. See also Planning.

@epriestley Would you guys be open for a patch for this? How would you like to see this implemented in order to be acceptable for you guys?

This is quite old and I have no idea how to reproduce it and thus no idea how to fix it. Locally, I tried a few things and wasn't able to identify a case where the Herald field value differed from my actual project list.

Rename the field to "Reviewer (Legacy)", or move it to a "Legacy" category -- maybe improves things, but really just punts this.