I'm not sure, since I'm not really sure what problem we're solving. It sounds like there are potentially three motivations:

Can you walk me through why you consider this to be a bug report rather than a feature request?

Sounds good. Current trajectory is:

what is this even

(I don't have any plans for making JS and PHP render from the same authority -- I don't see any realistic way to accomplish it.)

And, uh, SIMPLE is a color. I'm going to change that first, unless you have some other plan for having the yellow and non-yellow buttons present in the mock?

Okay. I have to port whatever we're using to PHUIX so you'll have to retouch both PHP and JS, but I can maybe put PHUIX rendering beside PHUI rendering in UIExamples to make that easier.

Are those buttons rendered by any existing class, or are they novel elements? The circular menus are presumably PHUIIconCircleView but the other buttons look custom (it looks like the spacing is slightly different from the existing "Simple" buttons, maybe)? Should I add a new mode to PHUIButtonView, or is this an existing mode somewhere that I'm just missing, or are they just "Simple" buttons with slightly Photoshoppy rendering?

If you believe this is not an issue with a bad SAPI binary, please file a new bug report including reproduction steps I can follow to reproduce the issue (see Providing Reproduction Steps for guidance).

I'm fine with dropping "no progress bars". I believe most requests we've ever received about inlines -- like T8909#224084 -- are fundamentally misguided. That user wanted features to make managing a review with 100 spelling corrections easier. But these requests are common and I don't have any real reason to believe that making Differential hard to misuse is actually helping anyone or putting any real pressure on attacking the root issues.

I think this feature is just inherently incompatible with my hardline "review shouldn't be a progress bar" view, and it would be more confusing to try to obscure the progress aspect of it.

I can also just put next/prev back on inlines if you prefer, and we can deal with the design issue if/when we add a context menu for "View History", "View Raw Remarkup", etc. (T11401).

I don't think we need to keep iterating here -- I don't think any version of this will ever be useful to me personally, and I think I'm clearly fighting a losing battle by trying to keep all the "X / Y" progress-bar-style elements out of the UI.

I think it's fine for none of this to work on mobile for now.

Okay, I'm going to implement these behaviors:

Oh! Works great in Chrome.

I deployed D18042 to secure, but it isn't retroactive. You can either:

Specifically, I got this (mail with HTML and text parts containing over-escaped HTML):

On top of this, I got some email from Pholio with odd HTML behavior, but I can't immediately reproduce it and I don't have any guesses about what's causing it so I'll assume I'm just crazy until someone else hits it.

(See also M1476.)

I've got most of a diff for this.

Probably permissions, let me see if I can reproduce locally. I thought I tested that but maybe didn't get the "replace an image" transaction specifically.

What I'm seeing, in Chrome?

What I'm seeing:

The first two images seem to have been lost, Pholio bug?

Next steps:

This doesn't appear to describe a bug in Phabricator.

I'm just going to nuke this since there's no repro. This workflow has also been rewritten on the experimental branch and the specific error encountered here should now be impossible.

See T12688#223690.

You should be able to use bin/config delete ui.footer-items --database to fix things.

I think we should probably not follow redirects from arc at all.

We've seen a couple of flavors of this from @swisspol, too. Although the symptom there is a little different (not a policy issue, exactly), the root cause is mostly similar. In particular, we saw:

(In this case, our behavior was strictly wrong, completely accidental, and trivial to fix -- but sooner or later we may make some kind of change which isn't very compatible with this older style of integration in a more fundamental way. When we do, a blog post from 2013 suggesting a set of workarounds at the time won't hold back the tides of change.)

The general story on Build/CI is this:

I think I didn't migrate this since there was no direct analog -- my memory's a little fuzzy, but I think the old query had some bugs / weird behaviors / general differences and there's no exact way to represent it after the change (and even if there was, the newer version -- with bucketing -- is probably way better for most users, so it's good to upgrade anyway). I figured it was better to just break it in an obvious way than subtly change it, which could be more confusing, I think.

I'm going to merge this into T9846 since I think they're the same, yell if it looks like I'm missing anything.

Here's an example of the old style:

Also, test agents probably shouldn't be accepting revisions at all. But ¯\_(ツ)_/¯

Note also that differential.revision.edit accepts IDs and harbormaster.createartifact allows you to create links to build results without needing to gum up the feed with comments. We will eventually remove differential.createcomment so things will need to update sooner or later.

This should be fixed in HEAD of master and stable. Thanks for the report!

That looks great to me.

Yeah, with whatever wrapping context maniphest.search has, so like:

That is, the specific error "use lists" is aimed at preventing is this:

The config also looks like this right now:

I guess we already have "keywords" and should probably accept any of them, too, so "!priority high" in mail, /priority high in a comment, and "high" in Conduit all work consistently even if the actual key is "elevated".

Ideally, we should maybe freeze maniphest.querystatuses (which has a sort of ridiculous output format, I think?) and provide maniphest.status.search and maniphest.priority.search, which return results similar to other modern *.search methods even if they aren't implemented quite the same way (at least make the output format similar enough that a client library with methods like "turn a x.search call into a list of objects" would work on these methods, too).

That sounds right to me.

See Planning for information on timelines and priorities.

Sure, we can do that too.

Ah, that makes sense. If there's some "good enough" way to get a button/link into these things today I'm happy to drop that in place while I'm in here, but we can just leave it for fiddling later too.

@chad, I'd ideally like to put a "view more" on the feed on the project page so that the original issue here (wanting to page back in history) is easier to solve. This is what it looks like right now:

I think using a Pool (like HandlePool) is not too much more work (at least, if I'm implementing it) than AJAX it and will be useful in more cases. I believe we need the Pool implementation regardless, sooner or later.

I think D18025 reasonably covered the immediate request we received, so just kicking this off the board until the next Phriction iteration.

A handful of users had created Conpherence threads to help the community find HP printer fax support. I destroyed these threads manually. There's currently no "Can Create Threads" permission and I probably wouldn't want to lock this down today since we get some legit uses out of it too.

Your suggested edit is correct, "disable" meant "switch to No I/O" but is misleading here.

I think that should fix things, but yell if I missed anything or made it worse or whatever. Thanks for the report!

Another approach might be to do T11934 first, and then implement this as /accept-magnainmously. This would be very hard to discover, but it's possible that ~10 users worldwide are meaningfully impacted and I could send them each a nice fruit basket with a card explaining the feature.

The major motivation for --no-discovery was to avoid this problem:

See also vaguely related T12590.

Actually, "no longer necessary" might be overbroad. If you have some really bizarre setup with Mercurial repositories, --no-discovery might save you some log spew in some situations. But assuming you're all git, it should no longer do anything in any valid configuration.

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".