Page MenuHomePhabricator

investigate hiding the policy controls for phabricator projects.
Closed, ResolvedPublic

Description

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'

Event Timeline

mmodell claimed this task.
mmodell raised the priority of this task from to Low.
mmodell updated the task description. (Show Details)
mmodell added a project: Phabricator.
mmodell added a subscriber: mmodell.

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.

@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.

Well, they've done it for Maniphest, haven't they? I think it makes sense to provide similar functionality in projects.

@Krenair: for sure, it definitely makes sense and would be more consistent. I think maniphest just gets a lot more attention than projects does.

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".

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.

Addshore added a subscriber: Addshore.
Addshore removed a subscriber: Addshore.

Can be done by forms, so blocked by the next update...

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.

@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.

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.