Got it, thanks for clarifying.

It looks like these triggers don't run when you move tasks via "Move on Workboard" (instead of drag and drop). Is this expected / intentional?

It looks like these triggers don't run when you move tasks via "Move on Workboard" (instead of drag and drop).

PHI1224 describes a somewhat-adjacent situation: an install would like a way for external automated tooling to reference source files and generate editor links for them.

PHI1231 would like API access to coverage.

My expectation is that this is effectively resolved by T13277. Since "Autoclose" is no longer a separate permission from "Publish", commits should now always mention + close or never mention + close.

The actual facts Maniphest currently generates need to be adjusted to properly support stacked-area-by-reason: currently, when a task is closed, we don't have enough data to figure out whether it should be removed from the "created into this project" area, the "reopened work" area, or the "moved work" area.

One issue with model we're evolving toward is that if you view a chart in Klingon, then send the link to a user whose primary language is Kerbal, we'd prefer to relabel the chart in Kerbal, not restore serialized Klingon-language chart labels. That means label generation has to be at render time, not at chart construction time, and I'm serializing a data-structure which is slightly too low-level for common application cases.

This is a little ways out, but the actual facts Maniphest currently generates need to be adjusted to properly support stacked-area-by-reason: currently, when a task is closed, we don't have enough data to figure out whether it should be removed from the "created into this project" area, the "reopened work" area, or the "moved work" area. This is okay if we're summing the opens/closes but not precise enough if we're breaking them down.

Probably, push another commit to Y

Multiple Project Burnups Stacked in an Area Chart

See also PHI1226. An install has an environment where automatic rules (Herald/Owners) frequently trigger group reviewers (projects/packages), and some groups are not prompt about performing review.

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.

I think a possible model for the UI is to have some base ChartConfigurationEngine, similar to SearchEngine, which defines a set of fields. Some fields would be common (e.g., all time-series charts can have time controls for domains).

The concrete use cases that are currently filed are:

This is approximately coming into existence and this task no longer serves much of a purpose. See T13083 / T13279 for followups.

This now approximately exists and is no longer of much use as a standalone task. See T13279 and elsewhere for followups.

hmmm

Wow thank you for this. I came across a diff that mixed a lot of whitespace with minimal code change it's much easier to differentiate what happened.

The complexity of handling this makes adding a "the whole repository is caught up, deal with it" from T4453#13 sort of step more attractive. This would be far easier to motivate if we had more stuff that suffered from similar issues, though.

I believe this was resolved by D20327 / D20393.

I believe this has been fixed by D20327 / D20393 -- at least, the examples above no longer seem to reproduce any bad behavior.