Best way to add an issue to several assignees, is cloning issues the option?

[Pedro PerezGrande]

It may be a noob question, sorry if that's the case,

In my team, we have activities that need to be done by several people, like installing and configuring certain software in their machines, or make a 20 hours course for a specific technology, and I would like to manage this by jira, also thinking in the future incorporation of new members, so we have built a "NewCommersProtocol", 

What is the best practice for this matter?

Cloning issues for each new member?
Assigning as a subtask in the "mother issue" ?
any other option I have not figure out?

Ideally, the new comers should be assigned (in bulk) to this serie of issues (or to some of them), and being able to add coments/solutions to the "mother issue", like a wiki, at the same to keep a control how advanced are in this process. 

(because the addition of comments on this type of issues to improve the task, I would prefer if it exist only one issue that could keep track of this improvements)

also, it should be possible to assign more than one user at same moment on the same "task" (i.e. two employees are on the 20 hours curse)

Is JIRA able to manage this efficiently?

By the way, I have see the Bulk functionalities of edit and move issues, but not coping and duplicating them. In cloud, is the only way to do this by installing a third party add on like CLI ? 

thanks in advance !!

[Nic Brough -Adaptavist- · Accepted solution]

It does sound like you have a set of tasks to execute as part of one process.  I'd be strongly tempted to break it down with subtasks, as you suggest.  You can keep the workflow for the subtasks really simple, and you could even block comments on the subtasks with workflow properties to force people up to the parent to do it.

JIRA does not support many simultaneous assignees on one task because it does not work in real life - you need a clear single owner for a task at any one time (even if you change it lots without updating anything else, it's one person responsible at all times)

Without subtasks, your multiple assignee options are

• to use dummy "group" users
• use a group-picker
• (probably the clearest in this case) to create a multi-user picker to allow many users to be allocated to the issue

None of those work-arounds use the assignee field, so you'd have to educate your users that "no, it doesn't think you're assigned it, but you are because of this other field"

However, on Cloud, you are limited on what you can do, so you're a bit stuck on automatically creating subtasks.

[Pedro PerezGrande]

Hi Nick, thanks for the response:

"It does sound like you have a set of tasks to execute as part of one process.  I'd be strongly tempted to break it down with subtasks, as you suggest."

Indeed I have establish 33 issues to have in place for new comers, all with a description easy to identify and in a specific EpicLink easy to select, all enough granular to make one by one and (sometimes) in different order

The problem with the subtasks, is the need to go issue by issue adding the subtask assigned to the specific employee, plus the multiplication of issues on the list. On the other side, form the individuals point of view, they can have a easier monitoring of their progress

I guess I just dream with a functionality like this:   http://i.imgur.com/cIpkkLS.png

(sorry JIRA developers for the upcoming feature request pile it will come  ) 

[Nic Brough -Adaptavist-]

They've already explicitly stated that they will never do multiple assignees on issues, so you will need another way to do this. If you were on Server Jira, it would be easy - there are several ways to create the subtasks. I could actually get you very close to the screen you've mocked up as well. Another approach might be to have a single issue with multiple assignee/status fields too. So "new user" would have pairs of fields like: Old Employee - Assignee Old Employee - Status Medium Employee - Assignee Medium Employee - Status etc. You'd use the assignee type fields as single user pickers, and the status fields to indicate the current status. You still wouldn't have the system assignee from those fields, but you could generate the report you've shown

[Pedro PerezGrande]

Hi Nic, Thanks once again for the response "They've already explicitly stated that they will never do multiple assignees on issues, so you will need another way to do this." Yes, ans that's right, I am completely agree that one task should have only one responsible, That perfectly fine. Even more, in this case, by "project management theory" each employee should have his own task. (or subtask). The problem with that, is the overhead work, and the complication on the task list "If you were on Server Jira", But I am on cloud :_-( I presume that the two alternatives are: - create subtask for each user (cucumbersome) - create a field for each user to track progress (cheap work around, ) You mention: " a single issue with multiple assignee/status fields too." what type of fields are those and how can I set them up ? I would love to try out this posibility

[Nic Brough -Adaptavist-]

My last comment covered the user-picker fields I'd suggest. I'd probably go for a select-list for the status fields. Have a look through https://confluence.atlassian.com/display/JIRA/Adding+a+Custom+Field

[Pedro PerezGrande]

Hi again Nick is that what you mean ? http://i.imgur.com/T6uf1HW.png I have create a new type of issue and two custom fields, select List (single choice) Problem I see with this solution, I need to create a new field for each new user, and add the same list of values . It is not posible to clone fileds, or to raise a new instance of a (sort of) master field I show the user-picker fields, but I did not understand how that would work. I mean, you would have a field to select a username, but no way to assign to a status. Because as far as I can see, there is not "complex" or "concatenated" fields. Isn't it?

[Nic Brough -Adaptavist-]

Yes, that is what I meant. It's why sub-tasks are a far better approach, the only real weakness with them is that you can't automatically create them inside Jira With the user-picker fields, you'd need to add "User employe1" and "User employe2" to match the status fields (you can set these fields to select from roles or groups, rather than just "all users). The status would be a visual link only, there's no technical relationship between them.

[Pedro PerezGrande]

Thanks Nic for all your help I knew that subtask may be the ideal solution, but for our case it adds too much complexity We will try this approach, who knows if we will need to switch later, Best regards, and once again, thanks a lot