how can i restrict label creation to selected users

There are multiple labels created by multiple users in my JIRA server instance. To ensure that labels continue to stay meaningful, I would like to restrict creation of new labels to a limited number of users. How do I ensure this?

5 answers

No @Nic Brough [Adaptavist], the point of labels is to be able to categorise issues, and in the interests of data quality, it's entirely reasonable that you'd want to restrict users to a pre-agreed choice of labels, otherwise you quickly end up with several versions and/or (mis-)spellings of the same thing, making reporting/filtering difficult.

Your suggestion to use a multi-select list would work just fine for a small set of options, but become cumbersome as the number increased, and therefore I'd still like to see the ability to restrict creating labels to specific roles.

No.  That is not what they are designed for.  As I said already, they're designed to allow users to define their own categories.  That's the whole point of them.

For your data quality - use a (multi-)select, that's what they are for.  Set up a simple process to get new options added by your admins (I once set up a really simple project to handle it with a bit of scripting)

Which is different to how pretty much every other label/tag/categorisation solution I've come across works.

If the available list of options is easily polluted (and from what you're suggesting this is actually encouraged) then it quickly becomes useless for reporting/filtering, certainly at an organisational level, and therefore isn't fit for purpose. If this was by design, then it really does need a rethink.

As I say, the multi-select list or set of checkboxes approach just isn't effective for anything beyond a small handful of options, as large lists aren't presented well on the page, whereas labels take up very little screen real estate regardless of how many options are available.

I really do think providing an option to prevent users creating their own labels makes a lot of sense.

Again, no, labels are designed to work like that.  Select lists are for non-user-definable items.  It doesn't need a re-think, it needs users to use it as intended and think before they pollute the lists.

I agree with Chris - we too would like to be able to restrict label creation as an issue permission via permission scheme for the exact same reasons. 

We do not want the administration overhead that comes with using a select list.

Also, if you feel so strongly about the label feature and are unwilling to see our point, I would like to simply request a new feature called "restricted labels" which does the same as "labels" but adds control via permission scheme as to who can create a label.


Thank you

I do see your point, but the answer remains the same.

You can make feature suggestions to Atlassian over at , but someone already has made a similar one and they've closed it with pretty much the reasons I gave above.

It's always great when people just design for the sake of designing and ignore the customer - great job!

Like 2 people like this

It's not ignoring the customer, it's designing for the majority. 

Most people need labels and multi-selects as implemented, although we would like more freedom to delegate the control of multi-selects (see how "component" fields work), and that is  in progress

A statement we can hardly verify, since the the majority is not here not complaining about the how labels can't be restricted.

Yes, because they don't need or want it.  There were very few votes on the issue in JAC as well, compared with other requests.

Sure, if you would link it here I would vote for it.

You can't vote for closed issues.  There's no point, Atlassian have said they're not going to do this (but are going to allow more control delegation to multi-select fields)

I also needed this feature. I have googled maaany asks about it over many years. But Attalasian knows better that is not needed.


it could be so great feature with this possibility. Without this is only fine.


Do anybody  know any payable addon?

I'm going to chime in and say I also need to restrict labels.   Misspelling labels is incredibly common, and very damaging.   The use of such a system needs to be tempered with the ability to safeguard against human error.  Since that's not possible we have disabled it completely.

Use a multi-select list then, that restricts the options.

Multi-select field as implemented is useless. It is utterly useless. Who is 2018 is going to say it is proper UI design to go to a list of 30-50-or even 300 options and click on one item and then hold the control key and scroll several times down and click another option? This is year 200 design at the best and Atlassian has become too arrogant to listen to its customers. Number of Votes do not matter much as people like myself who are in this community since there was no such community have become tired of this voting system that atlassian has put up as a fake facade. (Remember the bulk label add issue that took 7 years to fix and was the highest voted issue?). So give me a break with "majority like the feature they way it is" as that is a total lie. Majority does not like a multi select field that lacks basic usability. 

Adding permission control to the existing Labels field would make it work for users who are used to the way it works today, AND make users happy that want it to be restricted. Please do not post anything if you want to say that is how it is meant to work. If that is the case why even bother giving feedback to Atlassian, right? 

Like 1 person likes this

Agree with everyone that's asking for restricting creation of labels. Atlassian, would be a good idea to listen to customers..

Like 1 person likes this

Agree - Atlassian has become arrogant and won't listen to users, and why not they now how large customer base so they don;t care until someone comes up with better solution.

Like 1 person likes this

Please, stop ignoring what labels are for - they're supposed to be free for the users to enter what they want.  If you need to control what they enter, then use a list that restricts them.  It's not Atlassian being arrogant, it's you not understanding what a function is for.

At the moment, controlling a field's options means a (multi-)select.  This is the right answer, but has a huge weakness in that only Admins can add acceptable values.  That's poor, we should be able to delegate that to people who know what the list should be (think about project admins who can set components and versions).  Atlassian have that on the roadmap, and if I understand correctly, it's close.

Nic, please stop ignoring what users are saying, and railing against people who are simply trying to bring about constructive change in response to a need they see from their real world experiences. Such change can only be good for the product.

You're defending Atlassian's a very poor choice of label implementation, which absolutely breaks with the conventions used in every other implementation I've come across, where the data in a label field is intended to be used for reporting. As such you are part of the negative culture clearly evident in those close to the product which is actually holding things back.

You're confusing the "right" answer, with the "only option available with the current implementation", and they're nothing like the same thing.

Multi-selects aren't a good solution for anything other than a small number of options which are unlikely to change, and spending time implementing permission based changes to the admin side of these doesn't address this limitation. The issues people have with the label implementation, which are driving this request for change, will not be addressed by the multi-select changes you're suggesting are on the horizon.

Having a system wide option to change the behaviour of labels so they cannot be created on the fly by non-admin users, which would be set to false by default, delivers exactly what many users are requesting, without any negative connotations. It's not a lot of work at all, and set to false by default, wouldn't impact anyone who might be happy with the way things to work at the moment.

My firm belief is that given the option, the vast majority of admins would disable dynamic creation of labels by non-admin users, as this would improve data quality, and mean that label fields could then be used for reliable and useful reporting, which at present, they can't.

Steadfastly refuse to implement such a relatively simple and non-breaking change, despite the repeated calls from users, is pretty much a textbook definition of arrogance, as many of those posting here have suggested. And also a near perfect example of tech people telling users what they want, rather than actually asking, or listening to them.

Chris, I'm railing against people who don't read what I've said, and those who to refuse to grasp that what they're asking for is (mostly) possible already.

I'm not confusing "right" with  "current implementation".  I'm explaining that you already have access to a "right" option, although it is not as good as it should be.   I've repeatedly said I would like to see multi-selects that can be set by non-admins, (and that is in the pipeline now as well)

>My firm belief is that given the option, the vast majority of admins would disable dynamic creation of labels by non-admin users

A lot of them do.  Then they add a multi-select field with a controlled list of useful options.  Have you tried that yet?  It works well.

I don't agree Nic.

I think people are reading what you're saying, however they're asking for something, and you're just suggesting the same approach which they've made clear doesn't meet their requirements. This would suggest that in fact it's you not reading what they're saying.

It's very obviously not the "right" option for some people (and I personally think it's probably not even the "best" option for many of those who are using it, but they currently have no choice) however you keep suggesting it.

