I haven't seen any reports of actual users experiencing real confusion. If and when we do, I'd prefer to tailor any solution here to their actual confusion (e.g., what were they expecting to see, what were they trying to do, why did they find this confusing), and imagine that hiding these applications is probably not the best solution (offhand, another solution might be marking these applications as admin-only instead). In legal jargon, this issue isn't "ripe".

There's some tangential discussion of thinking about sort-of-similar issues in T8761#124843.

I'll update the documentation to explicitly dissuade users from filing "unripe" or hypothetical issues. Issues which discuss hypothetical future harm aren't very helpful to us because they necessarily lack the context required to understand the root problem. We can't move forward with them until the actual harm occurs, because we can't know if the harm will occur, why it will occur, how to fix it, if we actually fixed it, etc.

I can only agree with your position WRT hypothetical requests, but this task is a UI bug in my mind, not a hypothetical request. There's no reason for a non-admin user to see admin apps at all, which they cannot do anything with anyway: it's just setting the user up for failure.

Besides AFAIK when you are not an admin, a number of things are hidden in the Phabricator UI, so clearly even it these things may not cause actual "harm" to regular users, the decision was still made to still hide them.

If I hadn't put "Seems like this would confuse users to even see these." in the task description but instead just said: "Bug: admin apps are visible to non-admins", would you really have said this is hypothetical?

Case in point: as a non-admin, clicking on "Config" here:

Just results in this:

I would argue that showing stuff to users that cannot be used is a UX bug.

I would argue that showing stuff to users that cannot be used is a UX bug.

I disagree very strongly. In the general case, this is an important feature which makes the UIs easier to use and reduces our support cost. It's usually an explicit design decision, not a bug.

In the common case, we show many things that users can't do. For example, when viewing a task you can't edit, we still show an "Edit Task" link. Clicking the link explains why the user can't edit the task, but showing the link means that the UI is always consistent, things are always in the same place, users can see how they would do things even if they can't do them. If we didn't show this link, a user who wants to edit a task but doesn't have permission to can't distinguish between missing permissions and not using the software correctly. Showing the link prevents any user from ever being confused about how they edit a task, or thinking they might be on the wrong screen or just doing it wrong, etc.

This UI pattern is used extensively in other software, including OSX, for the same reasons. For example, if you open the "Edit" menu without any text selected, options like "Cut", and "Copy" are shown but greyed out.

Although the argument for showing these applications isn't as strong as the argument for showing commands, there are a lot of similar cases where showing these applications removes ambiguity. For example:

• A user is logged in with the wrong account (not an admin account), and tries to go to Config. With the current behavior, they receive a permission error. With the proposed behavior, they can't find the application at all. The permission error is more specific, and more likely to remind them that they're logged in with the wrong account than the thing being completely gone. The permission error is also less likely to generate a support request (resolution is more clear), and is much easier to resolve if it does (the number of things that could be wrong is much smaller).
• A user who isn't an administrator is trying to follow some instructions in the documentation which direct them to navigate to Config, but doesn't realize they'll need to be an administrator. With the current behavior, they can find all the signposts from the documentation in the UI, but are stopped by a permissions error before they complete the navigation. This suggests to the user that they're doing everything correctly, just don't have permission to take the action, which is the correct conclusion. With the proposed behavior, they won't be able to find all the signposts and may be left with several possible explanations (e.g., documentation is wrong, or they followed the instructions wrong).

Let me try to rephrase: "I would argue that showing entire app components to users that cannot be used is a UX bug".

The Edit menu analogy is not a good one IMO since the equivalent to the current Phabricator behavior would be more like showing the "Edit" menu with all commands enabled even though selecting any of them would result in in showing a dialog "you can't do that". Might as well not show the "Edit" menu at all.

The two examples you provide can be translated as-is to any app (e.g. if I set Pholio to only be usable by people in the Designers project), so why hiding apps at all then?

In any case, it's not a big deal anyway, I just felt it was worth pointing out this UX peculiarity.