Page MenuHomePhabricator

Defining policies for "Project Members"
Closed, ResolvedPublic


As far as I can see it is not possible to set a policy to "Project Members", meaning the members of whatever project a task belongs to.

Use case: we are happy allowing all registered users to edit tasks, their projects, and dependencies, but we want to restrict changes to Priority only to the members of the specific project. We want to set such policy for all projects.

Currently Admin > Applications > Manifest allows to define policies for All Users, Administrators, or the members of Project X. Unless I'm something, this means that we need to edit the policies of each project one by one, assigning each team to each project.

Event Timeline

qgil raised the priority of this task from to Needs Triage.
qgil updated the task description. (Show Details)
qgil added a project: Policy.
qgil added a subscriber: qgil.

Context: Wikimedia has hundreds of projects, technically we could set manually permissions for Project "Foo" specific to Team "Foo", but we'd rather define a policy based on Project(x) permissions given to Team(x).

Is this already possible in Phabricator and I'm just blind? It's somewhat strange that we are the first ones requesting this feature.

T3820 has some general discussion of why projects do not currently imply policies directly. In particular, an object can be in multiple projects in Phabricator, which tends to complicate anything in this vein.

Some issues that would arise with a "Project Members" setting, offhand:

  • You would also need to lock the projects field itself, to prevent a user from adding a task to a project like "epriestley loves prioritizing things", then re-prioritizing tasks (since the user is now a member of one of the projects the task is in).
  • If you lock the projects field, legitimate administrators of the "Goats" project can't put an existing task in "Goats" because they won't have edit permission for the field.
  • If the user filing the task can edit the projects field, he or she can add "epriestley loves prioritizing things" and then prioritize it. If they can't, they can't meaningfully categorize the task.

A coarse solution is to create a project called "Users Who Can Prioritize Tasks", set that as the policy, and add anyone who should be able to edit priorities to that project.

T3820 might offer more fine-grained solutions here, by letting you separate projects across namespaces, although that's not completely fleshed out.

I think no one has requested this because most projects have highly-trusted users (e.g., employees) and may have relatively-untrusted users (e.g., contractors, clients, contributors) but it's rare to have somewhat-trusted users (presumably, volunteers who have seniority in project X but shouldn't be allowed to touch project Y?).

I'm not sure if T3820 will offer a good solution to this problem or not, but I think a "Project Members" setting is probably not the right way forward here.

I see. So far my concern has been theoretical. If we do have a real problem one day, probably the long-term solution will be a workflow that you can find in many membership sites:

  1. User requests joining a team.
  2. Any admin or any team member can accept/ignore.

This way users cannot just walk in to a team, but they cannot be forced to join a team either.

It is fine if you wontfix this task (or merge it with T3820). I might revisit it in the future, if we run in a situation where the current system of distribution permissions doesn't scale.

We had thought about an EditTasks group, just like we have an EditBugs group in Bugzilla. We can work out an initial configuration based on it, allow exceptions for projects with more restrictive requirements, and see how it goes.

libregeek triaged this task as Normal priority.Jul 16 2014, 1:22 PM
libregeek moved this task from Details to Important on the Wikimedia board.

A coarse solution is to create a project called "Users Who Can Prioritize Tasks", set that as the policy, and add anyone who should be able to edit priorities to that project.

I think I mentioned this in T6502, that is having a more generalized "Users Who Can Plan Tasks" which would encompass Workboards and Priority might be a good solution. Of course my language isn't completely perfect.

Workboards and Priority are something I'd likely want on this install as well. I don't think they need to be two separate Policies.

eadler added a project: Restricted Project.Aug 5 2016, 5:24 PM
epriestley claimed this task.

At least in this use case, I believe things turned out alright without this policy.

Nowadays (and maybe back then, although I don't remember), this policy can be implemented as an extension fairly easily. However, I don't currently plan to ever bring it upstream because I think it will cause more problems than it solves overall, per above. At some point I also wrote a slightly longer version of that in the documentation with some examples:

There are some narrower flows (like "request to join a project", and workboard stuff discussed in T6502) that are quite reasonable outside of this, but as far as I know the former hasn't really been an issue and the latter is already tracked on that task. If there are any other followups here, feel free to file new tasks describing what issues you ultimately ran into.