I've proposed a very simple implementation which would deliver what everyone here is asking for, without any negative side-effects. Can you please explain why you believe such a solution, shouldn't be implemented?

I don't believe for one second that the voting approach which Atlassian take to feature requests delivers anything meaningful, as the only responses are likely to be from people like yourself, who are happy with the current solution, rather than actual users seeking change. Actual users are very unlikely to ever see or engage in these polls.

I entirely accept that you feel able to deliver a suitable solution to your users with the features currently available, but as a software developer with well over 30 years commercial experience, I've seen time and time again developers refusing to implement user requests because "that's the way it's always been done". In every single one of these cases, this has held back progress, and poor design/implementation choices have been perpetuated, when they could/should have been addressed.

Like 1 person likes this

<sigh> I really don't think you've got it.

Most people want free-access.  Those who don't already have the option of multi-selects which fulfil most of the requirement, and work for the overwhelming majority.  

Most of the people who are asking to limit labels are just not understanding that what they're asking is already possible (with a weakness in those, in that you have to be an admin to be able to create the options, but there is a fix for that in the pipeline)

No Nic, you're the one who isn't grasping this.

You're simply suggesting, over and over, ad nausium, the same solution. You're being told that this isn't a suitable approach in these cases, but you're telling people that they're wrong. They're not. Their experience and requirements are just different to your own, but you seem unable to put your self in their position, and unprepared to consider that they have an entirely valid point.

