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.

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.

That Herald rule is clever!

First thought is to do this:

Yeah, on further thought I suspect the magical config is just metamta.reply-handler-domain not being set.

Presuming this is resolved because the new feature is a superset of the old feature.

(I don't think we need this to repro anything.)

There's also no actual technical reason that objects legitimately need to have a mailKey at the PhabricatorMailReplyHandler level right now.

I can't actually figure out what configuration avoids this error -- metamta.public-replies on and off both try to call getMailKey() for me.

We are very unlikely to ever support this.

(I pushed this, too.)

I haven't seen this one before. My guess is that it might be because you have display_startup_errors on, and possibly we should detect that and raise an issue for it, although it's sort of good to show these errors somehow.

We aren't interested in supporting IPv6 in the upstream at this time, and don't have the time or resources to help you develop a patch.

Type r and then part of a repository name, like:

This behavior is expected. Cursor values are not intended to be human-editable. The fact that this worked in previous versions was a side effect of how the cursor was implemented at the time, and not an intentional feature.

See also T6403 for a longer-term fix for this.

Let me know if that didn't fix it ^^

I think this is something we'll probably revisit in the long run but it's probably a v2+ type of thing and I'd expect it to be informed by other product decisions between now and then (and possibly by application changes like having meaningful automatic escalation).