Add Support for D2IR API Integration with INN-Reach Resource Sharing Systems
(UXPROD-2598)
|
|
| 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: |
|
||||||||||||
| 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?
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. |