change name of an agreement with local resource AL fails
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
blocks
Checklist
hideTestRail: Results
Activity
Jag Goraya October 14, 2020 at 3:14 PM
For Honeysuckle
Owen Stephens October 13, 2020 at 12:57 PM
Following PR #371 the agreement name can now be updated when there are agreement lines, but a POST to /erm/sas/ now fails if there is no items array specified.
e.g. this CuRL fails:
but this succeeded
It should be possible to POST or PUT an Agreement without an Items array
Stack trace for failure seems to confirm that this issue is related to PR #371
Owen Stephens October 12, 2020 at 11:36 AM
Summary of Slack discussion:
Upgrade to Grails 4 seems to have led to the previous minimal items (aka entitlements/agreement lines) array being omitted on returning the agreement
This was "fixed" by https://github.com/folio-org/mod-agreements/pull/352 but this led to the full items object being included in the agreement
Including the full entitlements object broke the UI processing because it uses the presence/absence of certain information in the items objects as part of its processing logic - when the items previously (pre-Grails 4) only consisted of an `id` then this worked fine. Once the full item object was included (post PR #352) this logic didn't work
Immediate solution (for Honeysuckle release) is to ensure that when returning the items inside the agreement we only include the minimal information (the `id`) - which replicates the pre-Grails 4 behaviour
Medium term - we should re-examine the way the UI interacts with the items objects and see if (a) we need to include items in the agreement at all, and (b) if so, make sure the UI is using appropriate logic for making decisions on how to process the items
Owen Stephens October 12, 2020 at 11:29 AMEdited
More (long) Slack discussion
https://folio-project.slack.com/archives/CAYCU07SN/p1602154991082100
Owen Stephens October 8, 2020 at 11:42 AM
More analysis on this:
I think that /erm/sas is now more verbose about items combined with this line in the UI (which has always been there):
https://github.com/folio-org/ui-agreements/blob/81e44e5bafa487345ad3b333291941dce9ff6580/src/routes/AgreementEditRoute.js#L298
Means the UI sees a full item in the /erm/sas response, and that leads it to submit the full item back rather than the reduced fields which are in that if statement in AgreementEditRoute.js
src/routes/AgreementEditRoute.js:298
it looks to me like this PR led to more data being returned for items on retrieving the agreement https://github.com/folio-org/mod-agreements/pull/352 - can you have a look?
Details
Details
Assignee
Owen StephensReporter
Claudia MalzerComponents
Labels
Priority
P2
Overview:
Steps to Reproduce:
Log in to folio-testing or snapshot
open Agreements App
add a resource from E-resources to the basket
create an agreement and add an agreement line with the resource from the basket linked to it
try to edit agreements name
Expected Results:
agreements name is changed
Actual Results:
the green box with the message
Agreement updated: <agreement name>contains the edited name, but this new name is neither shown in the agreements list nor in the detail view of the agreement, even after a page reloadAdditional Information:
the error only happens with agreement lines linked from the basket.
it doesn't occur with ALs from eHoldings or ALs w/o resource
OS analysis
The issue seems to be caused because the JSON object for the entitlement/agreement line includes the "owner" object. See the example below - the "name" property of the agreement is "OS Test Agreement 98" but in the items[0].owner the "name" property is still the existing agreement name "OS Test Agreement 99". Suspect omitting this property will solve the problem