Still, the bug is marked as fixed and closed in a version that is exclusively available OD. This doesn't make much sense for 90% of customers, which are not using the OD versions.... is like saying "case closed, solved on my own machine"... not identical but you got the idea.

I think that bugs should never be marked as fixed only with "OD" versions, if this is supposed to be included in the unreleased yet "6.4", why we are not seeing this in the Fix Versions?

circusdog, this is planned to be available for Server deployments with the upcoming version of JIRA 6.4 - coming really soon.

Cheers,
Bartek

@Bartek - It looks like this is currently fixed for cloud customers only. Can you please tell us which version of the server offering will contain the fix?

Great news, everyone. The solution to this request is provided as a fix for another JAC request: JRA-24118.

I am therefore closing this one as "Fixed".

Thanks for your comments, and votes.

Cheers,
Bartek
JIRA Product Manager at Atlassian

When used for the 'Fix Version' field, I like to think of this functionality as giving the option to "preserve version history" or "replace all values"

This makes sense to apply to multi-select fields in general though, & options are always nice.

Even a generic variable as a value like current version to denote to keep the previous values - whatever makes the most sense for the UI & workflow.

I agree 100%

Agreed. The bulk edit is essentially broken because of that. Adding a new version has become a very painful operation.

What is Atlassian's response to this?

I see several issues created and many votes and watchers. JIRA's bulk change functionality is broken and can do a lot of damage to the database by bulk editing multi-value fields. We are running into this on updating versions, adding (or trying to) a new label to issues with existing labels, selecting a value on a multi-checkbox to issues with existing values checked. It wipes out all existing data!

Example:

I have a multi-check box called follow-up with values "include in release notes", "create knowledge base article", "update training", etc. If I search for a group of issues and want to add the "include in release notes" in bulk, it wipes out any existing checked values.

The bulk change function needs a Add or Replace option for all multi-value fields. Without this, we can't allow people to use it, and it's worthless for multi-value fields.

Thanks,
Robert

This is something we need desperately also.
Can Atlassian please provide an update on this.

Thanks

We are JIRA customers and very unhappy about the fact that this issue is still open.

We have to add affects versions and fix versions to existing issues very often. Doing this by hand for hundreds of issues need a lot of time.
The actual behavior of bulk edit for version fields is not really usable for this problem.

Please add the missing function.

I too need this feature badly. We are performing a painful manual process.
Opened in 2007, no comments since 2010. Any word on this from Atlassian?

Making the changes additive might not address some cases where I want to turn something off without affecting the other selections.

What about supporting something akin to an 'as-is' setting for each selection in the box? Anything marked 'As-Is' would not be affected while all other entries would be updated based on the bulk-edit operation.

By the way, this type of behavior would be valuable for any multi-select box, including custom ones.

So, would it be appropriate to have a 'retain' option for bulk edits to make values additive.
It's a strange feature to be missing

As we provide both patch releases and formal software releases, we may choose to pick a number of critical issues for a patch release, and update the fix-for versions to target both a patch and formal release without affecting the final release version
Equally our software testers will be regression testing a build, and often need to bulk change the affected version field.

Agree that this is very frustrating. I use fixVersions to track product releases, coarser "phases" of functionality, and also much finer grained Sprints/Iterations. I can't apply any of these as a bulk op to items which may already have any of the others, since it will erase important info that I've associated with an issue.

Is there a fix/workaround?

This is a really important feature for us to have. When we release a software version, there are ususally a number of issue that existed in previous version(s) that have not been addressed. Therefore the Affects Version(s) field for these issues needs to be updated to include the most recent release. A bulk change on the issues concerned should be able to simply add the new version affected to those already there.

Like Kief, we are working round this with a painful manual process.

Seems that fairly similar code has been created for the bulk move feature... see

http://www.atlassian.com/software/jira/docs/v3.12.3/bulkoperations.html...

Retain Original Values

It is possible to retain original field values that are valid in the target destination by checking the Retain checkbox associated with the field. For example, some issues may already include a valid custom field value - these values can be retained, while issues that require an update will adopt the value specified on the field update screen.
Checked: the original value is retained where possible. The field will not be updated with the specified new value.
UnChecked: all fields will be updated with the specified new value.

I have a half-assed system of getting a list of unresolved issues affecting the previous version, sorting it by "affected version/s", and then selectively bulk editing them in batches which have the same set of affected versions. For example, first I change everything that affects versions 1.0, 1.1, 1.2, 2.0, and 2.1. Then I change everything that affects 1.1, 1.2, 2.0, and 2.1. Then ....

It involves painstakingly going through the "bulk edit" page and ticking those issues that fall into the current batch. Sorting first makes this a bit easier.

But it's still very, very painful.

How are people currently working around this, other than editing issues individually?