Add Support for D2IR API Integration with INN-Reach Resource Sharing Systems (UXPROD-2598)

[UXPROD-3804] INN-Reach: Ability to activate/deactivate ongoing record contribution on-demand Created: 16/Sep/22  Updated: 30/Nov/23

Status: In Refinement
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Add Support for D2IR API Integration with INN-Reach Resource Sharing Systems

Type: New Feature Priority: P3
Reporter: Brooks Travis Assignee: Tim Auger
Resolution: Unresolved Votes: 0
Labels: epam-volaris, inn-reach
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to MODINREACH-312 SPIKE: UXPROD-3804 Closed
relates to UXPROD-3679 Record Contribution Enhancements ("Bi... In Refinement
Potential Workaround: Deactivating the bib transformation options will prevent new bib records and their attached items from being contributed, but does not prevent updates to already-contributed item records.
Epic Link: Add Support for D2IR API Integration with INN-Reach Resource Sharing Systems
Front End Estimate: Large < 10 days
Front-End Confidence factor: 90%
Back End Estimate: XXL < 30 days
Back-End Confidence factor: 90%
Development Team: Volaris
PO Rank: 99
Rank: Cornell (Full Sum 2021): R5
Solution Architect: Raman Auramau

 Description   

Current situation or problem:

The current INN-Reach integration implementation for ongoing record contribution (evaluation and contribution/update/de-contribution of bib and item records when they are modified in FOLIO) is an "always on" process, and will contribute records whenever they are evaluated and found the meet the criteria for contribution. The is currently no mechanism to stop/start this process. We would like to add such a mechanism to allow the library to control the process should the need arise.

In scope

UI/UX for activating/deactivating ongoing contribution

Back-end approach for providing such facility

Out of scope

Use case(s)

Proposed solution/stories

Links to additional info Mockup Slides

Questions



 Comments   
Comment by Arin Suryavanshi [ 13/Oct/22 ]

Hi Tim Auger I've one question regarding activate/de-activate contribution, in case of already contributed bib, when a new item added to the contributed bib whether it should be contributed as it is different from updating current items in the contributed bib.

Comment by Brooks Travis [ 13/Oct/22 ]

@Arin Suryavanshi The desired behavior is that all record contribution be blocked, item or bib.

Comment by Arin Suryavanshi [ 17/Oct/22 ]

Hi Tim Auger do we need to track the events of contribution activation/deactivation such as contribution paused_by (userId), resumed_by (userId), paused_at (time), resumed_at (time).

Comment by Tim Auger [ 31/Oct/22 ]

Arin Suryavanshi sorry for the delayed in responding. Is there a log where events are already recorded? I'll still answer "yes" we should track.

Comment by Tim Auger [ 21/Feb/23 ]

Brooks Travis We are reviving this request but I have a few questions...

I know of a couple use cases for ongoing contribution but not sure if these are what you had in mind?

    1. Configuration changes. For example, changes to mapping within FOLIO. A customer would pause it, make the changes, resume, pause again to confirm (at central) that they took effect and then resume. If this is one of the cases, then we will also need to make sure that pause invokes the re-reading of mappings.
    2. IP address changes. Presumably, we'd want to advise customers to pause contribution until the IP address change was made at central. Presumably, the rare case of a central IP changes would be taken care of here as well.
    3. Bugs. Something bad enough to pause contribution until it's fixed.

The case for initial record load could be the same but we might do one better by allowing the user to specify a set of records. Until we have FRM, I don't think that's a option, right? For Sierra sites, the initial contribution usually starts with a hand-selected set of records that tests the configuration. Records are then released to central and when the set of records have been processed, an implementation consultant and the customer review the records together to validate the config.

Are there any other use cases for either the ongoing or initial record contribution you had in mind?

Comment by Brooks Travis [ 22/Feb/23 ]

Tim Auger I think that mostly covers it. On the initial contribution part, we never really considered the ability to limit the set of records included in the job. I believe this was a byproduct of the choice to utilize the instance iteration facility originally created for elastic search re-indexing to feed the contribution job. Other parts of the contribution configuration (specifically the statistical codes and location-based contribution criteria) are used to manage what is actually sent and what isn't.

Comment by Tim Auger [ 24/Mar/23 ]

Moved this to the backlog since the TAM for D2IR API is quickly dwindling. For more info, please reach out to me. 

Generated at Fri Feb 09 00:34:56 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.