Setting project XXX permissions to "Members of Project... XXX" does not list XXX when the user is an admin but not a project member.
Description
Description
Revisions and Commits
Revisions and Commits
Related Objects
Related Objects
- Mentioned In
- Blog Post: Projects in Policy Controls: No Longer Total Garbage
T8808: Policy menu should show actual project icon next to project
T9164: Simplification of policy controls for different types of projects in an organisation with external collaborators (policy templates?) - Mentioned Here
- T9183: Policy control JS dropdown should be case-insensitive sorted
Event Timeline
Comment Actions
This is currently expected -- the defaults available in the dropdown are projects you're a member of, not projects you can see.
As a workaround, you can either join the project you want to use, or use "Custom Policy" to create a custom policy (you can select any project you can see from that UI).
I think we're going to change this UI to show the 5-10 most recently used projects and then have "Other Project..." which lets you select anything you can see.
Comment Actions
We should probably also add an epriestley (i.e., the current viewer) option, to make it easier to create personal objects which don't have strong ownership (like Repositories).
Comment Actions
Having an ability to name and save custom policies would be useful - in my organization we need to allow administrators access to some things in order to help with troubleshooting or general management. My current options are:
- Re-create custom policy for items which allow Project + Admins
- Create new Project that includes members of both Project + Admins
Option 1 is what I currently use, and being able to set the default policy helps avoid having to re-create for every instance (of say, new diffusion repositories). However this can be tedious and would be nice to have "Project X + Admins" policy that I could select when needed.
Option 2 works, however it doesn't scale well with multiple Projects and as employees change.
Possibly having sub-projects might resolve this? But I feel that would run into some nuances where a more-horizontal organization is preferred over vertical for management.
Comment Actions
One small addition: Having the ability to assign a meaningful name to custom policies would be beneficial even without the ability to re-use elsewhere. Right now when viewing policies of items, I have a lot of "Custom Policy" displayed in summaries, properties, etc.
Comment Actions
After thinking a litle more about T9183, the usability issue I'm seeing as our usage of Phabricator grows is *finding* the object / Project in the JS policy dropdown, to which I want to make the edited task visible. As the Projects list grows long, this action requires scrolling the entire page and results in a jerked jump back to top after selecting a Project. The natural sorting that I suggested there would only alleviate this slightly.
If I may make a suggestion: it may be faster for the user to have a "combo-box" for Policies just like the Projects selector, that would include all the contents of the current JS dropdown. You would tab into it, start typing, and quickly select the target Policy before moving on to the next field. If you don't want to type or are unsure what to select, clicking on the Query icon next to it would bring up all the available options to select from.