Page MenuHomePhabricator

"Visible To" should not display "Spaces" dropdown if user can only access the public S1 space
Open, LowPublicBUG REPORT

Description

Our "Visible To" interface looks like this:

Screen Shot 2017-02-15 at 1.00.47 PM.png (231×589 px, 22 KB)

The first part says the ticket is public, but in this case it actually isn't. Frankly I've never understood what the first select list is for, but I've never used it and it doesn't seem to be helpful. Whenever I'm training new hires I tell them to just ignore the first select list and use the second.

What is the first select list actually for? Do we need it? If so, can the options be changed to be more accurate/less confusing?

Event Timeline

The first part is the Space the task is in.
Spaces are 'stronger' than any potential custom policies in the second dropdown.
And yes we need Spaces. :)
Any ideas what would be less confusing?

Aklapper renamed this task from "Visible To" interface is confusing to "Visible To" interface is confusing: Spaces dropdown (e.g. saying "S1: Public") and second dropdown (e.g. saying "Custom Policy").Feb 15 2017, 7:41 PM

If we're using Spaces for real things now, can we remove the S3 "Testing space", and then make sure the dropdown is not shown if the user doesn't have the right to access any of the restricted spaces?

If we're using Spaces for real things now, can we remove the S3 "Testing space", and then make sure the dropdown is not shown if the user doesn't have the right to access any of the restricted spaces?

I've archived S3. The latter should be the case already.

Aklapper renamed this task from "Visible To" interface is confusing: Spaces dropdown (e.g. saying "S1: Public") and second dropdown (e.g. saying "Custom Policy") to "Visible To" should not display "Spaces" dropdown if user can only access the public S1 space.Feb 16 2017, 5:02 PM

I still get the spaces interface (like matmarex), even though I can only see 1 space.

According to our documentation, that shouldn't be the case.

Please provide URLs to reproduce.

(That was my volunteer account not being able to reproduce in some places.)

(For the records, with my "default" @Malyacko account I do not see any "Visible To" dropdowns on https://phabricator.wikimedia.org/maniphest/task/edit/158226/ )

Aklapper triaged this task as Lowest priority.May 30 2021, 9:36 AM

Closing as I don't manage to reproduce with the URL provided. If someone has good steps to reproduce that also work for my average account: please reopen.

RhinosF1 subscribed.

(For the records, with my "default" @Malyacko account I do not see any "Visible To" dropdowns on https://phabricator.wikimedia.org/maniphest/task/edit/158226/ )

On that url, I see

IMG_6859.png (2×1 px, 474 KB)

Which is what this task describes. The spaces menu when you only have 1 space.

Aklapper raised the priority of this task from Lowest to Low.Jun 14 2023, 8:57 PM

Thanks a lot, that helped me finally realize what I've been doing wrong so far.
Now that I checked the "Custom "Can View" Policy" of https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/edit/3/ , and made my standard account a member of one of the listed ACL projects (in this case, acl*userdisable not to create any real damage), I can reproduce.

Aklapper changed the subtype of this task from "Task" to "Bug Report".Jun 15 2023, 12:41 PM

This a bug as src/docs/user/userguide/spaces.diviner says Users with access to only one space won't see these controls, even if many spaces exist. This simplifies the UI for users with limited access.

src/view/form/control/AphrontFormPolicyControl.php: if (!PhabricatorSpacesNamespaceQuery::getViewerSpacesExist($viewer)) { should in theory avoid the observed behavior.

I have not managed yet to reproduce this locally.