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.

Thanks for the very detailed response.

Yep, that's a better solution. In the mean time, we just updated all of our .arcconfig files.

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.

@epriestley, if you had any thoughts on this it would be appreciated as this issue is heavily affecting our users. There is a workaround (update our .arcconfig files to point to the new domain), but we have a lot of repositories...

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.

For git, is that because discovery only happens on the Almanac device on which the repository is bound to or is it because there is some sort of global lock taken for repository updates? I'm curious to learn more bout how this works.

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.

Thanks.

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".

I feel like there's just some kind of bizarre disconnect:

See also vaguely related T12171.

@nemobis: when customers pay (for example) Atlassian for Atlassian Premier Support, what value/right/expectation do you believe they're getting out of that which we aren't also offering above?

This was a misconfiguration on my part and I wasn't properly forwarding the query string from nginx to PHP.

This was a misconfiguration on my part and I wasn't properly forwarding the query string from nginx to PHP.

Possibly related, I'm having issues with Almanac too. I created an Almanac device, but clicking on "Add Interface" takes me to /almanac/interface/edit/?deviceID=2 which shows a 404.

In T12547#219587, @epriestley wrote:

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

😢