[#JRA-6053] restrict assignees by workflow

JIRA

restrict assignees by workflow

Created: 26/Feb/05 10:52 AM Updated: 08/Nov/07 07:25 AM

Component/s:

Workflow

Affects Version/s:

3.0.3

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue duplicates:

JRA-6381 Permissions per workflow step / state

Part

This issue is incorporated by:

~~JRA-7456~~ default assign to is wrong

Reference

This issue relates to:

JRA-6126 Limit "Assign To" list to specific user group

Participants:	Anton Mazkovoi [Atlassian], Jeff Turner [Atlassian], Neal Applebaum, Nick Menere [Atlassian] and Nikolay Gorbunov
Since last comment:	36 weeks, 3 days ago
Resolution Date:	29/Dec/05 06:43 PM
Labels:

Description

« Hide

As in one of your competitor's products, I need the ability to restrict assignable users not just by Project but also by workflow status within the project. So, if an issue is being resolved, I would like the assignable user list to include only those members of the project (i.e. the QA department) that should test a resolved issue. Otherwise, developers tend to make mistakes and resolve issues to other people, or even to themselves.

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Neal Applebaum - 01/Mar/05 10:22 PM

I'm finding the users are resolving issues without re-assigning them. I'm constantly cleaning up the "resolved issues" list because the drop down is showing too many users for "resolve" to.

[ Permlink | « Hide ]

Neal Applebaum - 17/Sep/05 01:49 PM

Is there any chance this could make it into a release soon? It is the biggest complaint I have with JIRA.

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] - 18/Sep/05 08:39 PM

> Is there any chance this could make it into a release soon?

Unfortunately at the moment I cannot make any promises for the release date as this issue has not been scheduled. This issue will require quite a bit of effort to implement and I am almost certain due to this fact it will not make JIRA 3.5, as there are currently quite a few issues that are 'competing' for a spot there.

That said, we realise that adding this fucntionality to JIRA will make it a lot more useful. So we are keeping this issue in mind.

Thanks,
Anton

[ Permlink | « Hide ]

Neal Applebaum - 19/Sep/05 08:01 AM

OK, thanks. As an alternate I was going to sign up as 50 different accounts, and add 50 votes... er.. just kidding

[ Permlink | « Hide ]

Neal Applebaum - 23/Dec/05 08:36 AM

<tickler>
Just a reminder that this would be very helpful to me. Each project has a group of developers and a group of QA. When resolving an issue to a tester to test, it should only be the QA people that can be assigned the issue. This is the only issue where JIRA falls fall short of other systems with regards to workflow. Thanks
</tickler>

[ Permlink | « Hide ]

Jeff Turner [Atlassian] - 29/Dec/05 06:43 PM

I have to 'lose' votes here, but this is in fact a duplicate of JRA-6381 - permissions per workflow step. The permission here is 'Assign Issues'.

There is a plugin which makes this possible linked to from JRA-6381.

[ Permlink | « Hide ]

Neal Applebaum - 30/Dec/05 11:43 AM

Jeff, with all due respect, I do not see how the linked issue is a duplicate. My concern is not PERMISSIONS based on workflow - it's the assignable user list. Anyone can assign an issue, or resolve an issue, but when resolving an issue, the assignable user list needs to be a completely different list/group of people than when assigning an unresolved issue. The typical use case is when an issue is assigned to development to fix, and then assigned to QA to test. If you say you would like to address both issues in the same release, that's fine. But JRA-6381 is a completely different request - the ability to constrain WHO can do what, as opposed to who can be assigned an issue. The only mention on that issue of assignable users is a recent comment by Jakob, which is kind of off topic from the original request.

[ Permlink | « Hide ]

Nick Menere [Atlassian] - 02/Jan/06 07:28 PM

Neal, we believe it is a duplicate because the list of who can be assigned to an issue is based on the Assignable User permission. There for, if you can specify this permission on a per Transition or State basis, you will be able to restrict that list to who you want.

Cheers,
Nick

[ Permlink | « Hide ]

Neal Applebaum - 02/Jan/06 08:34 PM

OK - I get it now. The technical aspect of the linked issue's description is what threw me. Now it just needs to be scheduled!

[ Permlink | « Hide ]

Nikolay Gorbunov - 17/Aug/07 07:06 AM

In 3.8, the Assignable User permission is still not transition/state-driven. Do I miss anything?

[ Permlink | « Hide ]

Neal Applebaum - 17/Aug/07 07:35 AM

Do I miss anything?

Yes - what you missed is that this was resolved as a duplicate, and the main issue is still unresolved meaning we still don't have this functionality.

[ Permlink | « Hide ]

Nikolay Gorbunov - 08/Nov/07 07:25 AM

X-posting my comment from JRA-6381:

Allowing an issue to get assigned to a member of different group than one which should be responsible for handling the issue in a given state can result in losing the issue which's really bad.

E.g. if I transition the issue to "To Be Documented" but assign it to Peter which's a QA guy (say, by mistake), the issue will likely get lost because Peter knows he never gets issues in "To Be Documented" and may have filters saved which prevent him from seeing those.

Email notifications on "Issue Assigned" event partly help, yet they don't give a warranty unless Peter is 0% lazy and has less than 200% workload.

As a possible implementation, there could be a Group Picker-like (or Multi Group Picker) field on the "Update Workflow Step" screen, named "Assignable Group/s". This will enable to bind assignable users to workflow steps on a per-group basis; this binding may be then ANDed with "Assignable User" permission with no need to make it dynamic.

What do you think?