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?

4 answers

1 votes

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


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!

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?

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,897 views 12 18
Join discussion

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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot