-
Suggestion
-
Resolution: Low Engagement
-
None
-
1
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
Currently when creating agile board filters, you add a project's name. This should be changed to the project's key. The name of the project can be editied/updated and then the board filter's are broken. But, if the project key is used, which cannot be edited, then changing the project name will not break board filters.
- is related to
-
- Gathering Interest
- relates to
-
- Closed
-
- Closed
-
- Closed
[JRACLOUD-37353] Agile Board Filters Should Use Project Key
Now that project keys can be updated, this issue is no longer valid and should be closed.
Hans-Jürgen Tappe
added a comment - Hello Philip, working around frontend issues on database level is not a viable option here. I would assume that this would be an option in small size environments only.
Hans-Jürgen Tappe
added a comment - Hello Philip, working around frontend issues on database level is not a viable option here. I would assume that this would be an option in small size environments only. 
Philip Schlesinger
added a comment - Hi Hans,
Do you have SQL database access? If so, you can modify them in the database...and I think you don't need to restart JIRA to have the changes recognized (I could be wrong, but I think JIRA does not cache filter queries)
Philip Schlesinger
added a comment - Hi Hans,
Do you have SQL database access? If so, you can modify them in the database...and I think you don't need to restart JIRA to have the changes recognized (I could be wrong, but I think JIRA does not cache filter queries) Hans-Jürgen Tappe
added a comment - The integrity checker might help me to find the filters - but I still cannot modify them if I don't own them (which I would if I could).
I believe the default behaviour should use the project ID not it's name to build a filter. It also becomes shorter and more readable in the advanced filter mode and when sharing filter URLs by e.g. mail.
Hans-Jürgen Tappe
added a comment - The integrity checker might help me to find the filters - but I still cannot modify them if I don't own them (which I would if I could).
I believe the default behaviour should use the project ID not it's name to build a filter. It also becomes shorter and more readable in the advanced filter mode and when sharing filter URLs by e.g. mail. I agree with the need for this.
FYI there is a free Integrity Checker plug-in for JIRA which will check for broken filters.
Philip Schlesinger
added a comment - - edited I agree with the need for this.
FYI there is a free Integrity Checker plug-in for JIRA which will check for broken filters. Hans-Jürgen Tappe
added a comment - This also affects us here. The project key never changes on our side as it connects to so many places. The project key is also a handled as a clearly technical identifier. We would rather create a new project with a new key and migrate the issues rather than changing the project key of an existing project.
Nevertheless, changing the project name should not affect the tool behavior. There is a scenario where the scope or the focus of a project is adapted during the project life time and this should be reflected in the project name.
Today, even as an administrator, I am not able to change the project name because it will render all agile boards and project filters (which were not manually set to use the project key) unusable (and I cannot change the filters if I do not own them). This feels more like a program usability error than an inconvenience.
Thanks for considering this as a possible enhancement.
Hans-Jürgen Tappe
added a comment - This also affects us here. The project key never changes on our side as it connects to so many places. The project key is also a handled as a clearly technical identifier. We would rather create a new project with a new key and migrate the issues rather than changing the project key of an existing project.
Nevertheless, changing the project name should not affect the tool behavior. There is a scenario where the scope or the focus of a project is adapted during the project life time and this should be reflected in the project name.
Today, even as an administrator, I am not able to change the project name because it will render all agile boards and project filters (which were not manually set to use the project key) unusable (and I cannot change the filters if I do not own them). This feels more like a program usability error than an inconvenience.
Thanks for considering this as a possible enhancement. This is a must have. I would expand the scope to all filters and not just agile board filters though.
@Jose, I agree that it would be nice to have filters still work if either the key or name of the project changes BUT the importance of the project name is fairly critical and I'd take it sooner if it didn't include support for changing keys.
Jose (Ericsson GmbH)
added a comment - Agree, it would be better if the project key is used, but would it solve the problem, if the project key changes?
Project name and Project key are both important and should be updated in all places at the same time. Otherwise, JRA-2703 (As an Admin, I want the ability to edit a project's key) is not fully resolved.
Jose (Ericsson GmbH)
added a comment - Agree, it would be better if the project key is used, but would it solve the problem, if the project key changes?
Project name and Project key are both important and should be updated in all places at the same time. Otherwise, JRA-2703 (As an Admin, I want the ability to edit a project's key) is not fully resolved.
Hi everyone,
Thank you for bringing this suggestion to our attention.
As explained in our new features policy, there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritize and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.
Unfortunately, as a result of inactivity (no votes or comments for an extended period of time), this suggestion didn’t make it to the roadmap and we are closing it.
While this issue has been closed, our Product Managers continue to look at requests in https://jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket.
Thank you again for providing valuable feedback to our team!