Definitely, let me get you a rough cut.

Quoted Text

I've been wanting to have next/prev post, but wasn't sure how to build it. I can build the UI and let you handle the query?

If so, I'd generally claim this is an issue with the client you're using: I think clients generally should not do parameter validation themselves. They will always be less able to do validation than the server is, even though server validation is not especially sophisticated right now. If/when we have a formal Python API client, it is very unlikely to perform client validation. Does client validation provide any advantage?

http://www.gyro-php.org/documentation/contributions/group__Unidecode.html seems relevant.

It may also make sense to fold accents when normalizing strings for ngram indexes.

I think we fixed this elsewhere, yell if it's still an issue.

I tink at least some of this was added in, e.g., D14231.

You can destroy the whole index, then reindex everything.

We don't know how to reproduce this and haven't seen other reports.

I'm not sure how to reproduce this (it didn't reproduce just now), and haven't seen any other instances of it or further reports. It's possible this was fixed earlier this year; we did some work on inbound mail around the time of this report.

(Test.)

We haven't seen requests for this from other installs and I don't particularly favor this mechanism. Prior alerts in this vein like "daemon and web config differ" have created a lot of noise and little value. T7338 should eventually provide more monitoring tools.

I don't think we actually need, this at least for now. We can look at it again later if we get more feedback about users making these sorts of errors, but it seems unlikely (I think?) that a use would type google and expect it to work.

Let's just wait for a stronger use case before building this, I think our URL construction has generally become much stronger since this idea was originally tossed around.

From the front page:

I don't want the error messages to just disappear since I worry that might be confusing, but I've added an option to dismiss errors once you're done with them in D14886:

Possibly related to T9270?

Couple of thoughts, not necessarily unbeta stuff:

It's not recommended to install on a shared host. This is the first of likely many issues you'll run into trying to set up Phabricator. Maybe you'll get lucky.

I'm merging this into the newer T5698, because that one has slightly more discussion and more subscribers.

Resolved by D14823.

I'm going to merge this into T8488 since I think we ended up just removing this distinction.

I'm just going to close this because it doesn't identify any specific problems and I don't want to build these things to deal with hypothetical problems.

I think it's good that destruction happens in the foreground, since I think this should be a very rare operation and errors should always be reported to the user. Users who want to background long destruction operations for some reason can use tools like screen.

Facebook has this exact kind of integration with their internal tasks tool - it's extremely useful for communicating the engineering progress of a task to non-technical team members, and it builds an explicit relationship between tasks and diffs, which very often go hand in hand. Maniphest and JIRA both already have this type of integration with Differential - it would be great to have the same thing for Asana.

These are in good shape technically for whatever you want to throw at them.

Maybe a better approach would be to let you filter which columns are visible more flexibly. It sounds like all the existing use cases are arising because "hide" isn't being used to archive obsolete columns, but because it's being used to give workboards multiple states where each state has a different set of visible columns.

See T5403 into T7858. I don't think this makes sense after T4100 with "Browse" UIs. All requests for this are "distinguish between multiple similarly-named projects", which is better done via "Browse".

Oh, I was thinking this needed a whole pile of work (like, all of T9372) but I don't think it actually does. I'll take a look.

@epriestley not sure if you saw this, but all apps installed by default on the sidenav have a reasonable blank state except for Differential. Not sure how much work there is to modernize RevisionQuery there.

The original request here seems to be for specific links to members and workboards from hovercards. I think it predates modern defaulting rules (i.e., clicking the tag now takes you to workboards for projects where they're in use) and we haven't seen other requests for this. I expect work adjacent to T10054 to continue giving us better behavior for clicking through. I don't understand the use case for frequently needing to access members quickly. I don't currently anticipate adding these links to hovercards.