• We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      Atlassian Update - 16 March 2015

      Hi everyone,

      Thanks for your feedback and comments on this issue. We recently implemented JRA-14369, which resolves several of the improvements described on this issue – specifically, you can now selectively add and remove values during a bulk edit operation for JIRA's system multi-select fields, including labels, components, affects versions, and fix versions.

      We have decided to close this ticket because we have no plans to address the remaining requests around label management. Our intent is to ensure that there is a functional difference between Components and Labels. One is a lightweight "tag" that any user can create, one is a set of objects created by a project administrator. We would prefer to extend the capabilities of each of these features individually, rather than allow their functionality to overlap more than it already does.

      We expect the new bulk edit functionality to make it substantially easier to correct cases where you need to "merge" labels. There is also a free add-on on the Atlassian Marketplace to assist with this.

      Please don't hesitate to contact me if you have any questions.

      Regards,
      Dave Meyer
      Product Manager, JIRA Platform

      Wouldn't it be nice to have a way to manage Labels, maybe from the Project Administration screen? Currently there is not a way to mass manage Labels. Doing a Bulk Edit on a set of issues replaces (removes) all current Labels with only the new label for all issues, instead of adding the new label to the existing label set for each issue. This makes Bulk Editing Labels almost useless, since it is very uncommon to have issues with all existing Labels in common. Being able to Bulk Add/Remove/Rename a label, would be incredibly convenient.

      Wouldn't it be nice to be able to merge Labels? Sometime users will create different Labels which essentially mean the same thing, management should be able to merge these Labels. For instance 'grey' + 'gray' >> 'grey'.

      Wouldn't it be nice for management to be able to lock-down Labels? Sometimes users are just down right bad at creating appropriate Labels, and once a bad label is created, other users start using it as well. Maybe from Project Administration, administrators could create a set of Labels to be used in that project, and then users could only select from that set of Labels. If a user really feels like they need a new label it could always be requested.

            [JRASERVER-26128] Label Management

            I get the difference between labels and components described above, but is there a way to make a custom field that can be restricted like Components but is globally accessible like labels? I want to track "system capabilities" like components, but at a level that can span multiple projects. 

            Charles Breingan added a comment - I get the difference between labels and components described above, but is there a way to make a custom field that can be restricted like Components but is globally accessible like labels? I want to track "system capabilities" like components, but at a level that can span multiple projects. 

            Hi! 

            It will be nice if implement label management.

            Also what about label management on group based? 

             

            Cheers,

            Gonchik Tsymzhitov

            Gonchik Tsymzhitov added a comment - Hi!  It will be nice if implement label management. Also what about label management on group based?    Cheers, Gonchik Tsymzhitov

            Try out Label Manager for JIRA to manage Labels from Project Admin Screen. It locks down labels so that not every user can create new items.
            The admin or project admin can create, rename and delete items.
            It is possible to use these label fields for all projects or for each JIRA project individual.

            There are some more useful features like using colors for label items or adding, deleting, validating items during workflows.
            It's for free by using the promotion link at the end of the details description.
            https://marketplace.atlassian.com/plugins/rs.codecentric.label-manager-project/server/overview

            codecentric AG added a comment - Try out Label Manager for JIRA to manage Labels from Project Admin Screen. It locks down labels so that not every user can create new items. The admin or project admin can create, rename and delete items. It is possible to use these label fields for all projects or for each JIRA project individual. There are some more useful features like using colors for label items or adding, deleting, validating items during workflows. It's for free by using the promotion link at the end of the details description. https://marketplace.atlassian.com/plugins/rs.codecentric.label-manager-project/server/overview

            Antigone K added a comment - - edited

            Ah, thank you for clarifying, Greg,

            We need the JIRA labels to work exactly like Confluence labels, which on the surface would make sense given the supposed tight integration between Atlassian products. In fact, our original implementation team thought Atlassian had a system for labels that each product uses since that's good coding practice.

            We've hit the famous "trough of despai" with Atlassian. The "this is soooooo cool!" Honeymoon period is over and now we're finding a ton of glitches, bugs, and design flaws.

            Hopefully we can work through these asap because the adoption has been broad & fast meaning the divorce is going to be rough.

            If they'd like to see where this "new features first, refactor later" path leads, I suggest trying Windows.

            Antigone K added a comment - - edited Ah, thank you for clarifying, Greg, We need the JIRA labels to work exactly like Confluence labels, which on the surface would make sense given the supposed tight integration between Atlassian products. In fact, our original implementation team thought Atlassian had a system for labels that each product uses since that's good coding practice. We've hit the famous "trough of despai" with Atlassian. The "this is soooooo cool!" Honeymoon period is over and now we're finding a ton of glitches, bugs, and design flaws. Hopefully we can work through these asap because the adoption has been broad & fast meaning the divorce is going to be rough. If they'd like to see where this "new features first, refactor later" path leads, I suggest trying Windows.

            I'll clarify that last comment, although it's clear that Atlassian don't give a crap how poorly the labels system works, but others might be interested.

            If you want to have labels that are scoped to individual projects, or perhaps a group of projects, the only way to do it is to create a custom field for each project, and set up the field configurations to include it.

            This means you end up with lots of labels custom fields, eg LabelsProjectA, LabelsProjectB, LabelsProjectC, LabelsProjectD etc. Instead we should have the option of re-using the same custom field in multiple projects, but restrict the values from one project contaminating the values in another project, so you'd just have a single field called ProjectLabels and project A would get "regression, blocks-testing, degradation" as values, and project B would get "high-priority, paper-cuts, needs-retest" as values.

            Greg Hoggarth added a comment - I'll clarify that last comment, although it's clear that Atlassian don't give a crap how poorly the labels system works, but others might be interested. If you want to have labels that are scoped to individual projects, or perhaps a group of projects, the only way to do it is to create a custom field for each project, and set up the field configurations to include it. This means you end up with lots of labels custom fields, eg LabelsProjectA, LabelsProjectB, LabelsProjectC, LabelsProjectD etc. Instead we should have the option of re-using the same custom field in multiple projects, but restrict the values from one project contaminating the values in another project, so you'd just have a single field called ProjectLabels and project A would get "regression, blocks-testing, degradation" as values, and project B would get "high-priority, paper-cuts, needs-retest" as values.

            Antigone K added a comment -

            thank you, Greg! I'll look into that.

            Antigone K added a comment - thank you, Greg! I'll look into that.

            Actually the global-scope of the Labels field is another issue itself. This can be somewhat ameliorated by creating new custom fields of the Labels type and only putting it in the particular projects you want, but there should be a way to apply scoping to these fields types as well.

            Greg Hoggarth added a comment - Actually the global-scope of the Labels field is another issue itself. This can be somewhat ameliorated by creating new custom fields of the Labels type and only putting it in the particular projects you want, but there should be a way to apply scoping to these fields types as well.

            Antigone K added a comment -

            Dave Meyer, I get what y'all are saying about component and label functionality overlapping and wanting to avoid that. But there's one distinct difference for us ... Labels are (supposed to be) installation wide whereas components are created on a per project basis.
            We need a way to designate related issues across projects and using labels is currently the best way to do that except for a few major problems. One is that I have no way to see all of the labels across the installation meaning I have no way to see which duplicates or ambiguous labels are out there, and two if I create a label, it doesn't appear in the dropdown of available labels for anyone else. It's only cached for that user after they've used it. Um, hello, site wide?
            Give us a way to easily relate issues across projects without all kinds of undue fuss or administrative overhead. I don't care what it's called. Just make it happen.

            Antigone K added a comment - Dave Meyer, I get what y'all are saying about component and label functionality overlapping and wanting to avoid that. But there's one distinct difference for us ... Labels are (supposed to be) installation wide whereas components are created on a per project basis. We need a way to designate related issues across projects and using labels is currently the best way to do that except for a few major problems. One is that I have no way to see all of the labels across the installation meaning I have no way to see which duplicates or ambiguous labels are out there, and two if I create a label, it doesn't appear in the dropdown of available labels for anyone else. It's only cached for that user after they've used it. Um, hello, site wide? Give us a way to easily relate issues across projects without all kinds of undue fuss or administrative overhead. I don't care what it's called. Just make it happen.

            Dave Meyer added a comment -

            Hi moshe.hajaj, as described in the description, we have implemented support for bulk managing system multi-select fields: labels, components, affects versions, and fix versions. Custom fields are not supported, this is tracked in JRA-14369.

            Dave Meyer added a comment - Hi moshe.hajaj , as described in the description, we have implemented support for bulk managing system multi-select fields: labels, components, affects versions, and fix versions. Custom fields are not supported, this is tracked in JRA-14369 .

            I installed Jira v6.4 today, and I must say I'm very disappointed with the way this issue was resolved.
            The fix applies to "labels" (system field) but not customized fields of type 'labels'. It fixes "affects versions" and "fix versions" but not customized fields of type "version". and also ALL multi-select custom fields are not supported either! very disappointing. Sorry Atlassian, this is not a way to fix a broken thing.

            Moshe Hajaj added a comment - I installed Jira v6.4 today, and I must say I'm very disappointed with the way this issue was resolved. The fix applies to "labels" (system field) but not customized fields of type 'labels'. It fixes "affects versions" and "fix versions" but not customized fields of type "version". and also ALL multi-select custom fields are not supported either! very disappointing. Sorry Atlassian, this is not a way to fix a broken thing.

              Unassigned Unassigned
              a71f5ef78821 David David
              Votes:
              266 Vote for this issue
              Watchers:
              144 Start watching this issue

                Created:
                Updated:
                Resolved: