My primary concern here is that I strongly dislike adding options to the product (see T8227 for discussion). In most cases, I personally bear the brunt of the long-term cost of adding options.

This requires:

Can you disable Autoclose in the version-branch repository? Differential → (Select a Repository) → Edit Repository → Edit Actions → Autoclose? Or do you want these commits to associate, just more weakly than they currently do?

IMHO one should always be able to login using admin account that was created. This is not the case. Is it a bug?

• From elsewhere, we should make it an explicit error to specify both "before" and "after". The behavior when both are specified is meaningless. This should generally be better documented.

Cool. D12973 adjusts the documentation to recommend the relevant setting in the general case. Thanks for the report, and let us know if you run into anything else.

This seems to be working correctly now in my test case. Can you verify that things are fixed for you?

I've deployed a configuration change which I believe will fix this, but it affects AWS CloudFront so it will take a few minutes to propagate. Once it deploys, I'll test if it resolved the issue.

Thanks, I'll take a look at this.

No, we shouldn't. All of the changes that I have been making should be backwards compatible. Older arcanist clients will still submit arcanistProject as part of a diff, but it will be silently ignored server-side. We will need to wait a while before landing D12899 because this diff removes the arcanist.projectinfo Conduit endpoint (which is still in use until after D12962 and D12971).

Here is the expected workflow when you login with your newly created administrative account. First, you'll see the home screen like this (note the red callout about unresolved setup issues):

• Press / to focus the search input.
• Configure this setting in Settings → Search Preferences.
• Press ? for a list of keyboard commands.

Yeah, this is a bug with the interaction between offsets and limits in the underlying fulltext search query (which finds documents matching the search terms) and policy-aware, cursor-based paging in the application-level query (which filters out documents you can't see). I wasn't able to find a clean fix in 5 minutes of poking at it.

Cool. Let us know if you run into anything eles.

The username is also locked, and can not be edited from the web UI.

Can you walk me through a deployment scenario where changing the password from the web UI is necessary, but changing the username, host, port, etc., are not? I can't come up with a case where this makes sense.

Filed as T8277.

since it's a huge GIF with a bunch of text on it.

I'll file that separately.

We strongly recommend you disable (rather than delete) users for this reason. This is explained in the prompt when you try to delete a user.

• secure.phabricator.com does not support export-grade (weak) ciphers, and is safe from the brunt of this attack.
• nlb*.phacility.com is terminated by the notification server, which does not support export-grade (weak) ciphers, and is safe from the brunt of this attack.
• *.phacility.com is terminated by ELBs, which do not support weak ciphers as configured, but do use a common 1024-bit DH group. This means connections could theoretically be compromised by state-level actors. I think we can't address this directly (we can configure cipher suites, but not the DH group). I haven't found AWS issuing any guidance on it yet. I would expect them to remedy the issue or provide guidance on it in the next few days; if not, we can evaluate running software loadbalancers instead of ELBs (this is a fair amount of work, but we already run software LBs on the vault tier and terminate our own SSL on the nlb tier).

You may be able to run this command:

This is presumably obsoleted by the new scrollbar behavior.

Presuming resolved since I'm pretty sure this works properly.

This seems to be in relatively good shape. Some possible future work:

Placing severe limits on the power of administrators is an intentional design decision. See here for discussion:

Even T3820 won't necessarily fix this. We don't currently plan to implement this level of siloing, although we may pursue it after T3820. If you need to prevent users from knowing that other users exist, Phabricator may not be the best tool for your purposes.

Yes, we plan to address this use case via "Spaces", see T3820.

I dont believe such functionality exists at the moment. Can you describe the problem that you are trying to solve? see Contributing Feature Requests.

I think this would also be covered by T3820.

I think T3820 is what you are after.

LLVM has custom code which is doing this. Upstream Phabricator does not send email which looks like this.

I love them so much

The header shows the view policy, not the edit policy.

Quite possibly.

My User Agent is Mozilla/5.0 (Linux; Android 5.1; Nexus 5 Build/LMY47I) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.111 Mobile Safari/537.36

I think there's a point at which your parsing JavaScript instead of JSON...

This has come up for discussion before, although I can't remember when/where. Generally, I'm onboard with it.