The only other field which seems possibly useful here is "Name", but I can't really come up with any reasons why you'd ever want to do something when, e.g., a rule's name matches some regexp.

I'm going to tentatively put this (the Phriction rule, specifically) into T13130 for this week although I'm not sure how much work getting getDefaultPolicyForObject() to return the root document policy is and maybe that's Unbelievably Difficult. Let me take a quick look at that and you can either run with it or I can pick it up if it's some kind of weird arcana.

• Fix "a another".
• Remove stray "phlog()".

Ah, yeah. No idea why I typed "blind" instead.

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

Offhand, two possible issues with that:

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.

I didn't catch anything substantive beyond the typo @amckinley caught.

Incidentally, the first page shown after the install

I do sort of like the ring of "confuguring".

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.

Oh, no problem.

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.

I can't come up with any other ways to break this.

I think this reattaches the bindings to the interface we delete, not the actual survivor? Maybe I'm crazy but:

Definitely OK to just make the rows as-correct-as-possible without writing transactions for them.

I haven't run into that LOCK TABLE thing before, but some googling suggests that maybe you need to be using raw queryfx() stuff on the same $conn? I'd normally expect the existing w mode $conn to get reused (since we can use a 'w' conn for 'r'), but maybe that isn't actually what happens today.

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.