Issue Summary

When a project has one or more archived versions, and any user attempts to edit that issue in order to either add or remove said archived version, the user will not see any sort of error or failure to indicate that this is not something they can do via REST API update.

Steps to Reproduce

1. In a project create two issues, example issue keys ABC-1 and ABC-2
2. Create a version in that project called 'example'
3. Add 'example' version to the FixVersion field of ABC-1
4. Archive the 'example' version (Project settings > versions > ... Archive
5. using the REST API, attempt to add 'example' to the FixVersion field of ABC-2
6. using the REST API, attempt to remove 'example' from the FixVersion field of ABC-1

Expected Results

For steps 5 and 6: We would expect that if this issue edit is somehow unsuccessful, that Jira would provide some kind of indication of this in the REST API response here. Such as a HTTP 400 error with an error message that indicates something along the lines of a bad-request, or perhaps something more targeted to indicate that the version cannot be modified

Actual Results

REST API call provides an HTTP 204 response. In turn the end user/script has no idea that their edit did not actual go through as planned.

End user has no indication that this particular version is archived.

If an end user in the web UI attempts to make this change, they can at least see that a version is archived and not-removable from an existing issue where it is applied.

Workaround

A project administrator (or system admin) must first unarchive that version. Once this is done any user with permissions to edit that issue can then make changes via REST APi successfully.