Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

All work

Select view

Select search mode

 
29 of 29

Folijet support work for Inventory Optimistic Locking (Data Import and SRS)

Done

Description

NOTE: This feature assesses how much impact the Inventory Optimistic Locking work has on Data Import. If any UI changes are needed (for the Data Import log or error messages in the UI), then a follow-on feature for Lotus will be added

Current situation or problem: Inventory is implementing Optimistic locking in Kiwi. Folijet needs to review and determine how Data Import and SRS may be affected. There are already conflicts when 2 processes, or a person and a process are acting on the same record at the same time. Currently, one set of changes is discarded silently, with no error messages or UI indication. UXPROD-3058 lays out more details so that apps can return messages indicating when record edit conflicts occur. Data Import and SRS will need to react to those messages when the conflict (one of the simultaneous edits) is caused by Data Import.

FOLIO-wide technical proposal: https://folio-org.atlassian.net/wiki/display/DD/Optimistic+locking+proposal
PO doc on detecting and resolving conflicts: https://folio-org.atlassian.net/wiki/display/COMMUNITY/Optimistic+Locking+-++Detecting+and+Resolving+Conflicts+Requirements

In scope

  • Any Data Import or SRS activity that causes changes to any Inventory record (Instance, Holdings, Item) at the same time as another automated process

  • Any Data Import or SRS activity that causes changes to any Inventory record (Instance, Holdings, Item) at the same time as a user editing manually in the Inventory app

  • Any Data Import UI pop-ups and handling user response, if necessary

  • Any Data Import UI log messages or details to reflect conflicts or resolution of those conflicts

Out of scope

  • 2 users manually editing the same record in Inventory at the same time

  • 2 users manually editing the same record in quickMarc at the same time

Use case(s)

  • Data Import is trying to update an instance, holdings, or item at the same time that a user is manually updating the same record

  • Data Import is trying to create a holdings or item on an instance that a user is manually updating at the same time

  • Data Import is trying to create an item related to a holdings that a user is manually updating at the same time

  • Data Import is updating an instance, holdings, or item at the same time that another automated process is updating it (e.g. circulation, aged to lost, another Data Import job)

  • SRS MARC Bib is updated by a Data Import job at the same time that a user is manually updating the same record in quickMARC (or leaves the record open in Edit mode on their screen for an extended period of time)

  • SRS MARC Bib is updated by 2 Data Import jobs running at the same time

  • Would there be use cases where OL would affect matching? (if trying to match from static or from incoming record to Instance, Holdings, or Item value?)

  • Is there a separate implementation that DI will need to do in case an SRS MARC is being acted upon by import B or by QM at the same as import A?

Possible use cases (validate with Kate and Ivan; maybe consolidate with above)

  • Cannot create holdings because instance was in use

  • Cannot create item because instance was in use

  • Cannot create item because holdings was in use

  • Cannot update instance because instance was in use

  • Cannot update holdings because holdings was in use

  • Cannot update holdings because instance was in use

  • Cannot update item because item was in use

  • Cannot update item because holdings was in use

  • Cannot update item because instance was in use

  • Would there be use cases where OL would affect matching? (if trying to match from static or from incoming record to Instance, Holdings, or Item value?)

  • Is there a separate implementation that DI will need to do in case an SRS MARC is being acted upon by import B or by QM at the same as import A?

Proposed solution/stories

Links to additional info

Questions

Priority

Labels

Fix versions

Development Team

Folijet

Assignee

Solution Architect

Parent

Parent Field Value

None

Parent Status

None

Confluence content

mentioned on

Checklist

hide

TestRail: Results

Details

Reporter

PO Rank

112

Back End Estimate

Small < 3 days

Release

Lotus R1 2022

Rank: Cornell (Full Sum 2021)

R1

Rank: U of AL (MVP Oct 2020)

R1

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created July 9, 2021 at 9:29 AM
Updated March 7, 2022 at 7:11 PM
Resolved March 7, 2022 at 7:11 PM

Activity

Show:

Martin TranNovember 22, 2021 at 3:40 PM

Hi , yes, the PTF can test DI with/without OL in the next couple of weeks.

Ann-Marie BreauxNovember 22, 2021 at 1:03 PM

Hi Just wanted to check on whether UIDATIMP-995 and UIDATIMP-996 can be tested in the next couple of weeks. I don't think there's additional work that Folijet needs to do for Kiwi, but it would be good to have confirmation on these issues so that it's clear if any work is needed in Lotus. Thank you!

Ann-Marie BreauxSeptember 1, 2021 at 1:53 PM
Edited

Grooming:

  1. Folijet resolves the PTF P1 bug UIDATIMP-997

  2. PTF test DI performance before the OL changes in MODINV UIDATIMP-995

  3. Merge the MODINV and MODINVSTOR changes (Prokopovych)

  4. PTF retests DI performance after the changes UIDATIMP-996

  5. We're confident that DI will not stop/die when it encounters OL error message from Inventory. Folijet may describe or test to ensure that DI doesn't stop or get stuck when an Inventory record is being manually edited, or SRS MARC is being manually edited in QM, while import is also trying to act on it. See if we can figure out how to trigger it, but it may be difficult to trigger UIDATIMP-998

  6. Look at the error message that is triggered for DI and see if we need any UI story, or if existing error message is clear enough

Ann-Marie BreauxAugust 25, 2021 at 1:15 PM

Grooming: for Kiwi focus on unblocking the problems when Julian merges existing changes. Will need to test DI performance before and after the merge. If any problems with versioning, then the job will be completed with errors.

Next steps: to write the BE stories and to review

If a record is being used, then we will end up with "discarded" on the summary page. Once DI can accept OL errors, try and see if we can trigger the error. Then meet with Ivan and Kimie to discuss UI options, which may need to be in Lotus.

Ann-Marie BreauxAugust 12, 2021 at 1:04 PM

Next steps in defining this feature:

  1. scheduling meeting for next week with , , and optional , to go over OL and implications for DI backend

  2. to outline design for required DI BE work

  3. to finalize Inventory UI requirements (https://folio-org.atlassian.net/browse/UIIN-1245 and https://folio-org.atlassian.net/wiki/display/COMMUNITY/Optimistic+Locking+-++Detecting+and+Resolving+Conflicts+Requirements)

  4. to finalize DI UI requirements with Folijet UI devs and the SMEs

TestRail: Cases
TestRail: Runs