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

[Boris Zozoulia]

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

More on new user mgmt is here: https://community.atlassian.com/t5/Atlassian-Access-articles/Org-admins-can-now-rename-groups-in-cloud/ba-p/2276321

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

Fixes:

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.

Summary

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?

Cheers

[Boris Zozoulia]

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

https://jira.atlassian.com/browse/ID-8092

Let's see how is this progressing

[Boris Zozoulia]

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