-
Suggestion
-
Resolution: Fixed
-
None
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
Since we've ended project key format support on JIRA 6.
- Is it possible to provide an update task for the user who is using the customized project key to migrate the project key to the normalized project key?
- Also the measurement regarding to the project key using in the remote link to other application?
- Is there any exception character and symbole that the user can continue to use?
- is detailed by
-
- Closed
- is related to
-
- Closed
[JRACLOUD-31852] Provide a better way to handle the project key migration
This one require to have the number using the project key as an exception.
Intel CHD Jira Admin
added a comment - In https://support.atlassian.com/browse/JSP-149557, I was asked to communicate our concerns in this issue. So here goes:
We are now aware that as of Jira 6 Atlassian will no longer support customized project key patterns. Let me describe our situation and then rely on you to guide us through the migration:
- Here is our customization:
jira.projectkey.pattern = ([A-Z|A-Z][A-Z0-9\_|A-Z0-9_]\+)
- We have many projects with "_" and/or digits in the key.
Note that our original purpose in customizing the key was not to add a delimiter, but to add digits. We have many projects that have numbers in the name and distinguish themselves from each other by number. What were we to do? Project keys like "GRXTHREENINEZEROZERO" AND "GRXTHREENINEONENZERO" are impossible. So we have GRX3900 and GRX3910. A little better, or? 
It really surprised me that the project key was limited to letters. Apparently this is still the case. ("By default, the JIRA project key configuration requires two or more uppercase alphabetical characters - based on the regular expression ([A-Z][A-Z]+)." - https://confluence.atlassian.com/x/XgISCw) I didn't worry about this madness then because it was possible to customize the key pattern.
- We have many external references to issues in projects with "_" and/or digits in the key: Fisheye/Crucible, Confluence (full URLs in text as well as jiraissue macro), other webpages (e.g. MS sharepoint).
- We have issue IDs hardcoded into Mercurial changeset comments that cannot be changed. (Changeset comments are immutable.)
Constraints:
- We have to have digits or something equivalent. Please provide a solution or reasonable alternative.
- External references must still work. In particular, it is crucial that the immutable issue IDs in Mercurial repos be recognized and traced to the right issues in Jira by fisheye.
- We can move away from underscore, but we must have a reasonable way to change the database. Neither of the procedures described in https://confluence.atlassian.com/x/d4D_Eg is acceptable: Option 1 because we lose external links and Option 2 because we cannot recreate projects with thousands of versions in different states, components, role lists, etc. You've got to come up with something better. (In https://jira.atlassian.com/browse/JRA-2703, people are also saying that bulk move changes the issue numbers; this is a non-starter! It is also said there "We currently plan to solve it by providing a means to copy a project (and the versions, components, etc), making the workaround much easier... we will not be addressing this feature request in the next 12 months" The idea may be right but the timeline is wrong. This must be available with Jira 6.)
I have to say that I am very unhappy with Atlassian for the first time. If you planned to phase out key customizations, then you should have had a "transparent" solution available to customers that have used the feature in good faith, along with the phase out. Now it looks like you support guys are playing catchup and providing nonstarter "solutions" like https://confluence.atlassian.com/x/d4D_Eg. 
In this page others raises many of the same issues that I have: https://answers.atlassian.com/questions/109118/jira-end-of-support-for-project-key-format-configuration-in-jira-6-0.
Intel CHD Jira Admin
added a comment - In https://support.atlassian.com/browse/JSP-149557 , I was asked to communicate our concerns in this issue. So here goes:
We are now aware that as of Jira 6 Atlassian will no longer support customized project key patterns. Let me describe our situation and then rely on you to guide us through the migration:
Here is our customization:
jira.projectkey.pattern = ([A-Z|A-Z][A-Z0-9\_|A-Z0-9_]\+)
We have many projects with "_" and/or digits in the key.
Note that our original purpose in customizing the key was not to add a delimiter, but to add digits. We have many projects that have numbers in the name and distinguish themselves from each other by number. What were we to do? Project keys like "GRXTHREENINEZEROZERO" AND "GRXTHREENINEONENZERO" are impossible. So we have GRX3900 and GRX3910. A little better, or? It really surprised me that the project key was limited to letters. Apparently this is still the case. ("By default, the JIRA project key configuration requires two or more uppercase alphabetical characters - based on the regular expression ( [A-Z] [A-Z] +)." - https://confluence.atlassian.com/x/XgISCw ) I didn't worry about this madness then because it was possible to customize the key pattern.
We have many external references to issues in projects with "_" and/or digits in the key: Fisheye/Crucible, Confluence (full URLs in text as well as jiraissue macro), other webpages (e.g. MS sharepoint).
We have issue IDs hardcoded into Mercurial changeset comments that cannot be changed. (Changeset comments are immutable.)
Constraints:
We have to have digits or something equivalent. Please provide a solution or reasonable alternative.
External references must still work. In particular, it is crucial that the immutable issue IDs in Mercurial repos be recognized and traced to the right issues in Jira by fisheye.
We can move away from underscore, but we must have a reasonable way to change the database. Neither of the procedures described in https://confluence.atlassian.com/x/d4D_Eg is acceptable: Option 1 because we lose external links and Option 2 because we cannot recreate projects with thousands of versions in different states, components, role lists, etc. You've got to come up with something better. (In https://jira.atlassian.com/browse/JRA-2703 , people are also saying that bulk move changes the issue numbers; this is a non-starter! It is also said there "We currently plan to solve it by providing a means to copy a project (and the versions, components, etc), making the workaround much easier... we will not be addressing this feature request in the next 12 months" The idea may be right but the timeline is wrong. This must be available with Jira 6.)
I have to say that I am very unhappy with Atlassian for the first time. If you planned to phase out key customizations, then you should have had a "transparent" solution available to customers that have used the feature in good faith, along with the phase out. Now it looks like you support guys are playing catchup and providing nonstarter "solutions" like https://confluence.atlassian.com/x/d4D_Eg .
In this page others raises many of the same issues that I have: https://answers.atlassian.com/questions/109118/jira-end-of-support-for-project-key-format-configuration-in-jira-6-0 .
The declared supported characters in project keys has been expanded to allow numbers and underscores.
Also we completed
JRA-2703in v6.1, so you can now edit project keys.