Oh, right. Sorry, I'm being totally unhelpful here and conflating priority and status.

I think we're also going to let you pick different icons, that's just blocked on me actually doing that.

I've also made a small foray against this in D14013, in Audit, which faces a similar set of problems:

This is desirable, but a bit involved, particularly in the cluster.

Here's an extension you can drop in src/extensions/. This is unsupported and the code is terrible, etc. This is purely intended to be a stopgap until we find a more permanent solution which is maintainable in the upstream.

Awesome! I'll see if we can clean up that login-error-state stuff soonish. Let us know if you run into anything else.

The model is that the excuse is for the lint/unit state of a given diff (an individual update on a revision), so it stays attached to that diff. If you fiddle with "Revision Update History", you should be able to find any previous excuse by diffing older diffs.

This is now deployed to the cluster and I've updated the configuration for your instance. You should be able to see the domain on your instance page, and the configuration change in the transaction log in case I spelled it wrong or something silly like that.

After T9297 / D14017 , it would be nice to do this:

There isn't really much of a workaround available at the moment, but I think we can get the feature deployed in some reasonable form by later today.

This isn't currently supported, but I think it's reasonable to implement. Behavior would roughly be something like this:

I pushed that to this server if you want to poke at it, let me know if I missed anything.

(Pretty sure this isn't related to T5263.)

I can't view those links and can't reproduce this locally:

This sort of exists in HEAD now, but with major limitations:

I also want to note the consideration that "good accuracy" + "simple ruleset" is probably a better default than "great accuracy" + "complex ruleset".

My 'useful' bar for email is "would I want to reply to this".
Does the user have to do something about this email?

You're also welcome to try pushing a large commit to this server (there should be writable test repositories available in Diffusion) to see if you can lock it up. If you can, it's likely that will give me enough information to understand and fix the underlying problem.

I'm not sure how to reproduce this. At HEAD at the time this was filed, the query UI looked like this:

Closing for lack of feedback.

Doesn't look like there's really much we can do here in the upstream which isn't filed elsewhere.

These things have been fixed:

This appears to be resolved. It's been in master for about a week without issues and deployed to the cluster for about 48 hours.

I haven't seen any issues related to this in the last couple of weeks. I suspect this affects <5 installs worldwide.

Some additional discussion in T8650.

We could make make not actually depend on the timestamps on those files, conceivably (only on whether they exist).

(A similar block in shouldHideForFeed() prevents these from publishing redundant feed stories, and stops the actual notifications.)

I think that the issue was that the timestamp on parser.yacc.hpp was older than the timestamp on parser.y. I'm not really sure how git handles timestamps but likely they aren't preserved.

Implementing this feature just involves deleting the code in PhabricatorApplicationTransaction->shouldHideForMail() which prevents these from sending mail.

What was getting cached that created an issue?

Closing for lack of feedback.

(For completeness.)

I don't plan to pursue this. I consider it highly desirable that users must explicitly grant permission to OAuth clients.

I guess git doesn't preserve timestamps... I just worked around this by running rm support/xhpast/* && git reset --hard HEAD && ./scripts/build_xhpast.php.

I expect to move this stuff into Locale subclasses eventually, but it's potentially performance-sensitive so I want to be careful when doing so.

(Happy to implement this if it is desirable for the upstream)