Page MenuHomePhabricator

Upgrading: Maniphest field-level policies ("Can Prioritize Tasks", etc.) have been deprecated and will be removed
Closed, ResolvedPublic


2015 Week 49 is the last stable cut not impacted by this change.

Maniphest currently has several field-level policies configurable in ApplicationsManiphest. Specifically:

  • Can Edit Task Status
  • Can Assign Tasks
  • Can Edit Task Policies
  • Can Prioritize Tasks
  • Can Edit Task Projects

These policies are deprecated. At HEAD, these policies are still in force, but they are not respected in the UI and setting them to anything other than "All Users" may result in policy errors. Installs are advised to:

  • Use form customization to adjust workflows instead. See User Guide: Customizing Forms for instructions, examples, and descriptions of use cases.
  • Set these policies to "All Users".
  • Expect these policies to disappear completely in the future.

These policies are being removed because:

  • they are not general (other fields do not have them; other applications do not have them), but object editing now is general;
  • a general version of these policies would be nightmarishly complex to implement in a usable way; and
  • all use cases we are aware of are about workflow tailoring, not actual access control, and form customization is a better (more general, more powerful) tool to achieve workflow goals.

Broadly, having field-level policy controls implies a huge level of additional product complexity to implement properly. For example, D14359 + D14683 add new "Change Status To: ..." and "Change Priority To: ..." actions for tasks in Herald. If we retain field-level policies for these fields, this creates product questions like:

  • Can a user create Herald rules using these actions?
  • Can a user edit a global rule another user created which uses one of these actions if they can't use the action?
  • Can a user change the action value of the action in another user's global rule?
  • If a user writes a rule with one of these actions and then loses permission to take the action, does the rule still work?
  • If the answer to any of these is "no", how do we communicate it clearly in the UI?

Questions like this repeat all over the product: in Conduit, in email actions, in CLI workflows like arc todo, in Workboards (dragging tasks in a priority view), and in other interactions between applications (like Fixes D123 in commits), and even within Maniphest itself (resolving an unassigned tasks normally assigns it to you).

While all of these questions are probably tractable, all use cases we're aware of for these settings are exclusively focused on tailoring workflows for less experienced users and/or random users, particularly on open source installs. There is no need to resolve complex questions about Herald interactions in any of these use cases, because they are about simplifying workflows and preventing mistakes, not truly enforcing field-level policy controls.

If you have a strict policy concern which you currently resolve through use of these controls, please describe it below and we can try to help you work through it. My belief is that no such cases exist, and that all existing cases are better served by form customization, which is substantially more flexible.

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley changed the edit policy from "All Users" to "Community (Project)".
epriestley added a subscriber: epriestley.
epriestley renamed this task from Upgrading: Field-Level Policies have been deprecated and will be removed to Upgrading: Maniphest field-level policies ("Can Prioritize Tasks", etc.) have been deprecated and will be removed.Dec 16 2015, 6:31 PM
NOTE: We do not use Maniphest field-level policies any longer, but since the topic had been silent, I figured I'd share.

Re: A "Strict Policy" concern description

We're an Independent Software Vendor and Application Service Provider for a Free Software product, that uses Phabricator for inbound email on support@ and sales@, among other such addresses (think postmaster@, etc.), alongside the web-based interface of course, and git for our DevOps for the ASP environment and other corporate infrastructure.

As such, we interact with community members, colleagues, partners, partners' corporate customers, corporate (direct) customers and individual end-user customers about things ranging from development topics and sales leads all the way to end-user support requests. Our system therefore contains privacy- and security-sensitive information.

We currently have a default "Visible To..." and "Editable By..." Custom Policy that contains;

  • ManiphestTaskAuthorPolicyRule (allow),
  • PhabricatorSubscriptionsSubscribersPolicyRule (allow),
  • PhabricatorAdministratorsPolicyRule (allow),
  • default (deny)

"Subscribers" to a task will generally include one or more projects, such as a Support team project and an Example account project.

Users being Human Beings (TM), provided the technical possibility to change these view and edit policies, we expect it is only a matter of time before someone (un)intentionally discloses information to an audience wider than the audience intended.

Current Implementation

While we used to, but not any longer, enforce policies on Maniphest Tasks using these field policies, obviously we understand that such doesn't apply for other objects (where we may require the same "strictness" soon enough).

Instead we seek to develop and employ a custom HeraldAction to revise the view and edit policies on objects, should they have deviated from the defaults.

For as far as our current implementation (still under development) goes, it may be found here.

There's likely some problems with the implementation, such as "bluntly" creating new policy objects rather than trying to find existing ones (such as the old one), but I don't know how to get to the old one yet. Note also it uses a relatively poor implementation of comparing current and desired policy rule sets.

@vanmeeuwen couldn't you use custom forms to lock/hide the policy controls on the maniphest task submission / edit forms? That's how we handled it at Wikimedia's Phabricator. As mentioned above, Custom Forms is the general way forward for controlling default task policies.

These are actually removed in 2018 Week 33. See T13186 for a small amount of followup and discussion, although there isn't too much new information beyond what's here.