Tech changes out of T9132 (see also T9905) put this on a relatively short timetable and this stuff is no longer active on the major edit workflows so I'm going to land T9860. We probably won't cut a stable this week, and will continue issuing guidance on upgrading smoothly through these changes.

Specifically, the rule is that the lesser of:

I couldn't include F1018337 in the original post?

Additional errata:

"Create Subtask" is a shortcut for "Create Task, then add it as a blocker for this one".

T7661 is also similar.

Actually, that report is already fixed.

Actually, that report is already fixed. For completeness, the behavior adapters should have is:

See also T7961, which is another modular behavior adapters should have.

• You can now technically write this as an extension by extending HeraldAction, although mail is quite complicated and this extension may be challenging to write.
• You could use an extension like the one in P1895 to add a comment instead, although I think this will be caught by notification preferences.
• You can use the action above (reject commit unless they bypass).
• You could use "Add Projects" and then just manually email the offenders who got hit at the end of the week to warn them.

Offhand, I'm inclined to still publish "Herald closed the task." in the "subscribe + close" hypothetical, which I think is the current behavior.

This behavior is "correct" in some sense (Herald really did perform the "strongest" action in the transaction group) but the sorting on tiebreakers is likely wrong (see D14680 for a similar case) and we should sort actions by real users over actions by Herald at the same strength.

The build for Dyyyy should not fail. They do not fail in the upstream.

Related, the test console has a big if ($x instanceof ...) mess that should be pushed down into Adapters. A reasonable flow might be:

The new tools from T9132 are now in HEAD (see D14718 for documentation, which will land shortly).

Broadly, if comments have the new "stacked action" UI (an "Add Action..." dropdown, allowing you to take multiple actions at once), the expectation is that they support the new drafts too. This includes Maniphest at HEAD.

I can't reproduce this issue by following the steps in the report:

These unit tests take a while. I'll run it on the final revision

(See general churn in T9905, T9908, T9132.)

Oh -- are you creating these from the workboard? Never mind, in that case.

I don't understand the difference between this and T9936. Aren't they aiming to solve the same problem (difficulty remembering what failed during arc diff when running arc land)?

The expectation is that you'll remember what the issue was, since arc diff printed the specific problems earlier and you already explicitly confirmed that you wanted to continue despite the issues.

As a workaround, you might be able to put aliases in /etc/arcconfig (e.g., symlink that to something which is version controlled) and use ~/.arcconfig for credentials only.

After "thinking carefully" about this I am going to do the lazy / less bold approach and we can sort it out later so you can have this back. :3

("Not really." in the sense of "I don't have anything in mind" -- I agree that it might feel weird.)

Not really. I was going to do this:

I'm going to try to bludgeon this in for EditEngine, we can refine it in Projects v3 if I ham it up.

I think D14016 actually fixed this?

I don't plan to implement this. We haven't seen other interest in it and your use case seems fairly unusual.

See Contributing Feature Requests for help writing a feature request.

Do you have a meaningful amount of configuration in your ~/.arcrc?

(If your time is valuable, we're happy to shoulder the entire burden of building a reproduction case and fish around for environmental problems at our consulting rate; see Consulting.)

Or, let me clarify: if you give us a running VM in EC2 with root credentials, that's useful.

If I could provide a virtual machine image of some sort that shows the issue, would that be useful?

When submitting a feature request, please describe the root problem you are trying to solve. See Contributing Feature Requests.

Can you provide more details on exactly how this is a bug?

This does not describe a bug with Phabricator. For help filing a bug, see Contributing Bug Reports.

So - a technical team lead would encounter this.

I don't think any of those actually specify the favicon... what does this return (with the right domain)?

Are there any more details that might be useful?