Epic to link all support issues located in Dev projects (SUP-12)

[ERM-1118] Error on trying to update an `inward` relationship between two agreements to be an `outward` relationship Created: 10/Sep/20  Updated: 18/Jan/21  Resolved: 21/Sep/20

Status: Closed
Project: ERM Platform
Components: ui-agreements
Affects versions: None
Fix versions: None
Parent: Epic to link all support issues located in Dev projects

Type: Bug Priority: P1
Reporter: Kruthi Vuppala Assignee: Owen Stephens
Resolution: Done Votes: 0
Labels: Support, agreements, erm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to ERM-460 Manage linked agreements Closed
Sprint: ERM Sprint 97
Development Team: Bienenvolk
Release: Q2 2020 Hot Fix #3
Affected Institution:
5 Colleges
Epic Link: Epic to link all support issues located in Dev projects

 Description   

Overview:
Steps to Reproduce:
In Agreements 2.3.1 (and possibly earlier, but cannot recreate in Agreements 3.x)

  1. Create two agreements (A1, A2)
  2. On A1, add an "inward" relationship to A2. "inward" relationships are:
  • has post-cancellation access in
  • has demand-driven acquisitions in
  • has frontfile in
  • is superseded by
  1. Save A1
  2. Edit A1 and change the existing relationship to an "outward" relationship. Outward relationships are:
  • provides post-cancellation access for
  • tracks demand-driven acquisitions for
  • has backfile in
  • supersedes
  1. Try to save A1

Expected Results:
Agreement A1 saves with updated relationship

Actual Results:
Status error "422 Unprocessable Entity"
Response:

{
    "total": 1,
    "errors": [
        {
            "code": "typeMismatch",
            "object": "org.olf.erm.SubscriptionAgreement",
            "i18n_code": "org.olf.erm.SubscriptionAgreement.customProperties.typeMismatch",
            "message": "Property customProperties is type-mismatched"
        }
    ]
}

Additional Information:
Curl setting the original "inward" relationship

curl --location --request PUT 'http://localhost:9130/erm/sas/8649da11-6146-41fc-b8bc-3330a025b5a9' \
--header 'Connection: keep-alive' \
--header 'Accept: text/plain' \
--header 'X-Okapi-Tenant: diku' \
--header 'X-Okapi-Token: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJkaWt1X2FkbWluIiwidXNlcl9pZCI6IjNmNzcxYjU0LTA5ZDAtNTJmMi1iZjgxLTA0NGRjNWRiYmRjNCIsImlhdCI6MTYwMDA3NTk3MywidGVuYW50IjoiZGlrdSJ9.PVTFiXxoGNbxalnKrLQLEIATwiL3IhFF96Ns23BfPIQ' \
--header 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36' \
--header 'Content-Type: application/json' \
--header 'Origin: http://localhost:3000' \
--header 'Sec-Fetch-Site: same-site' \
--header 'Sec-Fetch-Mode: cors' \
--header 'Sec-Fetch-Dest: empty' \
--header 'Referer: http://localhost:3000/erm/agreements/8649da11-6146-41fc-b8bc-3330a025b5a9/edit?filters=agreementStatus.active%2CagreementStatus.draft%2CagreementStatus.in_negotiation%2CagreementStatus.requested&sort=name' \
--header 'Accept-Language: en,en-GB;q=0.9,en-US;q=0.8' \
--data-raw '{
    "id": "8649da11-6146-41fc-b8bc-3330a025b5a9",
    "customProperties": {},
    "contacts": [],
    "tags": [],
    "inwardRelationships": [
        {
            "_delete": false,
            "outward": "cbca60ad-b336-4c05-9a3d-38e3e6a5cffc",
            "type": "provides_post-cancellation_access_for"
        }
    ],
    "linkedLicenses": [],
    "docs": [],
    "items": [],
    "periods": [
        {
            "id": "8833ef58-e03e-4b96-b412-8ae6948116ec",
            "startDate": "2020-09-14",
            "owner": {
                "id": "8649da11-6146-41fc-b8bc-3330a025b5a9"
            }
        }
    ],
    "historyLines": [],
    "name": "Agreement_2",
    "orgs": [],
    "usageDataProviders": [],
    "agreementStatus": "active",
    "supplementaryDocs": [],
    "outwardRelationships": [],
    "externalLicenseDocs": [],
    "currentPeriod": {
        "id": "8833ef58-e03e-4b96-b412-8ae6948116ec",
        "startDate": "2020-09-14",
        "owner": {
            "id": "8649da11-6146-41fc-b8bc-3330a025b5a9"
        }
    },
    "startDate": "2020-09-14",
    "endDate": null,
    "cancellationDeadline": null,
    "alternateNames": [],
    "relatedAgreements": [
        {
            "_delete": false,
            "agreement": {
                "id": "cbca60ad-b336-4c05-9a3d-38e3e6a5cffc",
                "customProperties": {},
                "contacts": [],
                "tags": [],
                "inwardRelationships": [],
                "linkedLicenses": [],
                "docs": [],
                "items": [],
                "periods": [
                    {
                        "id": "a494a64e-af06-45e5-b695-1f1e28705bc3",
                        "startDate": "2020-09-14",
                        "owner": {
                            "id": "cbca60ad-b336-4c05-9a3d-38e3e6a5cffc"
                        }
                    }
                ],
                "historyLines": [],
                "name": "Agreement_1",
                "orgs": [],
                "usageDataProviders": [],
                "agreementStatus": {
                    "id": "402881ef748bfe8101748c029869002a",
                    "value": "active",
                    "label": "Active"
                },
                "supplementaryDocs": [],
                "outwardRelationships": [],
                "externalLicenseDocs": [],
                "currentPeriod": {
                    "id": "a494a64e-af06-45e5-b695-1f1e28705bc3",
                    "startDate": "2020-09-14",
                    "owner": {
                        "id": "cbca60ad-b336-4c05-9a3d-38e3e6a5cffc"
                    }
                },
                "startDate": "2020-09-14",
                "endDate": null,
                "cancellationDeadline": null,
                "alternateNames": []
            },
            "type": "has-post-cancellation-access-in"
        }
    ]
}'

