Can we do bulk update of summary?

[srinivasp]

Can we add a common prefix to Summary?

[Nic Brough -Adaptavist- · Accepted solution]

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.

[srinivasp]

Is bulk label additives possible with JIRA 6.1.6?

[Nic Brough -Adaptavist-]

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?

[srinivasp]

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

[Nic Brough -Adaptavist-]

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 :-(

[Clemens Luebbers]

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)

[Robert Jacobs]

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.

[Nic Brough -Adaptavist-]

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

[Robert Jacobs]

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.

[Nic Brough -Adaptavist-]

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

[Robert Jacobs]

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.

[Nic Brough -Adaptavist-]

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)

[Lee Cash]

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. 

[Lee Alderdice]

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.

[Pavol Harvanka]

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.

[MattS]

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

[Robert Jacobs]

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.

[Tim Morrow]

I would like to see this added