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

Is it possible to disable new labels creation?

Péter_Kemenyás

Dear JIRA community

Does JIRA allow to restrict the new values creation for "label" field type?

We have a huge list of functionalities/areas (more than 300) and wanted to have them as searchable multi-select in the same way as Labels are made but without possibility to add new values by normal users (to avoid similar or duplicate values).

Thanks in advance,

Peter Ke.

Accepted answers

All comments

Nic Brough -Adaptavist-

No, the whole point of the labels field is to allow people to create new values.

If you want a limited list, the best you can do is use a multi-select.

Péter_Kemenyás

"No, the whole point of the labels field is to allow people to create new values." - absolutely agree with you. And having one field where all the users can add values without any control is quite enough. Right? We do not need other custom field with mess.

"If you want a limited list, the best you can do is use a multi-select." - No, the whole point of my question is to have searchable (like "labels"), multi-select (like "labels") custom field without scrollbar (like "labels") and show the selected values in easy to read way (like "labels") BUT without possibility to add new values (like "multi-select").

Would it not be much more better to add an additional setting to "label" field type to enable/disable new values adding by usual JIRA user?

Yevhen Rohovets

Well, you absolutely right, add an additional setting to "label" field type to enable/disable new values adding by usual JIRA user is better, but Atlassian does not give such an opportunity, therefore, it is necessary to resort to other methods)

Nic Brough -Adaptavist-

No, Atlassian are not going to add another field that does what a multi-select already does.

If you want people to add free-format options, use a label. If you want a restricted list, use a multi-select.

Eli Szus

1. There is another big reason to use labels rather than another field. The labels show on the card in various listing views.

This is important for practical usage of this tool.

2. Limiting tag creation to certain users seems like a very reasonable and useful request. Allowing everyone to create any tags they want makes the labels field almost useless since users will create garbage labels losing all consistency or value. This may be fine for some use cases, but for many (or most) cases, having no control over this turns the tags field into a garbage field.

3. Another important thing to note is that removing a label from circulation is not possible. So once someone adds a label, say a bad word for example, it is now going to be autocompleted for everyone forever.

4. Labels is the only way that I've seen, other than parent tickets and deadlines, to show words on the cards.

X. But over a decade of using jira in various businesses, I have yet to have a single feature implemented that I've commented on or requested. I have zero hope that jira cares about its users. This community just feels like a bunch of people yelling into an empty void honestly. I typically end up here in frustration. They built an entire new version of the tool and somehow are still unable to add new features on a meaningful schedule. Would love it if someone proved me wrong, but I'm so exhausted commenting in these chats with no meaningful progress ever. I've commented on things with 1000s of upvotes over many years and still nothing.

Nic Brough -Adaptavist-

Yes, this does make a lot of sense.

1. Yes, very much so, that's why labels are useful.

2. Yes, you're right, it is very easy for people to create junk. If you want to stop this, then use a controllable field instead.

3. Ah, now that is technically wrong - to remove a label from circulation, search for it, then delete it from each issue it is on. Might be a bit of a slog if it's been widely used, but you can do it.

4. Select lists, text fields and so-on all show words and phrases on issues

X. Yes, Atlassian has implemented labels in a similar way to others. They are a bit stuck in general, to be honest - there's a faction pushing for more flexibility/agility for end-users, but at the same time, another pushing for more joined-up thinking and useful collaboration.

Atlassian doesn't go far down either route but tries to support both, which leaves us in a very grey area, and labels are one of the things that fall down the cracks - we want them to be useful, which means having a global constraint on them, but the aim of them is to let anyone put what they want in, in the name of flexibility.

Personally, I would like to see three things done to labels

There should be a (global) permission for creating new labels. Everyone with create/edit can add labels to an issue, but they can only add labels that already exist (I have a feeling that rule should only kick in after a system has 128+ different labels to offer). Then the handful of people in the "can create new label" group can add whatever they like.
There should be a simple admin screen for labels that lists them, allows a bit of a sort, shows when they were last added to an issue, and, most importantly, allows admins to rename, merge or, if it really is that terrible, simply delete the label.
I would split the field into two - global and personal. Global labels should work as they do now (with the two functions above added), but people should be free to tag issues with something that non-one else gets to see.

Eli Szus

I like your recommended solution. I don't believe that it will ever happen.

I would be happy if they would do something as simple as adding permissions on who can add new labels.

Wolfgang Landes_4s0um9

Hi @Péter_Kemenyás

Jira native 'Labels' field allows everyone to create new labels anytime. This often results in a mess of options.

We built an App that not only allows to clean up (edit, merge, delte) Jira native 'Labels' field globally or on a project level, but also to create 'Label Manager' own custom field type that allow to predefine allowed labels globally or for each project.

Label Manager for Jira

This allows project admins to manage their the options themselves without help from global Jira admins. (Like components)

Also you can use the label as checklist by assigning traffic light colors indepent on each issue.

Hope I could help you

Thanks

Wolfgang

JacksonC

@Nic Brough -Adaptavist- What is your recommendation when we have a select list that has 10k entries for each context of a select list field? And different values for each project.

Nic Brough -Adaptavist-

Get rid of it. It's slow (as in your performance is suffering), painful to use, and your humans are almost certainly getting it wrong. Are you sure they are selecting the right one from a list of 10,000?

Are they genuinely useful? Are they all being used?

There's a good reason many systems limit select list options to 55 - that's the point at which 99% of humans will start making significant numbers of mistakes (unless they are intensely familiar with the part of the list they need - 196 countries, plus all the weird outliers, like territories and crown protectorates work fine). Go to a DIY store and visit the aisle that is for "joining things together". Do you really want to have to plough through a single list of every type of screw, nail, or bolt, along with measurements, what they're for and so on. No. The store breaks it up to enable a simple intuitive search.

But, of course, I do not know why you have ended up like this. If you could explain that, I could probably refine "get rid of it" in a way that might help you a lot.

JacksonC

On server, we are able to use use a plugin that allows us to create a custom field that has JQL behind it. This JQL would allow us to show only the relevant issues per project ( similar to contexts, but a bit more advanced ). We created a custom field to list all builds for a specific project. As we create more builds, an issue is created in Jira and the field would display that as a selectable option. As time goes by the list gets very big.

We don't want users to enter free text since they could possibly enter junk.

I don't want to use a select list with that many options but I'm trying to figure a way to do something similar as what we had before since cloud seems to be very limiting.

Nic Brough -Adaptavist-

Ah, yes, makes sense, but there's a better approach than a JQL field. (Not a bad choice though - a JQL-based field is probably what is stopping you from posting "my Jira takes 25 minutes to render issues" problem!)

The last time I ran into this, we rigged up the build systems to create Jira versions in the project(s) affected, one project version per build. (Builds could cross projects, so we did a few tricks by post-fixing the version names - if build 324 affected ABC and DEF, we got two versions called 324-ABC and 324-DEF, but all the issues got "build-324" stamped on their build custom field too).

The "clever" part that I got most involved in once we'd got that working was the test result processing.

This was a much more complex situation than this, but let's just focus on "main" rather than "when I want to save it" or branches or "when I want a test and don't want to manually do it". Imagine that:

the developers are committing to "main branch" code when it's ready
there is a build
if it succeeds, it gets an id
the build was for about 600 slightly different things (there's only about 200 projects, some things can be grouped - if it fails on only one of nine grouped projects, we considered it to fail on all)
automated tests happen for all 600 things
the build id becomes a version, pushed back into Jira with a simple pass/fail into all the projects affected by it

On a busy day, they'd create 5,000 versions across many projects.

To vastly oversimplify this, I scripted

create issue for team that lists only what they committed that might have broken it, so they can have a look
archive any versions that have no open "what did you do that might have broken it" issues every day

This really just left them with a short list of "need to look at" and "release candidates" every morning.

Welcome!

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

Quick Links

Find more posts tagged with

server

jira

jira-server