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.

[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. 

[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.

[Benjamin Peikes]

Nic, you keep pushing multi-select, but that control does not work for the cases where you have a large number of tags. It's pretty unbelievable that you won't accept that.

The UI for multi-select is horrendous. Every modern system with labeling allows permissioning on labels. Look at Stack Overflow, you don't get to add new tags until you reach a certain level.

Would you be happier if we asked for instead for a new field type called "controlled label", or perhaps be able to configure a multi-select field with a "Use Label UI", parameter?

[Nic Brough -Adaptavist-]

I do agree that the multi-select is not great when there are a lot of options.  But if you're wanting to limit people's "tags", you probably don't want a lot anyway.

Ideally, yes, we get a type-ahead for multi-select instead (or better, as well as, and we can choose which we use).  But the fact remains if you want to control the tags, the best option is a multi-select.

[Turpentyne S.]

Right now I want to create a set of countries/regions as labels. I don't want the user to create their own because then we would have inconsistent values, "USA" vs "US" vs "United States" vs.. ad infinitum. 

and.. there are over 200 countries in the world.

A labels field where we can prevent the creation of new labels is PERFECT solution for this.. Not a dropdown.

I see multiple strings of back-and-forth over this. where Nic states that's the dropdown field and that the labels field is meant to be used as free-form..

But.. it still CAN. Simply give the option to limit that field or not. Then it's up to the user. it makes  EVERYONE happy. That "supposed majority" who want the existing Labels functionality are still happy. And those who want to limit labels, can. 

Simple as that. No arguments needed. Atlassian... just do it, already!

[Nic Brough -Adaptavist-]

If you want to limit the field, use a select type field.  Simple as that.

[salob]

With over 3 thousand jira users in our system we have tons of labels with mispelling and duplicates (e.g. word separation by underscore instead of dash). It is very hard to police and the idea of giving someone the weekly task of updating issues to remove bogey labels is a not a good solution I feel. Other software have a permission option for labels/tags e.g. stack overflow, github issues, azure boards, drupal, rtc. I don't see a problem with implementing this as if we still want to allow a free for all it can still be achieved with permissions but the option is there.

[salob]

Also I want to see my labels on my kanban board

[Nic Brough -Adaptavist-]

Please see the answers already given, there's a logical reason it works this way, explained in those answers.

[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.

[JacksonC]

Hi Nic, 

Thanks for your reply.

Using versions could be an option but in our situation, it won't work.

Versions and Builds would be put into the same pool of options. We need the builds field to have its own options.

Thanks

[Wolfgang Landes]

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