MODQM-338: Handling Unsaved/Saved Links When Updating a MARC Authority Record Before Saving a Bib Record in Create/Edit/Derive Bib Feature

Owned by Pavlo Smahin
Last updated: May 18, 2023
3 min read

MODQM-338 - Getting issue details... STATUS

Objective

Implement consistent behavior for when a user is creating/editing/deriving a bib record WITH a linked bib field that has not been saved AND at the same time another user has a.) edited the linked authority record 010 subfield a (if it populated the linked bib field subfield 0, b.) edited the 1XX  number or the 1XX controlled subfield value, OR c.) deleted the authority record before the user has saved the bib record. 

Requirements

  • Authority 010 $a change: If the authority record 010 $a is the value used to populate a linked bib field's $0 AND that 010 $a is edited WHEN user Saves the bib record THEN the bib field $0 is updated with the new 010 $a value.
  • Authority 010 $a addition:  If authority 010 $a has been added to an authority record (and is eligible to populate bib subfield 0) AND linked bib fields $0 were populated with authority 001 WHEN user Saves the bib record THEN the bib field $0 is updated with the new 010 $a value.
  • Authority 1XX change: If the authority record 1XX controlling subfield values have been updated or removed or added WHEN user Saves the bib record THEN the linked bib field controlled values should be updated.
  • Authority 1XX number change: If the authority 1XX is changed to another 1XX WHEN user Saves the bib record THEN unlink the bib field from authority record AND continue to Save record.  Must inform user that the field is no longer linked. Implementation options outlined under Linked status update notification options section.
  • Authority 1XX has removed or added a $t and bib field is no longer eligible to be linked: WHEN user Saves the bib record THEN unlink the bib field from authority record continue to Save record. Must inform user that the field is no longer linked.  Implementation options outlined under Linked status update notification options section. 
  • Authority record deleted: WHEN user Saves the bib record THEN unlink the bib field and keep the metadata that was provided by the now deleted authority record AND continue to Save record. Must inform user that the field is no longer linked. Implementation options outlined under Linked status update notification options section. 

Expectation: Update Success toast notification with a note that link updates are in progress SHOULD display this notification when one bib field is linked to an authority record. 


Findings

Observations

  1. QuickMarc UI uses:
    1. PUT endpoint for an update. The current endpoint has internal processing of links and uses endpoint to create/update/delete links in mod-entities-links storage
    2. POST endpoint for creating/deriving a record and endpoint to create/update/delete links in mod-entities-links storage. Moving the usage of the links endpoint to the internal process of the POST endpoint could be done after the module will migrate to the data-import process.
  2. mod-entities-links has logic for updating controlled fields in bib/instance records when related authority was updated.

Recommendations

The common links endpoint has to be improved to validate/renovate links in bib/instance records.

  1. Add validation to the endpoint to reject saving links to deleted authorities. Return response with 422 status code and having authority UUIDs that were not found in the system. This response could be used by:
    1. UI by showing an error message and stopping saving or showing pop-ups, removing invalid links data, and retrying
    2. mod-quick-marc by removing invalid links and retrying
  2. After links were successfully saved to the database - use existing logic to renovate controlled fields in bib/instance records.

Implementation details

Validation 

mod-entities-links consumes Kafka messages from inventory.authority topic and saves to own database some data about authorities. authority_data table contains authority ID and flag that indicates that authority is actual or deleted. This data could be used to validate links on the PUT endpoint.

Renovation

After links were successfully saved to the database additional logic of renovation have to be added. This logic has to trigger updates in bib/instance records and contains such steps:

  1. Use inventory-storage or search endpoints to batch-fetch authority records.
  2. Use source-record-storage endpoint to batch-fetch related source records.
  3. Combine fetched data into one Kafka message using existing logic for creating similar messages.
  4. Send a created message to the links.instance-authority Kafka topic. There is no need to create an entry in the authority_data_stats table because at the current moment, there are no authority changes and we don't need to track renovate process in the table.
These changes may result in a slight reduction in endpoint performance. To mitigate this impact, we can consider making the operation asynchronous. By implementing asynchronous processing, we can minimize the performance impact and allow the operation to proceed without affecting the overall system responsiveness.

Estimation

  1. mod-entities-links - 1 story - 5-8 SPs
  2. testing and hardening - 5 SPs