nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue ID usability

Inna S

Hi,

a newbie here.

I see several troubles with Jira Issue ID and would like to understand how this is ok for everyone.

1. There is no way to tell the issue type by looking at the issue ID. The only indication is the tiny icon that can mean one thing in one project and another thing in a different project. There is no text representation of it. It is against all the basics of the usability and I wonder if this can be changed.

2. Issue ID contains the project identifying prefix. So when we move issues from one project to the next, or rename a project, the issue itself has its ID changed.
This is a problem when we need to track items and refer to them externally.

I guess there is some internal ID for every issue and wonder if the Issue ID can be replaced by a custom field that would be a combination of the <issue type> + <running number within the issue type>?

Thank you

Accepted answers

All comments

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

1. Yes,, the issue key is for showing you the unique key of the issue. The issue type field is for seeing the issue type. In a lot of places, it's shown as an icon, so you should be selecting distinctive icons for them, but you can also hover the cursor over it to see the name.

I'm guessing you're coming from a legacy system which used the primitive and unhelpful trick of encoding the type into the key, leading to people having to be told what the cryptic thing meant.

Jira's view is more usable than that, you don't have to educate people on how it works.

2) Yes, the key reflects the project. Generally, moving an issue to another project is something you should be doing when housekeeping or when a genuine mistake happens where someone creates the issue in the wrong project. If you're moving issues between projects as part of a process, you've got a broken process and you should be looking to correct that. The issue lifecycle should be done by the workflow, not by changing projects.

Moving projects is recorded in the history, and the old key remains usable (note that it wouldn't if you encoded the issue type into it, this is one of the reasons has better usability than those legacy systems). If you move ABC-123 to DEF-456, you can still search for, or visit https://yourjira.atlassian.net/browse/ABC-123 and you will land on DEF-456.

So the short answer is "no". You can't replace the issue key with something less usable.

Inna S

Hi Nic,

appreciate your quick and elaborate response.

Unfortunately this confirmed my initial understanding about both the tool and the community.

Different organizations work in different ways and slapping a newcomer right away by telling them their work process is all wrong just because a tool does not support it is a bit strange.

Not everyone here has a 20:20 eyesight, some people are color blind and so using the tiny icon to convey a critical information is a big no in UI design. In fact it does not stand the UI standards.

Reassignment of the work item happens on a regular basis, this is normal.

Anyway, we will continue to search for the ways to adapt the tool to the business needs, even if it takes more effort and makes the work less intuitive.

Thank you.

Nic Brough -Adaptavist-

Of course organisations work in different ways, Jira is built with huge flexibility and power and supports many ways of working.

I'm not saying your process is broken because Jira doesn't support it, I'm saying the process is broken because it involves restructuring the entire issue and all the data on it, and moving it between different processes. A working business process has a single lifecycle for an issue.

It sounds to me like your processes have been broken by being forced to use a tool that doesn't work properly. Your processes shouldn't need you to re-engineer a data structure just becomes it gets reassigned.

I agree with you on the visibility thing, but that's why you can pick different icons for the issue types. When people's eyesight is bad enough to not be able to distinguish them, then they're able to use the tool tip (or even a screen reader), which would be a lot harder to do if the issue type were encoded into the key

Craig Nodwell_7eve9b

Hi @Inna S welcome to the community.
Quick question for you
Where are you viewing this "Issue Key" & "Issue Type Icon" combo? There may be ways to manipulate what you are seeing depending on where you are looking at it. Also yes, Jira does have an under the hood issue id. Issue Type icons should not change from project to project unless one project has an issue type that does not exist in another or the project is a Team Managed Project.

Inna S

Hi @Craig Nodwell , thank you for stepping in.

I see these everywhere. the Plan and My Work list are the worse because it does reveal the type even upon mouse over event, but they are also displayed in other locations.

We move work items from team to team all the time, especially when we need to consult one another, check things etc. Tracking items that keep changing their ID is a nightmare.

Not to mention the customer communication where the bug id would change depending on the team that handles it.

I plan to have company managed projects.

Inna S

@Nic Brough -Adaptavist- you do not really call a work process followed by a company unfamiliar to you 'broken' just because it is not what you are used to see, don't you?

Craig Nodwell_7eve9b

Hi @Inna S I wish I had better news for you. There is a feature request that you can vote on. On that request there is a suggested work around that you can probably implement again not the best but at least it is something.
Please note I do not work for Atlassian, I just like to help people.
Seems this has been an issue for a while now, and other people have felt your pain.
As per this post

Voting on the feature request will bring more awareness to the importance of this feature.

Inna S

Thank you @Craig Nodwell . Your input is helpful even if not encouraging . I just read the comments there and I'm now looking for an emoji of the head-banging-against-the-wall.

Voted for the request though.

Thank you.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud