Page MenuHomePhabricator

Allow creation of parameterized application policies
Closed, DuplicatePublic


When default application policies are applied to objects, they are currently copied directly. This allows you to create a policy like:

Default Edit Policy: epriestley

...but this is rarely a useful default policy because it's hard coded to one specific user. A parameterized default would more often be useful:

Default Edit Policy: Acting User

Under a parameterized policy like this, alincoln created a task, the effective policy would be "only alincoln".

I think this is the only useful parameterization among the builtin policies, although it should also ideally be possible to create a parameterized custom policy which uses "Acting User" in conjunction with other rules. This is blocked by T4100.

We can't implement T5135 until this happens, because the current default policy is effectively this parameterized policy ("only the acting user"), and there's no way to express that policy with a defaults control.

This may also interact with T5681. It is possible that applications may have meaningful policy parameters which are creation-time resolvable, although I can't really think of any offhand.

This might possibly interact with T6524, although it doesn't make a ton of sense to me to default a policy to the actor's IP address.

Original Problem

The reporting user wanted to configure Phabricator so that users can create tasks, but can not edit tasks created by other users.

This use case is unusual, but adjacent to other things we want to support and mostly within the realm of reasonableness.

Original Report

Under /applications/view/PhabricatorManiphestApplication/ there currently is only Can Edit Task Status which can be set to All Users or Administrators.

Neither choice is a good one. Setting it to Administrators means, that normal, non-administrator users cannot create new tasks (such as bug reports or feature requests). In our project installation we want normal, non-administrator to be able to create new tasks. Our only option at the moment is to set it to All Users. But this is also not really what we want. Having a user modify its own ticket is okay. But having arbitrary normal, non-administrator users being able to modify each and every task is a security issue.

A good policy for Can Edit Task Status would be Ticket Creator and Administrators.

Alternatively, other bug trackers such as trac allow normal, non-administrator users to create tickets, but not to modify any. Seems even better to me. Configuring as such is currently not possible with maniphest.

Talked about this yesterday with @epriestley on IRC. So if my report is unclear, he can hopefully clarify it.

Related Objects

Event Timeline

patrick.schleizer raised the priority of this task from to Needs Triage.
patrick.schleizer updated the task description. (Show Details)
patrick.schleizer added a project: Maniphest.

Can Edit Task Status can be set to any Project (team) as well or Custom.

Can you describe the problem you are trying to solve? We have many "improve Policy" tasks, one that might be better suited to what issues you're currently having.

epriestley renamed this task from maniphest lacks secure policy setting for creation of new tasks to Allow creation of parameterized application policies.Jan 4 2015, 4:28 PM
epriestley triaged this task as Low priority.
epriestley updated the task description. (Show Details)
epriestley edited projects, added Policy; removed Maniphest.

I wasn't able to find previous discussion of this immediately -- it was buried in T5135. I updated the description to provide some context.

In our installation, we have it so that if you make a task attached to a project, it sets the default visibility to that project.

This would be a good thing to add to paramaterized policies I'm sure.

In our installation, we have it so that if you make a task attached to a project, it sets the default visibility to that project.

Would you mind sharing how you did that? It would solve our problem util another solution is implemented.

We basically have two actual use cases in the wild here:

  1. Create a default Maniphest policy which allows the author to edit tasks: now possible through T5681 with the "Task Author" rule.
  2. Let Passphrase default to author as view/edit policy.

I think this task is actually a really bad idea and we should just store authorPHID on credentials and do an object policy check similar to "Task Author". I'm going to merge this into T5135 to track that.

In particular, as described, this task would make T6787 impossible: when we later went to check if a passphrase had the "default policy" or not, we would have no way to evaluate what the default policy was. Being able to do T6787 seems far more important than total higher-order purity of implementation here. The approach contemplated by this task was also potentially very complex.