They're cached: when you update a Postprocessor without touching CSS, that doesn't dirty the caches, so this server still has a cached version of my old colors. It'll fix itself eventually, but I can look at making it smarter.

But I do not understand the reasoning for having such arcane and basically useless metadata for maniphest transactions.

This change isn't useful for the upstream, and isn't the direction we intend to pursue. See discussion here:

You can "Edit Revision" and remove the user as a reviewer to override their block (you can move them to CC at the same time to avoid kicking them off the revision entirely). This is a strong action, but overriding their rejection is also strong.

Thanks. If this workaround doesn't work for anyone, let me know.

I just hit this again and am not sure what's causing it.

I think that patch fixes this, can someone who has a repro verify that it works for them? You can apply it with arc patch D13417 in libphutil/.

It looks like this has been reported to the cURL upstream in slightly different form already:

Yeah, they're functionally identical.

See also T7449.

Seems like the core is in at least roughly in a good place, now.

IMPORTANT: This feature is new, experimental, and not supported. Use it at your own risk.

(This is a bulk edit test.)

This now exists after T8637, but has various missing features and hasn't been adapted for other use cases mentioned here yet.

I have this working functionally, but the UI is still an atrocious mess. Probably have something ready tomorrow.

See also some discussion in T7804.

Development Log

Development Log

Concrete stuff here is probably something like this (this might not be the optimal order):

iPhone developers will also understand the annoyance of seeing the massive and often irrelevant project.pbxproj appear before source files in the diff.

This would be complex to implement (sorting isn't, per se, but proper implementation which consistently extends to Differential, Diffusion, Owners, arc, etc.) and this use case doesn't seem very strong (the behavior is obvious, there's a table of contents and a scrollbar, there's no particular reason not to review tests first, etc.).

After mulling this over for a bit while dealing with other stuff, I'm pretty convinced that the general purpose infrastructure in T5166 is the way forward here, so my plan is to move forward with that.

This appears to work to undo a status change batch edit:

• Define a recipient address for each team in Applications → Maniphest → Help/Options → Edit Application Emails. For example, frontend-bugs@phabricator.mycompany.com and backend-bugs@phabricator.mycompany.com. For example, here are five different receiving addresses:

There's now a generic "note" credential type which lets you store a big chunk of secret text.

Feeling pretty confident that T6860 was a really bad idea, so I threw it away; my current plan is to do T5135 instead, as described above.

It seems increasingly clear that T6860 was a really bad idea. New pathway forward here is completely straightforward:

We basically have two actual use cases in the wild here: