Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Group renaming eligibility criteria fails for renaming groups in Jira (new user management experienc

We have recently been migrated to the New user management experience, whereby we can rename our groups.

More on new user mgmt is here:

Our jira service management instance contains lots of data.

Group renaming eligibility criteria

Attempting to rename a group prompts the eligibility criteria for group renaming, and stops us from renaming the group

  1. Assets
  2. Group pickers Custom field
  3. Filters


1. Assets eligibility is fixed easily
We have a custom asset attribute pointing to the jira group - just remove the group value in question

2. Group pickers (custom field) eligibility
Ideally, we should see the custom field's name violating the eligibility criteria.
It took us a while to understand, that eligibility criteria here is our "Assignment group" field.

While the eligibility link in the popup dialogue points to the Custom fields configuration in Jira, this is wrong, as this particular case means that we have a number of issues that are assigned to the group we are trying to rename. This is nowhere documented!

The only way to fix this - is to create a temporary-named-group and assign all the issues assigned to the group to be renamed to the temporary one, via JQL and Bulk update. Then we would rename the group, using the same bulk update assign the issues back to the renamed one. Seems to be a tedious process.

I have run a rest API to extract the issue. Checked an assignment group value in it, and can see that the assignment group is referred to by name, and not by id. Since this is the reason why eligibility criteria fail, are there any plans to update these?

3. Filters eligibility
Somewhat similar to the above - I had to extract all filters via rest API, take note of which ones I have to modify and remove the hardcoded group name, rename the group, and then modify the filters.

I understand JQL is a text, thus the values for the fields will be stored in text format, not via IDs or anything. Is it really necessary then to introduce a stop on eligibility for filters, rather than issuing a soft warning for users to remind them to update such and such filters?

What is missing in the eligibility criteria

1. Automation, where automation assertions refer to groups (by names again, not by IDs) I believe you have accepted that automation is a problem, but this is not highlighted in the renaming eligibility criteria.
2. Queues
A restful API /rest/servicedeskapi/servicedesk/${servicedesk_id}/queue - will list all the queues in our instance, and we need to take note of which ones we will need to modify later.


This is somewhat of a long post, so to summarise

  1. Can the "group renamer" functionality be more specific on which fields require to be looked into?
  2. Why the issue JSON content refers to the Assignment group field values via Group name, rather than via ID?
  3. Can the "group renamer" functionality be more specific on which filters users need to look into? We contain around 1000 filters, and without the Jira cloud REST API knowledge, it is nearly impossible to identify those.
  4. Are there any plans to include automation references and Service desk queue references in the eligibility criteria?


2 answers

I have found the following Jira tracker for the very similar question in the subject:

Let's see how is this progressing

Omg - posted to ops genie - should be in Jira cloud - can one move it please ?

Suggest an answer

Log in or Sign up to answer