Phabricator projects should not have their visibility policy altered. I when I have time I will look into how difficult it would be to simply hide the policy controls for projects, forcing them to always be set to 'public'
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | mmodell | T120903 investigate hiding the policy controls for phabricator projects. | |||
| Resolved | mmodell | T120013 Next Phabricator Upgrade - 2016-02-18 | |||
| Resolved | mmodell | T122556 Figure out what upstream "Can Edit Task Policies" policy deprecation means for our Spaces/ACL setup | |||
| Resolved | DStrine | T123317 Report to TPG on new Phabricator Functionality | |||
| Resolved | csteipp | T125104 Evaluate the feasibility of phasing out the Phabricator Security extension | |||
| Resolved | • ksmith | T127019 Plan announcement of new major phabricator upgrade |
Event Timeline
Comment Actions
We should definitely be hiding the visibility policy field from everybody. I'd like to have a Maniphest-like 'Can Edit <x> Policies' application policy for Projects, and then restrict this to prevent most people from editing edit/join policies.
Comment Actions
@Krenair: I'd imagine that upstream would be receptive to a patch adding that functionality, however, I'm not sure how straightforward it is to implement. It doesn't feel like a terribly high priority.
Comment Actions
Well, they've done it for Maniphest, haven't they? I think it makes sense to provide similar functionality in projects.
Comment Actions
@Krenair: for sure, it definitely makes sense and would be more consistent. I think maniphest just gets a lot more attention than projects does.
Comment Actions
I do support this for the "Visible To" project policy.
When it comes to "Editable By" project policies, it's more complicated: It is used for acl* projects that Spaces rely on. Spaces are set up by administrators. Administrators set the "Editable By" policy to "admins and lead of that team" (so team leads can edit the list of project members and do not rely on admins. For example, for #acl*communityliaison_policy_admins it is set to "admins + Rach", or for #acl*fundraising_research_policy_admins it is set to "admins + atgo".
Comment Actions
I don't think my proposal about limiting who can change project edit policies themselves would be incompatible with that setup, @Aklapper. Admins would be able to configure edit policies, and the people allowed by those edit policies could edit the project to add/remove members.
Comment Actions
yeah this will be trivial as soon as T120013: Next Phabricator Upgrade - 2016-02-18 happens
Comment Actions
@Krenair is right, we will create a custom form that can be used by the people that should have access to edit policies. The custom form will not be available to others and the default form will have the policy controls removed.
Comment Actions
I've updated the default form to remove policy controls. I'm still working on the forms a bit more so keeping this task open for now.