Maniphest currently has several field-level policies configurable in Applications → Maniphest. 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.