This is kind of time-specific since it has a version number, but I got Aphlict working on my server by navigating to phabricator/support/aphlict/server and running npm install ws@2.X (literal X) as root. This installed version 2.3.1 (im assuming the latest stable 2.X version). Upon restarting aphlict, the notifications work without raising exceptions.

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 had indeed implemented precisely that herald rule once I realized that these diffs were being created without repository info attached. I also added repository.callsign to /etc/arcconfig to eliminate the problem going forward.

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

We could change the behavior to "tap and hold to begin a range + drag".

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.

There isn't enough information here to reproduce the issue as described. Do you have additional steps I can follow and see the issue locally?

I'm not allowed to close this, but it was fixed by T12757

Now i have changed that

In case anyone is still looking for a Trac Wiki -> Phabricator Phriction importer, we have an ugly but mainly functional script I pasted here: P2056. Code blocks are not always converted correctly, but for us that script was enough.

In T12766#225295, @epriestley wrote:

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

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

Thanks! We'll keep this around and see if a migration is needed. Sounds like mostly a dashboards issue.

@exp10r3r you still need to provide reproduction steps. Based on the ones provided, I cannot reproduce any issue using a new/clean install on Phacility or locally. That doesn't mean there isn't a bug to fix, but without the specifics needed to observe and troubleshoot the issue, we have no idea where to start or what to look for. Because we provide support for free, it's on report submitters to fill in all the details needed here. We can't assist with that. No other install is reporting this issue, so it's unlikely due to any change from the upstream.

Can you just pick a new query and fix the panel?

Can you just pick a new query and fix the panel? My thought is if only 1 person in 12 months is affected, it's going to be faster for you to fix the panel than for us to find resources to build an old image and test migrations.

I can confirm T12129 is indeed related, and the suggested workaround is very effective. Thanks for this!
For the record, our repo has about 60 branches total (about a dozen active only).

Took another pass here. I'd still like to figure out a way to get and working, but I could also just design them into the comments like they previously were. I think it's better though to have them in the top bar, since I could click on the and get right to the first bit of work I need to do.

(though we could add a mini-minimap to it, just a thought)

(it's probably distracting and pointless though for code review)

To be clear, the "progress bar" background was a simple scroll indicator, nothing related to marking things done. Some blogs use them and I find in ... interesting ... nothing more. It's sort of nice to know how much you have to read through to be finished. It would start at the top of the first file and end when the final comment box appears. You can see one in action here: http://www.avclub.com/article/why-does-superman-keep-getting-turned-dictator-255977

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

Thanks, everybody! Appreciate it, especially on a Friday night. :-)

Based on two points of anecdata so far, things indeed seem snappier with D17959.

Please read and follow Contributing Bug Reports carefully.

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!

Its on another page for scalability, we used to just have a single page.

Yep, that would be the page. I was expecting to see details ala "Related Objects" in Maniphest and failed to move my eyes sufficiently left.

This page?

That does indeed work! Thank you so much!

Does this work?

Not easily. :/

In T12234#211222, @epriestley wrote:

From a technical standpoint, we did not record these relationships in a normalized way prior to D16196 (June 2016, about 7 months ago) -- they only existed in the transaction log, and we just wrote a "close", extra_data="as duplicate of X" transaction that can't be queried efficiently.

Can you use the modern conduit calls?

This accidentally got fixed this week

That looks great to me.

Actual example output:

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

So should the return value for priority.search look something like this?

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

It looks like what we really need is a new method like maniphest.querystatuses, called maniphest.querypriorities to avoid anyone trying to hardcode these values.

That sounds right to me.