-
Bug
-
Resolution: Answered
-
High
-
None
-
33
-
Severity 3 - Minor
-
10
-
Issue Summary
If you create a custom field in a team-managed (formerly next-gen) Project and the name already exists in the company-managed (formerly classic) global custom fields, using the field in a JQL search will break, causing any existing filters using this field to fail.
Note - The bug also impacts the JQL search in add-ons - e.g Slack integration, Teams, etc.
Steps to Reproduce
- Create a custom field in the global system settings (company-managed (formerly classic))
- Create a custom field with the same name in a team-managed (formerly next-gen) Project
Expected Results
The JQL basic and advanced search should recognize these are 2 different fields and continue to function accordingly.
Actual Results
Any existing filters using the company-managed (formerly classic) version of the field will break and going forward you can only query this field by using a different syntax that includes the field type
Workaround
- Simply rename one of the custom fields so there are no duplicates
- Use a different syntax for the field reference in your JQL which includes the field type (eg. "Chocolate[Number]")
- Use the custom field id in the Advanced search instead of the custom field name
- is related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Long Term Backlog
-
- relates to
-
-
- Closed
-
[JRACLOUD-75453] JQL breaks with company-managed (formerly classic) custom fields if a team-managed (formerly next-gen) duplicate exists
I whole heartedly agree with Nilesh, you should prevent the defect with better validation that advises the user they're using a restricted or duplicate field name. In my case a user created a next-gen project with a Story Points field conflicting with the classic project field, breaking all filters and queries.
This workaround is poor:
- Simply rename one of the custom fields so there are no duplicates
Because if you have multiple common custom fields that are the same field on multiple projects the following could the case.
To do the math if we have 9 NextGen Jira projects and there are say 15 fields that need to be altered per issue type minimum 3 to make Classic Jira working Then this means 9x15x3=405 changes would have to be made.
This is a burden that cost each Jira Admin work that we need to do. Where is the justification for this time for a change that was not expected and does not work naturally. If Atlassian is going to promote you can use Classic or NextGen Jira projects that have to have different names for each field that defeats the purpose of having common names that mean the same thing to the Jira user. ie. If I have to name thing like "Version Found" In and then have to use a different name such as "Found In Version" then training will need to be provided to each Jira user. This is not how the product should work.
Please resolve this as soon as possible and raise the priority to High please.
Hi lellis2@atlassian.com, nilesh.patel, 02bba1c12beb,
Following up as we have recently received more feedback on this behaviour of the JQL search. I understand the frustration this may cause for some Jira instances; Jira allows duplicate naming of fields and to resolve problems arising from that we still recommend to follow the workarounds outlined in this ticket above.
I agree that changing duplicate field names would be unnecessarily tedious - my recommendation would be to add the [fields type] parameter in JQL searches moving forward (as shown in the ‘actual results’ section of this ticket). By doing this, the JQL search will automatically create a list of values that will include possible options from every field that has the same name and type.
I hope this makes sense and is of help to you. Please reach out to me if you have any other questions.
Jordan