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?
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.
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.
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.
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
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.
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?
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.
<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?
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.
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?
"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.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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!
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