CuRL attempting to update to an "outward" relationship

curl --location --request PUT 'http://localhost:9130/erm/sas/8649da11-6146-41fc-b8bc-3330a025b5a9' \
--header 'Connection: keep-alive' \
--header 'Accept: text/plain' \
--header 'X-Okapi-Tenant: diku' \
--header 'X-Okapi-Token: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJkaWt1X2FkbWluIiwidXNlcl9pZCI6IjNmNzcxYjU0LTA5ZDAtNTJmMi1iZjgxLTA0NGRjNWRiYmRjNCIsImlhdCI6MTYwMDA3NTk3MywidGVuYW50IjoiZGlrdSJ9.PVTFiXxoGNbxalnKrLQLEIATwiL3IhFF96Ns23BfPIQ' \
--header 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36' \
--header 'Content-Type: application/json' \
--header 'Origin: http://localhost:3000' \
--header 'Sec-Fetch-Site: same-site' \
--header 'Sec-Fetch-Mode: cors' \
--header 'Sec-Fetch-Dest: empty' \
--header 'Referer: http://localhost:3000/erm/agreements/8649da11-6146-41fc-b8bc-3330a025b5a9/edit?filters=agreementStatus.active%2CagreementStatus.draft%2CagreementStatus.in_negotiation%2CagreementStatus.requested&sort=name' \
--header 'Accept-Language: en,en-GB;q=0.9,en-US;q=0.8' \
--data-raw '{
    "id": "8649da11-6146-41fc-b8bc-3330a025b5a9",
    "customProperties": {},
    "contacts": [],
    "tags": [],
    "inwardRelationships": [],
    "linkedLicenses": [],
    "docs": [],
    "items": [],
    "periods": [
        {
            "id": "8833ef58-e03e-4b96-b412-8ae6948116ec",
            "startDate": "2020-09-14",
            "owner": {
                "id": "8649da11-6146-41fc-b8bc-3330a025b5a9"
            }
        }
    ],
    "historyLines": [],
    "name": "Agreement_2",
    "orgs": [],
    "usageDataProviders": [],
    "agreementStatus": "active",
    "supplementaryDocs": [],
    "outwardRelationships": [
        {
            "id": "c1b4e814-2128-4cb0-91cf-26026c85f8e2",
            "type": "provides_post-cancellation_access_for",
            "inward": "cbca60ad-b336-4c05-9a3d-38e3e6a5cffc"
        }
    ],
    "externalLicenseDocs": [],
    "currentPeriod": {
        "id": "8833ef58-e03e-4b96-b412-8ae6948116ec",
        "startDate": "2020-09-14",
        "owner": {
            "id": "8649da11-6146-41fc-b8bc-3330a025b5a9"
        }
    },
    "startDate": "2020-09-14",
    "endDate": null,
    "cancellationDeadline": null,
    "alternateNames": [],
    "relatedAgreements": [
        {
            "id": "c1b4e814-2128-4cb0-91cf-26026c85f8e2",
            "agreement": {
                "id": "cbca60ad-b336-4c05-9a3d-38e3e6a5cffc",
                "name": "Agreement_1",
                "agreementStatus": {
                    "id": "402881ef748bfe8101748c029869002a",
                    "value": "active",
                    "label": "Active"
                },
                "startDate": "2020-09-14",
                "endDate": null
            },
            "type": "provides_post-cancellation_access_for"
        }
    ]
}'

