How do I assign issues to multiple users

[Tao Shen]

The users like to assign issues to multiple users via a User Account as described here:

https://confluence.atlassian.com/jira060/how-do-i-assign-issues-to-multiple-users-370705091.html#HowdoIassignissuestomultipleusers-ManagingIssuesviaaQueue

From a policy point of view.

The Generic Email User Account requires to be assignable (to Assignee) but must either:

1. not able to login or

2. applies password rotation expiry. 

Both of which does not seem possible in JIRA CORE while the user remains assignable?

Any ideas how I can achieve this?

Tao

[Danyal Iqbal]

This is not a best practice, not even  good one. Never assign issues to multiple users. It will blow up in your face sooner than you think. However, if you must: add a user picker custom field to the issue and configure the notification scheme to send emails to user picker field

P.S: Use Watcher function to send email notifications to multiple receipients. Clone the issue to a different project and  give assignable user permission to only the relevant user group.

[Nic Brough -Adaptavist-]

Jira's assignee field is a single user because of exactly that - multiple assignees invariably goes wrong (except in pair programming).  I've yet to visit a place where multiple assignees has not gone wrong, one case only had three developers and it still went wrong.

[Tao Shen]

The users has been using this process for many years. It is familiar, simple and to be frank I can't fault it. If you have an accountable team I don't see the problem.

Is it possible to setup a notification scheme such that when assigned, another email is sent to somewhere else?

[Nic Brough -Adaptavist-]

I very much doubt that it works, just that they've missed stuff and not seen the fail, but it doesn't matter in Jira as you rightly can't do it.

Yes, you can amend the notification scheme to send elsewhere.

[Tao Shen]

just realised the answer to my own question was right in front of me.

Use a non-internal directory to manage the group(user) authentication. The group account will always fail thus prevented from login.

[Gezim Shehu [Communardo]]

Sorry can I ask which is the benefit of this?

You could just add everybody as a watcher/participant  and easily do the filtering on that.

[Tao Shen]

So that assigned group members are able to view the shared inbox.  Anyone or the roster user can progress the issue.

Are you saying it is possible to notify all members belonging in a Jira group when the issue is assigned to a particular user? i.e. watch a user!

[Nic Brough -Adaptavist-]

No, you'd notify the group when anyone is assigned to it.  You'd need code to do it by user.

[Gezim Shehu [Communardo]]

Hi Tao,

ScriptRunner, as Nic says is certainly the way to go. Though, with some creative thinking you could get around this.

1-There is a free add-on watcher custom field, which syncs with the watchers field, this way you could update it using a simple post function.

2-There is a component watcher free add-on, same as previous, but on component basis

3-If you have any email addon, you could also use that to notify user from groups, or fields.

Though any of the above, are wrong choices in my opinion.You are basically pushing 1 issue to x people.

Why not use a pull approach and let everything be  created unassigned. You could use built in "escalation filters", saving JQL filters (for example new issues unasssigned) and subscribe that filter to mail every 10 mins.

[Tao Shen]

Hi Gezim.

I do like the pull approach, it has a lot of merit and something worth exploring further. It would require a change to their workflow which has over the years simplified to human decision (i.e. which group to assign) making.

[Gezim Shehu [Communardo]]

I get it, people don't always like change :P.

What you are describing really is the oldest approach, compared to pull at least. Anyway you have to understand that people, at least here, will always "fight" you for this old approach, even though it seems it's not up to you lol.

You could run a small demo though. Why not select a group of issues or even a new project, with low priority of course, and try to implement there and see the reaction.

Br