Overview:

If you have an agreement with an agreement line for an item in the local KB, when the agreement is saved via the UI, the agreement does not update as expected

Steps to Reproduce:

1. Access https://bugfest-orchid.int.aws.folio.org/erm/agreements/e5565ec3-6fdf-4153-81af-9b8477ab256e

2. Edit the agreement name (e.g. try to remove the full stop at the end of the name)

3. Click save and close

Expected Results:

The agreement is saved with new name

Actual Results:

The agreement seems to save but the name is not updated

Additional Information:
It looks to me like the inclusion of the `owner` property in the `item` (agreement line), which includes the full agreement JSON (which includes the non-edited title) is being used to update the agreement, as well as the main agreement PUT. So essentially this is creating two saves for the agreement - firstly with the edit (in the main agreement JSON) and secondly without the end (in the agreement/agreement line/owner JSON)

If I amend the PUT request to omit the `owner` component fro within `items` then the save works as expected

Interested parties:

CSP justification

Describe issue impact on business

This makes it impossible to edit some fundamental properties of an agreement that has an agreement line linked to the internal knowledge base. For example, the agreement name cannot be updated. This makes it impossible for institutions to manage their agreements effectively.

What institutions are affected? (field “Effected Institutions” in Jira to be populated)

All

What is the workaround if exists?

No workaround exists.

What areas will be impacted by fix (i.e. what areas need to be retested)

• Editing agreements

Brief explanation of technical implementation and the level of effort (in workdays) and technical risk (low/medium/high)

0.5 days work (already done).

This change is Orchid specific and so will only be implemented on an Orchid branch. Other solutions are being adopted for Poppy and so this fix is not relevant to the current master branch of the application.

The change is to strip out the `owner` information embedded in the `item` in the Agreement Edit routes in the UI so that on submit the item does not include a copy of agreement properties

Low technical risk. The work only affects the UI and the changes are isolated to a single route in ui-agreements. The main risks are:

1. The need to iterate through the list of agreement lines in an agreement leads to a noticeable speed penalty

There will inevitably be a speed penalty to this, but it is isolated to the UI. We will compare speeds with/without the fix to check that the additional processing does not cause an unacceptable degradation. 

We will test editing agreements with a large number of agreement lines of different types to ensure that all scenarios are tested

Brief explanation of testing required and level of effort (in workdays). Provide test plan agreed with by QA Manager and PO.

0.5 days work

Test plan:

Agreements with 200 agreement lines of the three different types:

• Internal

• External

• Detached

Will be created in the Orchid bugfest environment. These will be tested to check that they can be viewed and updated as expected with reasonable performance

• Fix released in updated ui-agreements for Orchid which will be deployed to https://bugfest-orchid.int.aws.folio.org/: Run tests on https://bugfest-orchid.int.aws.folio.org/

Several agreements with many agreement lines have been created in the Orchid bugfest environment for testing.

Tests

• Create an Agreement

  • https://foliotest.testrail.io/index.php?/cases/view/757

• Edit an agreement

  • https://foliotest.testrail.io/index.php?/cases/view/758

  • Repeat for agreements with 100 and 200 agreement lines of each type

  • Specifically ensure that updating the following fields on the agreement works:

    • Renewal priority

    • Period notes

    • Supplementary properties

    • Agreement name

• Duplicate an Agreement

  • https://foliotest.testrail.io/index.php?/cases/view/9252

  • Repeat for agreements with 100 and 200 agreement lines of each typ

What is the roll back plan in case the fix does not work?

The fix will be implemented by a patch version of ui-agreements. If the fix doesn't work / causes issues the roll back will be a to revert the code changes and do a further patch version to restore previous functionality