You can't assign an issue to a group. You can create a mail group and then assign the issue to the user that uses that mail group address but other than that it is not possible to assign an issue to a jira group.
If you want to use a custom field in a project than you should put it in a screen that is used by the project. If you don't you can't see it in issues. But even if you put it in your project, it does not mean you can assign the issue to a group. It is just a custom field.
Elifcan is absolutely correct, the assignee field holds a user as the one single person currently responsible for the issue.
Adding a group picker for "this group is also responsible" is a very good approach to involving a group of people. There are other things you can look at too - see https://confluence.atlassian.com/jira/how-do-i-assign-issues-to-multiple-users-207489749.html
However, i am not sure this would be the best solution to me.
I will now explain what i need:
I want to assign issue to the QA team and than the QA team leader will reassign it to the relevant QA member. Once the issue is assigned to QA, the only person that will get the notification is the QA team leader and than he will choose the relevant person from the QA team.
What would be the best solution and how to make it work?
You can't assign it to a group (in real life, it doesn't work anyway)
For your case though, it is really simple. Assign it to the QA team lead. It's their responsibility to either deal with it, or delegate it by assigning it to someone else. For the notifications, just check that the notification scheme says that "issue assigned" and "issue updated" notify the current assignee.
If you want you can create a mail group as I described above and assign the issue to that mail group. Add every member of qa team to that mail group. It becomes something like a pool that every qa team can see. But as Nic said you can just assign it to the team leader too.
I'm adding to this old thread because we are considering Jira SD and our current system supports group based routing.
My approach was to explain to our staff how Jira queues differ from queues in our current system. In our current system a queue is a bucket. A ticket can be moved from one bucket to another group's bucket, and it can exist only in one bucket at a time. A Jira SD project is one big bucket, and the queues are just filtered views.
I created a field called "Assigned to Group" that defaults to our first tier Help Desk. It can be assigned to other groups like the Tier 2 Help Desk, onsite-support, DBAs and SysAdmins, etc. I have created queues, filters, and dashboard gadgets that filter to show unassigned tickets for a particular queue. If I want to, it looks like I could create an automation to notify the manager of a group if a ticket that is assigned to that group remains unassigned for too long, but we are really looking for a paradigm shift away from relying on email to provide customer service. If your role includes providing regular customer service, you will be expected to have the Service Desk tool open as regularly as you open your email. You will be responsible for what is assigned to you as well as what is assigned to your group and awaiting someone to take ownership.
I know some organizations have a hard time giving up email as the way they receive their assignments, but email is really terrible for providing customer service. Technically I could create a rule that emails an email distribution list whenever a ticket is assigned to the corresponding group, but I'm tired of enabling people who only want to watch their email. My ideal for the future, if I can get buy-in, is to use labels more and have people filter tickets based on labels for their areas of subject matter expertise (or some other assigned attribute like a department or a building they support).
Problem: Say we have a feature that involves two people simultaneously(real-world example; digging a well using conventional method, one guy digs and another guy at the top get the rubble out of well.) our feature involves something similar, I want both Alice and Bob work together on it. How can I do that in JIRA?
In this case I would create a STORY/TASK named "digging a well somewhere" and 2 SUBTASKS named "digging" assigned to Alice and "rubbling out" assigned to Bob.
Then the STORY should be assigned to someone. To Alice's and Bob's manager? Unassigned?...
Another approach could be creating an EPIC "digging a well somewhere", and then 2 STORIES/TASKS linked to that EPIC. Then assign STO1 to Alice and STO2 to Bob.
I cannot tell which method is better, there are a lot of variables.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs