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?

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.

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

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!

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

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.

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.

<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>

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

> 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