One option is to write "Herald Rules for Herald Rules".

Offhand, two possible issues with that:

See PHI251. This requests an "Ignore generated changes." option for Owners.

Historically, an issue with this was my hesitance to add more "Add Owner As Reviewer If Moon is Full" builtin rules to Owners: Herald already allows you to implement arbitrary rules with Owners, and an implementation of Herald where every possible rule is a dropdown option obviously isn't very good.

See PHI580. An install would like write API access to object relationships (depends on, fixes, etc). This is complicated, but perhaps plannable, and we may be able to put a reasonable facade with partial support into the upstream.

See PHI592. A diff with 600MB of videos required more than two hours to turn into an email patch, which exceeded the task lease duration and cascaded into various other kinds of problems.

See PHI285. An install would like a way to monitor changes to Herald rules.

See PHI251. This requests an "Ignore generated changes." option for Owners.

As a general update here since a couple installs are keeping an eye on it, I have a big chunk of the "use instance.state for everything" diff written, but some of the caching logic is tricky and I haven't had a solid chunk of uninterrupted time to stare at it in the last couple days so I don't expect to get it out in time for the release this week.

I'm happy to bring either change upstream if you want to do the legwork. We could also move them to a wiki page or something. No option here feels particularly good to me.

install_ubuntu.sh seems to be completely broken for modern Ubuntu. I don't mind updating it, but I think we discussed dumping it completely?

After D19384, we'll automatically mark these "phantom" notifications as read when you open the menu to review them:

D19384 cleans this up a little bit and mostly fixes the "phantom unread notification" issue in T8953.

The "Notification server not enabled" text should also link to the Aphlict documentation or something.

(These are in the menu.)

Alternatively, this can likely be fixed by creating edge tables for Phlux and adding them to PhluxSchemaSpec (which it looks like does not exist yet).

We should prrrrrrobably just delete Phlux.

I wholeheartedly embrace the latter ruleset. I also suspect that "a lot of 'All Users' documents and then some locked-down sections" is a common use-case, and the latter ruleset fits that use-case perfectly. I'll take a look at that when I get the chance.

Since Phriction policies are hierarchical, I think a dedicated setting probably doesn't make sense -- it would only effectively apply to creating the root document for the first time, at least in most cases.

See T13125 for a more detailed breakout of coverage plans.

See T13125 for coverage plans.

See T13125 for coverage plans. This is a pure feature request with no support mana backing it so I don't currently plan to pursue it.

A couple of things rolled forward into T13124.

@tycho.tatitscheff I have the same problem.
I tried to use /usr/bin/git-receive instead of /usr/lib/git-core/git-receive
Still the same.