URL:
Interested parties:



 Comments   
Comment by Owen Stephens [ 10/Sep/20 ]

Kruthi Vuppala Does this definitely only happen when the agreement has related agreements?
In the particular environment does always happen when the agreement has related agreements, or does it only affect specific agreements?

Comment by Kruthi Vuppala [ 10/Sep/20 ]

It happens with the agreement has related agreements: For example If there is a relationship on agreement A to agreement B, the problem is on Agreement B.

Comment by Kruthi Vuppala [ 10/Sep/20 ]

I was able to recreate a part of the error in bugfest-goldenrod environment too:
1. Create Agreement 1, and add a related agreement with relationship "Has post-cancellation access for" Agreement 2
2. Go to Agreement 2,the relationship will appear as "Has post-cancellation access in "Agreement 1""
3. Edit the relationship type on Agreement 2 and change it to "Has post-cancellation access for" , Now I see the error:

{
  "total": 1,
  "errors": [
    {
      "code": "typeMismatch",
      "object": "org.olf.erm.SubscriptionAgreement",
      "i18n_code": "org.olf.erm.SubscriptionAgreement.customProperties.typeMismatch",
      "message": "Property customProperties is type-mismatched"
    }
  ]
}
Comment by Anya [ 11/Sep/20 ]

Owen Stephens- do you have an update for this?

Comment by Owen Stephens [ 11/Sep/20 ]

Anya I'm afraid not. I've not yet been able to work out the cause and unfortunately other issues have taken up my time on Folio today. I'll look again at the start of next week

Comment by Anya [ 11/Sep/20 ]

Thanks for the update Owen Stephens. Former user will this time frame, work for you?

Comment by Charlotte Whitt [ 14/Sep/20 ]

Hi Martina.Schildt and Lisa Sjögren - at today's Support SIG meeting, we were discussing whether this ticket affects any German libraries and also Chalmers which are in production?

Comment by Owen Stephens [ 15/Sep/20 ]

Agreement relationships are reciprocal and can (this bug aside) be edited from either agreement to which they apply. One of the agreements has the "inward" relationship and the other agreement has the "outward" relationship. Because this bug only affects editing an "inward" relationship to become an "outward" relationship, affected sites can workaround the problem by editing the relationship from the other agreement.

The "inward" relationships are:

  • has post-cancellation access in
  • has demand-driven acquisitions in
  • has frontfile in
  • is superseded by
  • relates to

But essentially the temporary work around to seeing this error is to open the other agreement that is in the relationship and making the appropriate edit from that agreement instead

Comment by Lisa Sjögren [ 15/Sep/20 ]

Marie Widigson Have you run into this?

Comment by Felix Hemme [ 15/Sep/20 ]

At ZBW we have not yet had any trouble with this issue, but it's good to know that a workaround exists.

Comment by Marie Widigson [ 15/Sep/20 ]

At Chalmers we have not been using many relations so far and have not yet encountered this issue yet. But good to know about the bug and workaround.

Comment by Owen Stephens [ 16/Sep/20 ]

Comment from SO on why it works:
likely the session being flushed in hibernate when the value is used to lookup the item. I suggest you use that workaround if the UI can send that instead, as a fix would likely be more difficult to roll out on the backend. The session has to flush before it does a lookup, and the unfinished changes are attempted to be written and this is causing an error somewhere. Using the ID doesn't require this behaviour.

The transaction model was completely changed in Gorm7. The fact it works [in mod-agreements 3.x] is good and you should ignore it.

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