how can i restrict label creation to selected users

[LakshmiS]

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?

[Chris Wilson]

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.

[Nic Brough -Adaptavist-]

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)

[Chris Wilson]

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.

[Nic Brough -Adaptavist-]

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.

[Marcel]

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

[Nic Brough -Adaptavist-]

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

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

[Marcel]

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

[Nic Brough -Adaptavist-]

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

[Marcel]

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

[Nic Brough -Adaptavist-]

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.

[Marcel]

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

[Nic Brough -Adaptavist-]

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)

[Marek Gwozdz]

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?

[Chris Buzon]

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.

[Nic Brough -Adaptavist-]

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

[Deleted user]

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? 

[Saad Patel]

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

[Jitendra Bhimjiyani]

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.

[Nic Brough -Adaptavist-]

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.

[Chris Wilson]

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.

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

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.

[Chris Wilson]

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.

[Nic Brough -Adaptavist-]

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

[Chris Wilson]

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?

[Nic Brough -Adaptavist-]

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)

[Deleted user]

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?

[Marek Gwozdz]

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?

[Marcel]

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

[Elie Bou Farhat]

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

[Matthew Hoesterey]

We need this too.  Someone should fire nic.

[Matthew Hoesterey]

I'd love someone from Atlassian to explain a use case of how to get around our issue rather then explain that "labels are not meant for that...

We have 100s of enemy types.   Each enemy type has different tasks associated with it.  E.g. Animation, rigging, sound, fx...

Sometimes an animation will be associated with multiple enemy types.  E.g. a "Wolf" and a "Dog".

We'd LOVE to restrict labels so we could use them for enemy types and then use lists for task type.   So Animation : Dog, Wolf

But to do the above we'd need to be able to restrict labels. 

[Nic Brough -Adaptavist-]

"We need this too" - just tells me you have not grasped what has been said before.  There is a clear solution in the discussion already.  I'm afraid your comment does not help me understand why that (or using labels as intended) does not work for you.

As for someone should fire me - I suspect you've missed another point, in that I'm not an Atlassian.  I work for a partner who hired me because they think I'm good at this stuff, and keep me because I'm still improving at it.

[Matthew Hoesterey]

Sorry Nic,  I should not have publicly attacked you but I really don't think you have listened to the people in this thread. 

Labels as implemented are a garbage dumb in a medium to large project.  They almost instantly become impossible to manage and are 100% useless.   

If Atlassian wants labels to be "user added" they should exist on ONLY the account level.  So my labels are mine, yours are yours, etc...  Admins should also be able to add cross user labels that exist for the entire project.  Labels are not well designed as is and cause more problems then they solve. 

[Nic Brough -Adaptavist-]

Right, so use a multi-select, as we said before.

[Chris Wilson]

This is ridiculous.

How many more times can you ignore the use case where there are LOTS of labels (in this particular case "100s") which make using a multi-select completely impractical, and where there is a very clear justification for restricting a user's ability to dynamically create labels?

Time and time again actual users, with actual real world issues caused by the current label implementation, are explaining why multi-selects are not suitable, and yet you still keep suggesting them as a viable option.

The fact that you're a "Community Leader" with an attitude like this, and an apparent inability to see things from anyone else's point of view, speaks volumes about the state of things at Atlassian with regard to support and user engagement.

I don't doubt you have plenty of experience and a good working knowledge of JIRA, but your "it's my way or nothing" attitude is tiresome and gets us nowhere, as is very clear in this thread.

[Deleted user]

And as we said before, multi-select field is not user friendly. You keep ignoring every post that says that. 

[Chris Wilson]

This is ridiculous.

How many more times can you ignore the use case where there are LOTS of labels (in this particular case "100s") which make using a multi-select completely impractical, and where there is a very clear justification for restricting a user's ability to dynamically create labels?

Time and time again actual users, with actual real world issues caused by the current label implementation, are explaining why multi-selects are not suitable, and yet you still keep suggesting them as a viable option.

The fact that you're a "Community Leader" with an attitude like this, and an apparent inability to see things from anyone else's point of view, speaks volumes about the state of things at Atlassian with regard to support and user engagement.

I don't doubt you have plenty of experience and a good working knowledge of JIRA, but your "it's my way or nothing" attitude is tiresome and gets us nowhere, as is very clear in this thread.

[Andy Stevenson]

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.

[Mark Bowden]

@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

[Nic Brough -Adaptavist-]

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

[Mark Bowden]

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

[Nic Brough -Adaptavist-]

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

[Nic Brough -Adaptavist-]

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

[Stefano De Gaetano]

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

[erik.unangst]

My company would also benefit from being able to restrict the creation of labels...

[Nic Brough -Adaptavist-]

Use a multi-select instead.

[Deleted user]

And Nic, as we said before, multi-select field is not user friendly. You keep ignoring every post that says that. 

[Nic Brough -Adaptavist-]

You've not read what I said about them being clumsy when you have large numbers of options (which is generally a bad idea anyway)