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; } } }

Please HELP, how can I customize a request number according to its request type?

Mela

We have 3 different types of requests:

1.) Service Request

2.) Incident Request

3.) Problem Management Request

My plan is to customize their own request number like these

1.) Service Request - SR0001

2.) Incident Request -IR0001

3.) Problem Management Request - PM0001

How can I possible do this? Please Help

Accepted answers

Nic Brough -Adaptavist-

It is possible to get close to this, but not quite 100% there, and you probably won't want to implement it this way as it fragments your issue tracking.

A Jira issue key is always formatted as <ABC>-<XYZ>. The ABC is the project the issue belongs to, and the XYZ is a numeric sequence. So the "not quite" bit is that you can't have keys without a hyphen or with leading zeroes. SR0001, IR0001, and PM0001 will be SR-1, IR-1 and PM-1. (I'm guessing your desire for your format comes out of having used a legacy tracking system which uses it. If so, you should examine that - is it really of any good use for your humans?)

The bit you probably don't want to do is the projects - you can lead each key with a different piece of text, but you can only do it by having separate projects. For your text, you'll need three projects, one for service requests (key SR), one for Incidents (key IR) and another for Problems (key PM)

All comments

Fabio Racobaldo _Catworkx_

Hi @Mela ,

unfortunately you can't change issue key in JIRA. it is the aggregation on Project Key - ticket number within your project.

Keep in mind, that if you have another project with the same request types, the same number could be not unique in your instance.

Hope this helps,

Fabio

Nic Brough -Adaptavist-

It is possible to get close to this, but not quite 100% there, and you probably won't want to implement it this way as it fragments your issue tracking.

W_38l5et

This is nightmarish... considering you forbidden the users from imparting custom sort orders on EPIC children, it means that when you create the children, you MUST create them in the order they are going to be worked or you have highly inefficient work processes.

Say an EPIC has 20 children, say backend and frontend and testing and infrastructure all create their EPIC children independently... step 2 is for a project manager, or scrum master if you insist, to sequence the tasks. One can go and put blockers, that should hopefully stop people from starting something they shouldn't... but you have to click into each of the 20 children to find what is workable.

In the end, devs need an ordered list of things to work and trust in the automation and manually processes people work to put them together... Jira by omission and preferences, does not provide the ability to achieve it.

Hence, now we are trying to swap ticket numbers to get a reasonable order on an EPIC child list. Can't even save the setting for default sort order. It's really unbelievable, the primary workflow management approach in a workflow management tool is effectively unusable if you care about efficiency of your staff.

W_38l5et

Even worse, you do allow reordering of subtasks on stories.... my assumption is that the decision to do it one place but not the other was not intentional. Seems completely arbitrary, not giving me much confidence in the tool... reporting rarely works to boot.

Nic Brough -Adaptavist-

All of this seems like you have not quite grasped what Agile is for (and Epics within it). You're still thinking in a Waterfall manner where you plan at the top level (Epic), and then try to chop it up into pieces to be allocated out.

In Agile, your product manager works with the customers to find out the various things they want or need, and creates appropriate stories. When you realise you've got related stories and themes starting to emerge from these conversations, you attach them to Epics. Of course, you need to bear in mind that the stories may change, and more will continue to be added as the teams explore the work.

Jira Software supports Scrum and Kanban. Scrum has a backlog, where your teams rank the stories according to what needs doing next (and you can enable one for Kanban if it might be useful)

I would not recommend trying to use Jira Software for Waterfall, it's just not built for it. But if you need inflict it on your teams, you can do it - just take away all their autonomy in a Scrum project, so that they cannot rank. That's not going to fix your "ordering by numbers" problem, but that's a less than ideal way to organise any project anyway, it's better to rank things.

Subtasks are wholly a part of their owning issue, and can be re-ordered in the issue view, but because they're fragments, their order isn't too important to an Agile team - the team understands all the dependencies in their already.

W_38l5et

I mean, my friend, both agile and waterfall are extremes, two massively far apart areas of a contiguous spectrum. Neither exists 100% in any regard in the rigidly defined way you are implying, at least not in a functional company. Agile is not the first, nor will it be the last, attempt to teach basic project management and software lifecycle development to folks who just write code. The inherent tradeoff between the spectrum of agile and waterfall when designing a workflow and software lifecycle for any given project, in any given environment, is certainty vs. agility. Yes the web world needs agility over certainty, the winning business is often just that because they were the first. That being said, these tradeoffs are nothing new. In fact, the inventor of agile regrets it; I get the impression that it's been used as a excuse, when it was only really intended for illustrative purposes in teaching the basics, just as waterfall was. No practical approach to managing work is pure waterfall, when building a fighter jet, there are revisions.... it's more like a predefined water system with valves and recirculation... one cannot ignore the sequence of work needed to build a doctors website for monitoring a pace maker by quote the very very basic of agile. Agile is not so complete my friend, one cannot ignore the things we've needed as human beings to complete projects the last 10k years of civilization just because we are in a new field, there are things fundamental to all projects, sequencing work is most certainly one.

If you disagree, please justify, using the agile philosophy, why I am allowed to sequence subtasks on a story, but not children on an epic?

As far as I can tell, this is an accident... ironically, caused by using agile as an excuse not to ensure consistently across interfaces.

All IMHO.

Welcome!

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

Quick Links

Find more posts tagged with

jira-service-desk

new-to-jira

jira-service-management