Skip to:

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

INN-Reach: Ability to activate/deactivate ongoing record contribution on-demand

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

Priority

Labels

Fix versions

None

Development Team

Volaris

Assignee

Solution Architect

Parent

Parent Field Value

None

Parent Status

None

Checklist

hide

TestRail: Results

Activity

Show:

Tim Auger March 24, 2023 at 3:03 PM

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

Brooks Travis February 22, 2023 at 4:02 PM

 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.

Tim Auger February 21, 2023 at 12:21 AM

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.  

    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?

Tim Auger October 31, 2022 at 12:47 PM

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

Arin Suryavanshi October 17, 2022 at 6:31 AM

Hi 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).

Details

Reporter

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.

PO Rank

99

Front End Estimate

Large < 10 days

Front-End Confidence factor

90%

Back End Estimate

XXL < 30 days

Back-End Confidence factor

90%

Rank: Cornell (Full Sum 2021)

R5

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created September 16, 2022 at 4:44 PM
Updated November 30, 2023 at 4:41 PM
TestRail: Cases
TestRail: Runs