See also PHI48.

A prototype of this is now available on this server (secure.phabricator.com). You can access it in Maniphest by using the Query (Prototype) field instead of the Contains Words field.

I think there will be a trickle of these for a while, but we seem to have found the most common cases.

We'll consider offering instances in the Sydney region in the future, but this isn't really a valid feature request or bug report. Feel free to continue discussion on Discourse.

This is now in the wild, and nothing seems to have cropped up yet.

The behavior may have changed, but the change is from "we sometimes silently do the wrong thing" to "we explicitly refuse to do the wrong thing".

That is, specifically, it expected that hg commands do not work in Phabricator if it can not determine the version of hg, so this is not a bug. Ignoring the setup warning might mean "we used to do Mercurial stuff but don't anymore, leaving us with some archived Mercurial repositories which we don't really need to look at, so it's okay that hg commands won't be able to run".

The version is strictly required because different versions of hg use different command syntax. If we can not determine which version of hg is installed, we can not run hg commands.

We haven't seen other users encounter this issue in several years.

No current plans to ever pursue this.

Herald rules are now always public, which possibly addresses the original issue.

We haven't seen more interest in this in several years.

This doesn't sound like a Phabricator problem.

I'm going to call this effectively resolved:

I'm pushing this here, yell if all your queries explode or what-have-ye.

I'd guess it's several days of work.

See Planning for information on planning and timelines.

One caveat about this is that it gets dicey if we implement T4280, since user-specified anchors could look like anything and could collide with anything. But we can cross that bridge when we come to it. This is an issue in general anyway, since two users can make comments with the exact same anchor in them.

If you believe you've found a bug in Phabricator, please follow the instructions in Contributing Bug Reports to file a report.

See also PHI41.

Did you consider increasing the "tablet" breakpoint above the size of an 11" macbook instead?

Yes. In Mercurial, branch heads may be "Open" or "Closed".

I'm going to merge this into T12963, which isn't exactly the same but overlaps this substantially. It's possible we'll pursue a more narrow "vacation review" mode eventually, but we'd want to finish T12963 first and make sure it didn't adequately address this problem on its own.

Practically, msortv() and PhutilSortVector are now the solution here. They provide high-performance (no usort*()), multi-dimensional, stable, explicitly typed sort.

Just sweeping this up, rewriting the property display to show +x seems reasonable to me but I think it's self-evident enough that we don't need to keep a task around for it.

I don't think this meets the high bar required by modern feature requests (see "Upstreamable Feautures" in Planning).

(This isn't anything upstream-actionable.)

This seems to have calmed down.

We appear to have survived this. D18398 removed the double writes. There's a bit more cleanup (we could remove the edge type and actually destroy the older data) but that can happen whenever we get around to it.

This is five years old, and doesn't meet the requirements of a modern feature request. If you're still interested in this, feel free to start a new discussion on Discourse.

This doesn't meet the criteria of a modern feature request and predates significant changes to the inline comment UI. If this is still an issue, feel free to start a new discussion on Discourse.

Closing this for lack of feedback, feel free to resurrect it if you get back to it.

This isn't a bug; they aren't subscribers, and aren't listed in "Subscribers" in the right-hand column or in "Subscribers" in "Edit Task".

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

I just clicked through it, I don't think there's any reason for staff to be there normally.

There doesn't seem to be anything actionable remaining on our end.

We still get a tiny mess where administrators clicking "pin" might mean "pin by default for all users" or "pin by default for just me" but that's reasonable to clarify in the workflow.

Currently, users may hide or reorder builtin queries. With the simplest version of the plan above, users will lose that ability: builtin queries will always be visible (unless hidden by an administrator) and always at the bottom of the list.

@aubort, please use the community forum (see: Discourse) if you'd like to discuss this issue.

@aleb, if you like to continue discussion of this please use the appropriate channels, as @chad suggested above (at the time, they were Conpherence and Ponder, but the appropriate channel is now the community forum -- see: Discourse).

In https://hackerone.com/reports/259246 (not currently disclosed) a researcher found an actual issue with figlet. Although it would probably be hard to develop into a practical attack, it does make me feel better about the decision to pull all this stuff into PHP (not just dot) when the dot issue was originally identified.

I've landed the two scary migration changes (D18418, D18419) and deployed them here without any obvious issues arising. The actual effects here are: