Page MenuHomePhabricator

Creating a new task in a project should inherit policies of that project
Closed, WontfixPublic

Description

Search didn't turn up anything obvious, so I'll just add this one here.

I've been experimenting a bit with private projects in our open Phabricator instance.

One potential problem that I see, is that it is very easy to create tasks for a private project which are open to everyone, as the "Create New Task" UI defaults to the global default. This is not only inconvenient but - given the need for human action to manually set this - is guaranteed to result in "leaks" due to tasks being created with incorrect policies.

I realize that the general case (setting the visibility when adding new projects) is probably difficult to implement and may have unfortunate side effects (what policies to use if multiple projects are added, etc).

However, for the specific case where you Create a New Task from a project view (i.e., pressing the "New Task" button from within "My Private Project"), it seems to me that it would be logical that the new task comes with the same visibility settings as the project that it is automatically tagged with.

Event Timeline

michaeloa raised the priority of this task from to Needs Triage.
michaeloa updated the task description. (Show Details)
michaeloa added projects: Projects, Maniphest.
michaeloa added a subscriber: michaeloa.

While The Right Solution comes, Wikimedia is implementing a simpler solution for the short term (like now, or yesterday). :) We have added a custom field to mark security tasks. It's not fancy but it is hard to miss. You can try it out in our test instance at https://phab-01.wmflabs.org/

Thanks - much appreciated. We've had a lot of benefit from following the Phabricator adaption process at WM.

I guess a more ideal solution than what I propose would be to have a setting in Projects that allow specification of what level visibility we want for tasks in that project, but short-term I'd be happy with anything that limits the scope for mistakes.

I would think that something like the simpler version could be implemented in the same way as {T389}

epriestley claimed this task.

We don't plan to have projects imply policies. There were some plans to do this long ago, but we moved away from it after some thought. In particular, it creates a lot of hard product questions which would always be difficult to understand (e.g., what happens when a task is in multiple projects? What happens when all projects are removed?). There's a bit of discussion in T390 and T3820.

We do plan to support top-level "namespaces" (T3820) which let you put groups of tasks into a "Security" or "Client A" or "Secret Project" space. This sounds like it might be a good fit.