Change maniphest tasks depending on project memberships.
Closed, WontfixPublic
Actions

Assigned To

Authored By

	OCram
	Nov 3 2015, 12:53 PM

Description

Our Situation

We do have multiple internal projects which run independently from each other. The project members should never see each other's tasks.

The Problem

When a user creates a new task, the default policy for 'Visible To' and 'Editable by' is "All Users". Now the user decides if his tasks contains critical information. In this case he should change the policy from "All Users" to his specific "main" project. The problem here is, that I have no control if this happens or if the user creates weird custom policies.
I already checked if Spaces could help us therefore, but it in best case the policy should be changed through phabricator itself and not by user.

There's currently no setting (per user or Herald rule) to change this for a large installation with independent projects.

So it really would be great if there were a possibility to react on this with a herald rule or something else. I think this would be more effective than believing on the users purpose :D

Related Objects

Mentioned Here: T9908: Temporary Guide to Edit Forms / ApplicationEditor Chatter
D14718: Document how to customize forms in ApplicationEditor
T8434: Accommodate the "Security" workflow
T9132: Build an ApplicationEditor abstraction

Event Timeline

OCram created this task.Nov 3 2015, 12:53 PM

OCram updated the task description. (Show Details)

OCram added a project: Herald.

OCram added a subscriber: OCram.

revi added a subscriber: revi.Nov 3 2015, 1:02 PM

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

In T9700#142970, @epriestley wrote:

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Ok, should I create a new tasks with the necessary information and layout, or reopen this one?

Either is fine.

OCram renamed this task from Allow Herald to change maniphest tasks policies to Change maniphest tasks depending on project memberships..Nov 9 2015, 11:30 AM

OCram reopened this task as Open.

OCram updated the task description. (Show Details)

I suspect T9132 will address this use case.

Specifically, you will be able to create "New X Task" and "New Y Task" forms with the correct defaults filled in (and, optionally, locked or hidden).

You can find some additional discussion on T8434. Generally, I want this workflow to involve modal choices before creating a task, not hidden implicit rules after creating a task. I think making this decision before hitting the "Create Task" form will result in a much more usable workflow.

The new tools from T9132 are now in HEAD (see D14718 for documentation, which will land shortly).

Upon rereading your description, I think these won't actually do what you want.

It is an intentional design decision that projects do not directly impact policies, and I have no plans to ever change this. In particular, I think the behavior when a task is in multiple projects is too confusing to ever be clear, straightforward, or easy to use. The projects may imply contradictory policies and users already have difficulty understanding policies without this additional complexity.

Instead, use Spaces, and change Spaces instead of changing projects to move a task between visibility areas. (Perhaps it would be helpful to think of Spaces as "Projects", and think of Projects as "Tags".) Spaces resolve the "multiple projects" issue by requiring that an object be in only one space, so the policy behavior is straightforward.

In T9700#147847, @epriestley wrote:

The new tools from T9132 are now in HEAD (see D14718 for documentation, which will land shortly).

Upon rereading your description, I think these won't actually do what you want.

It is an intentional design decision that projects do not directly impact policies, and I have no plans to ever change this. In particular, I think the behavior when a task is in multiple projects is too confusing to ever be clear, straightforward, or easy to use. The projects may imply contradictory policies and users already have difficulty understanding policies without this additional complexity.

Instead, use Spaces, and change Spaces instead of changing projects to move a task between visibility areas. (Perhaps it would be helpful to think of Spaces as "Projects", and think of Projects as "Tags".) Spaces resolve the "multiple projects" issue by requiring that an object be in only one space, so the policy behavior is straightforward.

The upcomming changes within T9908 helps us a lot. So I think you're absolutely right and I can solve our problems with the new editable Maniphes Task Creation forms. Thank's a lot for your support!