Should be fixed in HEAD. Thanks for the report, sorry this is taking so many iterations to get right. Let us know what else you catch.

Haha, sorry, I hadn't actually committed the fix yet.

The process has already daemonized by the time we get this far, and it's generally impractical for us to prompt for the passphrase before daemonizing without significant rearchitecture. We also haven't seen other users trying to use password-protected certificates, and believe their use to be rare in most infrastructure (for instance, ELBs in AWS do not support them either).

Yeah, I'm pretty sure there aren't any relevant changes between rP18340d9 and HEAD. If it isn't resolved the next time you upgrade, let me know and I'll dig a bit deeper.

Seems like I fixed the top-level handling issue at some point (?) -- maybe during T6692 -- since I get this, although @mpalmer reports only getting a log in T7433 (maybe you're a little out of date?):

Although maybe that's talking about REST specifically. Unclear from context.

Some guy who authored HTTP or something here suggests this is legal but non-useful:

Well, I unhijacked symbol function_name as longhand for s function_name too.

We also hijack the word "symbol" but that seems more reasonable than "help". And we hijack a bunch of single letters, but those aren't normally reasonable search queries.

Yeah, I think this is a hijack and agree with removing it. This came from "Jump Nav" where it made perfect sense, but when jump nav got merged with global search I think this stopped making very much sense.

(Presuming fixed.)

This looks straightforward but I'm going to wait for things to calm down before touching production.

Yes, although we recommend using a domain.

Okay it is really launched now.

Let us know if that resolves the issue for you. Thanks for the report!

I kept this pretty brief since anything else I could add would be redundant with the entire site, the admin welcome message, the getting started doc, etc.

Well, possibly fixed by D11830. But was certainly broken before D11830.

This was probably fixed by D11830. Are you behind rP84d4142b06b71e7dfe86f3c2c5c6b98973d1431c?

@lpriestley hit this and also wasn't sure if the animation was intentional or not.

We don't plan to implement this in the foreseeable future. If you need extremely granular control over field permissions, we recommend considering other software which is better suited to heavier process-oriented workflows.

T7129 is very similar and discusses another type of non-file resource which users can drag and drop.

Maybe I am bad at clicking!

This task will update when the change lands. It needs to be reviewed first. It will probably happen within a few hours, but it's very early (8AM) on the west coast right now.

This is a problem with Phabricator, not your install. You need to wait for D11929 to land, update Phabricator with git pull, then try again.

Ah, okay. Can you run storage upgrade with --trace instead?

You can grab URLs from all over the place in lots of browsers (url bar, bookmark bar, tabs, etc).

Can you run bin/storage adjust with the --trace flag and show me the output before it fails?

From what I can tell, it seems like this is possible, but very complicated.

We don't have enough information to reproduce this.

@chad, are you satisfied with D11726 or does this still feel like something we could do better about?

This happens when you do a thread update but hit 0 transactions (e.g., maybe they were all hidden), but it isn't trivially obvious what the correct thing to return is.

This is launching, uh, "real soon", and is definitely not launched at all yet, so don't, say, try to use it. Because it hasn't launched. Despite this, I'm closing this task, for reasons.

Yeah, I want to clean up T7410 first, at a minimum, before looking at this. As a heavy Phabricator user on this install (where we haven't had anyone clicking workboard buttons randomly), my experience since we implemented this is that the workboard rule always takes me to the correct page (and that page is usually the workboard).

The response could also inform installs about security updates, although it might be better to put that on a different channel so we can deliver notifications in a more timely manner.

One general thought is that we could prompt administrators to confirm that they want to add members who could not otherwise join the group, or prevent their addition outright, but I believe both of these workflows are very common (e.g., on this install we have a number of projects with "Can Join: No One" and a manual membership list; construction of these projects was intentional). And users who can edit projects could always get around these restrictions, so any measure here would only prevent mistakes, not malicious actors.

I'm going to close this for now, since I think we resolved the major issues. We'll keep an ear out for users making mistakes with policies and work to clarify workflows, prevent those mistakes, and/or make them easy to undo.