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.
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?
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 :-(
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.
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, 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.
This approach requires you to have the JIRA administrative rights. The main aim of this article is to help you achieve an organized, easy-to-maintain workflows in your JIRA instance thereby, reducin...
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