Page MenuHomePhabricator
Create Task
Maniphest T8795

Only allow one project of a given kind on a task at a time
Closed, WontfixPublic
Actions

Description

Projects are awesome, so we'd like to use them for everything. But in some case we'd like to enforce minimal rules about which can be selected.

For example, as you use a class of projects (same icon/color combination) to represent the affected code area (repository where the fix should land), you just want one of those areas to be specified at the same time on a given task, so that you can autoclose the task when that specific change lands.

Implementation-wise, you could for example mark certain projects as "unique" in which case only one of the "unique" projects in a given icon/color combination could be associated at the same time with any object.

The alternative here is to use advanced custom fields, but that would mean abandoning all the other benefits of Phabricator projects. Which would be sad.

Related Objects

Event Timeline

tcarrez created this task.Jul 8 2015, 12:22 PM
tcarrez raised the priority of this task from to Needs Triage.
tcarrez updated the task description. (Show Details)
tcarrez added a project: Projects.
tcarrez added a subscriber: tcarrez.
epriestley added a subscriber: epriestley.Jul 8 2015, 1:33 PM

Just to clarify, you aren't actually using Phabricator yet, and are just identifying this as a potential concern -- is that right?

This problem sounds like it could be the sort of thing that might seem like a problem in theory, but not actually be a problem in practice. For example, we have some exclusive projects on this install (like Badge Awarded and Hard) but haven't run into any difficulty with objects getting mislabeled, and I don't recall other installs reporting difficulty with this in practice either. General conventions, naming conventions, and use of icons/color can help structure and reinforce proper use of projects.

This isn't necessarily something we'd never build, but I'd like to see it be a practical issue in the wild before we'd think seriously about pursuing it on its own. A plausible technical approach might be via subprojects (T3670), e.g., "only allow a single subproject association", which might even be a universal rule for subprojects, although I'd have to think through that in more detail.

tcarrez added a comment.Jul 8 2015, 2:09 PM

Yes, we are not using Phabricator yet, although we should set up an instance very soon and migrate some projects to it to test it live.

This is more of an identified feature gap compared to how we use Launchpad currently. The on-going analysis lives at https://wiki.openstack.org/wiki/Phabricator if you're curious, but I intend to file all of them as tasks upstream to see how likely they are to be implemented one day.

On this one I'd agree with you, we could have some instance-wide policy and then try to enforce it (although you can't easily search for tasks that violate the rule).

epriestley added a comment.Jul 8 2015, 2:17 PM

There are some, uh, creative things you could do if the problem is limited in scope to a few specific conflicts, like write a Herald rule like this:

When all these conditions are met:
  [ Projects ] [ include all of ] [ Easy ]
  [ Projects ] [ include all of ] [ Hard ]
Take these actions:
  [ Add project ][ Difficulty Conflict! ]

Then you could search for tasks in "Difficulty Conflict!" to find problems. But this could maybe scale to, like, 2-3 pairwise constraints before it got silly and unmanageable. Still, you might only have fewer than 3 constraints that anyone has difficulty with with any frequency.

tcarrez added a project: OpenStack.Jul 8 2015, 2:53 PM
joshuaspence added a subscriber: joshuaspence.Aug 30 2015, 5:26 AM
revi added a subscriber: revi.Oct 28 2015, 12:40 PM
epriestley closed this task as Wontfix.Jan 20 2016, 2:56 PM
epriestley claimed this task.

I don't have any current plans to pursue this, per se, in the upstream.

A Herald rule like the one above (or custom Herald rules) could potentially reduce the cost of enforcing these rules as a general matter of policy. Milestones (see T10010) will actually enforce this rule (something can be in only one unique milestone of a given project), so you might be able to use milestones as a workaround after that lands (e.g., just call them whatever you want instead of "Milestone 1", "Milestone 2" and pretend they aren't milestones).

This request is also hypothetical and (as I recall) was really getting at a root issue of deployment/merging/version tracking. See also T9530 for release management in the upstream, although this is probably at least a year away.

Phabricator · Built by Phacility