This is what it looks like after refreshing the page:

It is most definitely still an issue (in this case it duplicated like a bunch of times when I just spammed Send Message):

To add my own personal notes on this:

It was against HEAD at the time of the report. I'll try upgrading today and see if it fixes the issue.

Just reproduced it on this install, try viewing the project now.

Distributing third-party (or maybe unbundled first-party) Phabricator applications.

This has since been fixed.

As a side note, the task numbers T1049 and T2015 are permanently etched into my brain.

Upgrading fixes this issue.

Works on this install so it looks like I need to upgrade.

To copy the globally installed modules, I run the following on boot in the docker image:

Ironically for the docker image I built, it has to install WS from the system package manager because NPM doesn't work right. On boot it then copies the globally installed ws underneath the server folder.

If you're running a system with systemd (but I don't think the version of Ubuntu you are using does?), you could configure the Apache service with:

The other task that had this discussion is T4002: The "Edit Dependencies" dialog should use the saved search architecture.

It's better than git-annex because it actually works on Windows. git-annex's Windows support is extremely clunky (see https://git-annex.branchable.com/todo/windows_support/) and automatically turns on direct mode (because Windows does not support symlinks without Administrator permissions).

Merged T5010 since git-lfs is a far more feasible option than git-fat from a technical perspective (regardless of whether the actual feature will be built into Phabricator).

For some strange reason, it has now disappeared after creating a room...

As far as I know, the reason arc diff warns about untracked files is because untracked files could impact the result of unit testing or linting. The only way to know if those results are correct are for the working directory to exactly match what you're landing.

The feature basically changes the User Agent to desktop Chrome as far as I know, and nothing more. That's why Phabricator doesn't appear any different, because the CSS is already optimized for mobile based on actual screen size (and not redirecting based on user agent).

The only time I ever tried to use this was when the project sidebar wasn't available / usable on mobile and I had no way of creating a workboard.

Is there any reason that you can't simply allow registrations via other OAuth providers which implicitly registers accounts in the cluster (and links them)? This way an administrator could enable the JIRA provider with a white list on the email address domains allowed, and then everyone can just login with their JIRA account (obviously each new person that registers on the instance would increase the billing amount per month).

You mean T3 right? T2 has an open task under Blocked By according to the scenario you stated.

Okay, but you still have no way of safely issuing another bin/phd stop without it stopping both overseers?

There's no way an over-overseer can know when the previous reload is finished; all it can do is call bin/phd stop --graceful 999999 in the background and leave it to run. In addition, a previous reload can take several hours to run; if you need to deploy out another set of code before the reload is finished, you have no safe way of doing so until the first one is entirely complete.

I see this on secure.phabricator.com and local installs.

In our scenario, we have members of various teams who can control deployments, as well as the DevOps team (all of who can control deployments). We could create another project which is "DevOps + Deployment Managers", in addition to the "DevOps" and "Deployment Managers" projects, but this seems like more maintainance of projects (what happens if someone is removed from "DevOps" but not "DevOps + Deployment Managers"? They'll still be able to access stuff that they should no longer have access to.)

I should add that the way Phragment currently solves this problem is that it has a "Replace policies on child fragments with the policies above.", but this seems less appropriate for Wiki articles (given that you might want to have a child document with a more restrictive policy than it's parent, whereas for Phragment you're usually updating policies for ZIP archives and all their files).

The way policy works is clearly understood, it's just impractical when you want to open up a bunch of wiki documents. This is impractical when you have a parent document and 20 children; yes I could go through and update the policies on all 21 documents, but it's annoying and tedious.