[ERM-1249] Saving and/or retrieving LicenseAmendmentStatus records is not always successful Created: 20/Nov/20  Updated: 04/Jan/21  Resolved: 04/Jan/21

Status: Closed
Project: ERM Platform
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P2
Reporter: Carole Godfrey Assignee: Owen Stephens
Resolution: Won't Do Votes: 0
Labels: agreements, erm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File agreement-to-duplicate.png     GIF File dup-agree-unassign-amendments.gif     PNG File dup-agreement.png     Text File erm-1249-GET-request.txt     File erm-1249-GET-response.json     Text File erm-1249-PUT-request.txt     File erm-1249-PUT-response.json     PNG File license-with-amendment.png    
Issue links:
Relates
relates to SUP-22 Save sometimes does not behave as exp... Closed
Sprint: ERM Sprint 103, ERM Sprint 104
Development Team: Bienenvolk
Affected Institution:
Chalmers

 Description   

Overview:
On Goldenrod saving and/or retrieving LicenseAmendmentStatus records is not always successful

Steps to Reproduce:

  1. Log into Goldenrod FOLIO environment (mod-agreements 2.3.1, ui-agreements 4.0.4)
  2. Create a license
  3. Create an agreement
  4. Link License to Agreement with status set as Controlling
  5. Add an amendment to license
  6. Edit agreement, set new amendment status in Agreement and save agreement
  7. View agreement and check to see if all amendments are assigned

Repeat the last three steps until you see that even though all amendments were assigned when you saved the agreement (penultimate step), they are reported as not assigned when you view the agreement

Expected Results:
After saving an Agreement with assigned amendments, the amendments should show as assigned when you view the agreement

Additional Information:
Issue confirmed in Goldenrod Bugfest environment, but not successfully recreated in Snapshot which suggests it does not effect latest version of mod-agreements
Multiple amendments seem to be required to recreate the issue
Issue created when working directly with Okapi endpoint so doesn't seem UI related
Attached are the PUT request and response that shows all the amendments assigned, and the subsequent GET request and response for the same agreement which shows only one Amendment

Interested parties:
Martina Karlsson



 Comments   
Comment by Carole Godfrey [ 23/Nov/20 ]

Owen Stephens
This issue is also observed when editing and saving an agreement with unassigned amendments - (to try and correct the assignments).
As noted by Martina Karlsson when correcting these, saving looked ok but all the amendments were then unassigned. She created a video of this issue:
https://chalmersuniversity.box.com/s/nq96eda8q87203i0vfkj70vf93i4ngpt
If she edits the same agreement again, and assigns all amendments, it works fine.
Issue appears with saving in addition to duplicating

Comment by Owen Stephens [ 25/Nov/20 ]

Martina Karlsson Carole Godfrey Khalilah Gambrell I'm having difficulty replicating this on https://bugfest-goldenrod.folio.ebsco.com at the moment. Are you able to replicate on there?

Comment by Owen Stephens [ 25/Nov/20 ]

Also it would be great to see the bodies of the POST (on duplicating) and PUT (on saving) requests that lead to these situations

Comment by Owen Stephens [ 04/Jan/21 ]

The underlying cause is due to an issue with the version of the Grails software framework we were using for mod-agreements 2.x.x (Goldenrod uses a mod-agreements 2.x.x release). As of mod-agreements 3.x.x (used in Honeysuckle) we’ve upgraded to the latest version of the Grails framework and this has fixed the problem going forward. However, it isn’t possible for us to back port this fix to mod-agreements 2.x.x because the solution depends on the new framework - and it simply isn’t possible to retrospectively upgrade 2.x.x to use the newer framework.

Generated at Thu Feb 08 22:21:18 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.