I believe the above changes covered everything, and there hasn't been any more action on the motivating customer issues, although this isn't terribly meaningful.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 20 2022
This is resolved and/or mooted.
Mar 4 2021
I dug up another one of these in PHI1439, but there is a lot of text in that issue that I haven't re-read yet.
Feb 19 2021
A minimal implementation here is probably:
Feb 18 2021
Feb 17 2021
Feb 5 2021
Jan 26 2021
It looks like the case in PHI1977 was actually a situation of attempting to trigger an audit by writing a Differential rule, so the Global/Personal stuff may still be worth fixing but has zero known cases of actual confusion in the wild. I'm less sure how the UI could be clarified around the Audit/Differential issue.
Jan 20 2021
See PHI1977 for a somewhat-similar issue: a user was (probably) looking for an action available only in Global Herald rules, and didn't realize available actions depend on rule scope.
Nov 7 2020
The profiling in D20566 seems satisfactory, and has been useful in resolving or understanding a few performance-related issues.
Oct 16 2020
May 20 2020
Feb 3 2020
Jan 29 2020
Jan 24 2020
Jan 23 2020
Remaining work:
D20947 does not implement "Author's packages" as a "Commit Content" field, nor as a "Commit Content (Hook)" field. The reason for this is that getting the modern authorPHID in both cases is somewhat complicated.
Jan 21 2020
Jan 17 2020
Jan 15 2020
This should be fixed by D20943. Note that "Mute" in this context mutes notifications about edits to the object (e.g. "Alice renamed rule Hxxx from X to Y."), not notifications sent by the rule itself.
Nov 6 2019
Sep 25 2019
Sep 12 2019
D20808 fixes the two original cases (Harbormaster and Legalpad). There are probably more fields or actions which could be configured to be sometimes-unavailable, but these are probably the major ones.
Sep 11 2019
I understand this was supposed to be mentioned here: Herald ignores commits that are ancestors of permanent refs if they were previously pushed to some other non-permanent ref.
Sep 9 2019
0.00000000001 is very funny and we would be losing a truly great joke at such a young age
May 31 2019
May 27 2019
A sort of broad issue here is that Herald sometimes knows (or could know, or could guess, or maybe could speculate) that a rule won't do what you expect, but it doesn't tell you.
I think this is about as good as we're going to get, and we've only taken a very small step toward the precipice of a self-aware Herald that hates humankind.
KDE appears to be moving to GitLab (see: https://gitlab.com/gitlab-org/gitlab-ce/issues/53206) and we haven't seen this request from other installs, so I'm just going to close this out.
I think the modern answer here is "use Webhooks". They may not do everything you want if you're writing a chat bot (notably, they intentionally do not currently provide a human-readable text representation of transactions) but there generally suitable for publishing changes to Phabricator objects into a remote system and will produce a program with generally reasonable behaviors and no weird demons lurking under the surface.
May 22 2019
Currently, I think the primary transactions and transactions triggered by Herald are getting different group IDs. They should be the same group ID, e.g. all these transactions should be in the same "group" for the purposes of collecting transactions into effect groups:
May 17 2019
This stuff is largely resolved, but survived by a few remaining issues in T13290.
May 16 2019
May 13 2019
pass the applied transactions to Herald
May 3 2019
See PHI1107, which requests Auto-Abandon for old changes and also has a technical outline for this great and wholesome feature.
The answer here is now pretty unambiguously "Use Webhooks". feed.http-hooks is formally deprecated, Herald remains a terrible idea, and anyone brave enough to touch Doorkeeper can probably figure things out for themselves.
We don't have any current customer interest in this as far as I'm aware. We could revisit this in the future, but I'd like better / more modern use cases (e.g., that aren't addressed by an approach with Owners).
Although I'm not entirely confident that 100% of objects which should implement ExtendedPolicyInterface actually do today, I think we've gotten pretty much all of them. This approach also seems stable.
I don't believe there are remaining outstanding requests for this.
Owners review and auditing now have 6 and 4 options respectively, which I think cover most of the needs here. They don't handle everything (e.g. excluding merge commits) but think we're mostly in a reasonable place now and don't have any current plans to add additional shorthands.
May 1 2019
Apr 23 2019
In PHI1008, when commit X reverts commit Y, we don't write a revert edge between X and revisions associated with Y. We should.