name/synonym restrictive validation bug on synonym PATCH

[cmgrulke]

Describe the bug Validation as specified in issue #145 is not working as expected when PATCHing a synonym associated with a restrictive synonymQuality

To Reproduce Steps to reproduce the behavior:

1. Create a synonym that is linked to a restrictive synonym quality
2. PATCH that synonym and change only the qcNote
3. See the error stating the synonym.identifier value already exists (which of course it does because this record is a restrictive synonym)

Expected behavior If I am PATCHing a synonym that is already associated with a restrictive synonym quality, changing only the qcNote, source, or synonymType do not need to check if the synonym.identifier exists as a restrictive synonym. In the case above the QcNote should update as it will not create a duplicate in the restrictive identifier set.

[michael-barbour]

I've attached a postman collection as well as a folder containing the same 3 curl requests.

To replicate:

1. Load Seed data. (this will be much easier if we use seed data)
2. Perform requests in order.
   1. First create a restrictive Synonym Quality (save id from response).
   2. Second create a synonym with the Synonym Quality set to your restrictive response (save this id)
   3. Finally patch the same synonym (with the id from your second request and synonym quality from your first)

Any edits made without updating the synonym identifier will fail. If you make a new Synonym Quality and try to reuse the name with the new quality, that will also fail (I'm unsure if that is what is intended)

Other:

• If an identifier is_restrictive, no other restrictive or non-restrictive synonyms may be made using the same identifier.
• If an identifier is non-restrictive, and a restrictive synonym with the same identifier is made, the first identifier may no longer be updated.

145 bug.postman_collection.zip 145 bug curl.zip

[dmlyons2]

@cmgrulke let's chat about this after sprint review and update the def of done.

[cmgrulke]

Well at least make the ticket clearly state the bug. I went to verify the problem just now and encountered some other issues. I will try again on Monday (10/5). I have my calendar blocked for testing and will make this one my first priority.