Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Can we do bulk update of summary?

Can we add a common prefix to Summary?

3 answers

1 accepted

1 vote
Answer accepted

Bulk update, yes, but it will simply change all the summaries to be the one string you enter.

So adding a prefix to existing ones, no.

You should look to scripting, or, probably better, question the requirement - a fixed prefix implies you're trying to search or categorise something and that's better done with a field or label.

Is bulk label additives possible with JIRA 6.1.6?

I do not understand that question. Bulk labelling of issues works, it puts labels on a list of issues, has done since Jira 2. I'm lost on what you mean by "additives" - those are things you put in food to change the flavour, colour, texture, shelf life, etc. Not sure what it has to do with Jira, I think your spell-checker has picked the wrong word?

Sorry its a typo.. I actually meant label addition without removing existing labels.

Ah, ok, miskey on "add to", that makes a lot more sense. I should have guessed that, sorry! No, I'm afraid bulk-edit replaces existing settings, it doesn't add. There is a request to change this so that we get the option to add to lists, but it's not there yet :-(

Beside the already mentioned fact, that bulk edit does not "add" information to existing values - for field "summary" bulk edit does not work at all (see https://jira.atlassian.com/browse/JRA-33719)

Like Kyrry.Kyriacou likes this

Putting two pieces of information in a single field is not good data design. Use a label or other field. If you really need to then first think how you will remove the prefix when you decide you don't want it after all. 

The answer is probably script runner though

JIRA prefixes "CLONE -" to the issue summary when cloning issues. Fortunately, you can edit the summary of the issue but I have not seen how to prevent the prefix that is added to the summary of linked sub-tasks. This causes the very problem you described when you want to remove the prefix.

Like Kyrry.Kyriacou likes this

I would like to see this added  

You can append a prefix to the summary using a utility such as Excel then use the External System Import function to update the issues via Excel or a CSV source file. (Provided you supply and map the issue Key and Summary.) The process is similar if you want to later change or remove the prefix... edit the issue summaries in Excel and then update JIRA using External System Import. This method works well if you have a JIRA Cloud instance.

The answer is still correct - don't compound fields, it implies you're doing something wrong.

Like Kyrry.Kyriacou likes this

Nic, I disagree. There may be a business need to present information at the summary level.  Email is a good example. Most email applications will add Re: to the subject automatically for you when you click the Reply. Also, as I commented above, JIRA adds the CLONE - prefix by default when cloning issues.

Yes, the Clone prefix is something that's useful as an indicator at a glance, but you really are wasting your time with most others - it's useless for search, it's unhelpful and can be over complex and confusing in a lot of cases, and in the vast majority of cases, it absolutely screams "I have not thought this through" because you should have it in separate dedicated fields.  So you can search and use it properly.

The re: on emails is a fantastically poor design and should be replaced by email programs doing threading properly, so that's a terrible example to support your statement

In my opinion the "Clone" and "Re" prefixes are intended to serve very much the same purpose and are only useful in context. Can connotes ability however and whether you are of the persuasion that prefixes add any value to the design or not, the fact is that you can modify the summaries of multiple issues at once via the CSV import feature.

I'm sorry, I could, and should, have been a lot more clear in my last comment.

I'm sticking by the point that prefixing the summary is a terrible way to do this, and that the Clone and Re: ideas are, at best, a total botch which should have been done properly.  I could have explained this better by asking "in what scenario is it better to have a prefix over a clear, dedicated, indicator with full history which can be properly searched/sorted properly unlike the summary?".

I completely agree with you on the "only useful in context", and that's actually one of the reasons that a separate indicator is a better way to do it than prefixes in my opinion (because the context is given by the indicator automatically, rather than assuming the user understands something wedged into the summary.  In real life, the number of emails we see with "re:" stuck on the front out of context tells me it's a terrible implementation)

 

Late to the party here but in the backlog view, it's not always possible to see the full name of the Epic in the sidebar. Having a prefix (such as the team working on the Epic) makes it very easy to see who will work on the Epic without having to click on it to get its full name. 

 

A botch? Perhaps. But the alternative is to create a custom field for team when that could be seen as overkill; especially if you make the field mandatory. Now everyone is screaming about friction when creating a task because of the extra step, when all you wanted was a quick way to eyeball a task and know what Epic it belonged to. 

 

 

Like Melanie Albrecht likes this

Really, really late to this party but the prefix helps us visually scan backlogs and issue lists.  For reporting, utterly useless so we use prefixes, labels, components etc etc etc.

Even later than really really late - but I do have a solution: Automation for Jira

3 pictures where:

  1. To create a prefix for Summary if a particular label is added:
  2. To remove the prefix if label is removed
  3. To mass update summary (correcting the prefix in this case) based on criteria with a scheduled trigger that can be executed any time from within the automation UI and subsequently disabled until it is needed again.

image.pngimage.pngimage.png

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you