-
Suggestion
-
Resolution: Unresolved
-
47
-
40
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
Assuming the following:
- I have a project named PROJECT with key PROJ
- I create a filter:
project = PROJECT
- If I rename PROJECT to NEWPROJECT then the field produces
Suggestion:
Is it possible to bind the search to the project key or issue type ID instead? That way, renaming a project should leave filters unaffected.
Workaround
Edit the filters to update the project or issue type names
OR
Just noting here that you can save a filter that refers to a project by its ID rather than its name. If you do this, the saved filter will not be broken if you change the project's name.
To find all your projects' IDs, go to https://<your site name>.atlassian.net/rest/api/3/project/search
In the following example the id of my project is 10084:
To use it in a filter's JQL you need to type project = 10084
After changing the project's name, the saved filter referring to the project's ID continues to work:
Whereas the saved filter that referred to the project name has broken:
- is duplicated by
-
- Closed
- is related to
-
- Closed
-
- Gathering Interest
-
- Gathering Interest
[JRACLOUD-30467] Renaming a project or issuetype breaks filters saved with the old project or issue type name
Despite the low number of votes, this is quite serious drawback. One rename operation destroys significant part of project/issuetype related functionality. Should it be a suggestion even? I'd say it is a Bug.
Moreover, when you rename issuetype/project - there is no warning or any indication of such drastic consequences.
This is true for "affectedVersion" and "fixVersion" as well i.e. if these versions get renamed, then the existing JQL queries which are written with these versions break.
The problem is not only with filters 
Project names in JQL can appear also in agile board (quick filters, card colors, swimlanes) and in Confluence (JIRA macro, chart macros etc.).
So if we want to change project name, it's not enough to change the strings in searchrequest DB table.
I totally agree with Ben, the decision to use the name instead of the PKEY is the major reason for this disaster. This is a call for using PKEYs by default on filters as they are clearly less likely to change in time.
Here are some starts from a JIRA instance with >200 projects, and >2000 filters. About 40% of the filters are broken, and ~90% of them due to project name changes, not keys, names.
Part of the problem is that the interface doesn't default to the project key convention. If you type 'project =', then select a project from the drop down list, it inserts the name, not the key.
It seems that the most logical solution however would be for JIRA to store the ID under the covers, but display the project name to the user.
Thanks Boris!
I started to audit our project filters and noticed that all of mine are pre-bound to project keys.
A few other filters that my teammates created are bound to project names. Looks like I need to bother them to change that convention...
dave.hong You can do stuff like project=ABC, not just project="project name"
Upvote - It's limiting us from developing the best solution for enterprise-level roadmap management within JIRA.