What these people are asking for, on behalf of their users, is entirely reasonable, and I'm confident would be easy to implement properly. The ease with which their needs could be met is what makes this whole situation so frustrating, and it's entirely understandable that people feel Atlassian are ignoring the wishes and needs of their users.

I ask again - what possible reason could there be not to implement a simple change which would allow those who want it, to restrict the on-the-fly creation of labels?

Like 2 people like this

You're repeatedly ignoring me, so there's no point in bothering responding to you any more.

We'll just have to agree that we have different opinions and go do something useful (you could, for example, write a custom field that behaves the way you want - base it on the multi-select code which is already 95% of what you are asking for)

No, I'm really not.

This entire thread is people asking for something, and YOU ignoring them, convinced that you're right and they're wrong, despite all evidence suggesting that in fact the opposite is true.

It's not just you and I who have differing opinions, it's you and everyone else on this thread. You know, actual users who have a requirement which isn't being met, who have taken the time to seek out this forum and make an entirely sensible and reasonable feature request, explaining clearly why the options they currently have available don't meet their needs.

You have a hammer, and are treating everything like it's a nail. What these people have is a screw, and they need a screwdriver. You don't have the necessary tool to help, but rather than acknowledge that the "right" answer is to go and get a screwdriver, you're proposing they simply hammer it in. That's pretty ridiculous.

The one positive to come out of this, is that I now have an excellent real world example to use with my teams, highlighting how stubborn refusal to listen to what your users actually want, and a blind insistence that you're right despite plenty of evidence otherwise, inhibits progress, and means we miss the opportunity for a quick win, which would increase user happiness and improve solution functionality with very little effort on our part.

Like 1 person likes this

Maybe I am really missing a functionality here, Nic. You can alway teach me a new trick :)

How is multi select field doing what we are asking for? A multi select field as I have it setup, users have to scroll through a very small visible field and select from a list of 100s of entries and hold a keyboard key down and select to accomplish multi-selection. In the process user has so many ways to make a mistake and deselect other selections or select too many items. 

Are we talking about the same feature and function here?

I was also trying multi select field. And for some tasks are completly USELESS.

Lets start discustion from the point:

"Multi select fields are for many tasku USELESS !!!!"  because of not convinient way of using it. Especially with long lists.


So if You don't want to add functionality to labels, maybe You can add functionality for multi select? 

The functionality should be:

"Selecting the values inf multi select should be the same as in Labels"


Is it possible?

@Nic Brough [Adaptavist]

"Chris, I'm railing against people who don't read what I've said, and those who to refuse to grasp that what they're asking for is (mostly) possible already."

For me it's not just the inconvenience of how to administer a (multi)select list, it's the mechanics of the fields itself - people just love the autocomplete as you type thing supported by labels, while multiselect lists are just long and ignorant - also, we do not want to force people into going through super long lists by turning them into a mandatory field.

Like 1 person likes this

I have the same problem here. I have a lot of labels and it's not practical to put a multi select list. I need to restrict access to the "create new label".


How come Atlassian is still ignoring this issue.

So disappointed

1 vote

You can't do this.  The whole point of labels is that they allow users to add whatever they need.

@Nic Brough [Adaptavist] can you suggest an alternative tool to use? As the way you can filter topics by labels is very useful, but when you open the editing rights to all users it can quickly become messy

Swap to a select list. That way your admins control the available options and the users can't add their own.

Thanks, is there a way to move an existing label to a select list or is it a manual process? 

Manual I'm afraid, but you can at least use bulk edit to speed it up and deal with many issues at a time

I've just started a small project that is going to grow. I already have user label pollution and the multi-select list is a non-starter because of its cumbersome interface. I need the ability to limit label creation to a few users otherwise the label field becomes pretty much a garbage dump in just a few days.

I have the same problem with my users.

I know that the ability to create new label is given to all users that have "edit issue" rights.

If someone can give a better solution it is really appreciate also by me...


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Wednesday in Jira

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

141 views 0 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you