Consortia (Cross Tenant)
(UXPROD-794)
|
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Consortia (Cross Tenant) |
| Type: | New Feature | Priority: | P5 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ecs-candidate, loc, suppress-from-capplan | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||
| Epic Link: | Consortia (Cross Tenant) | ||||||||
| Front End Estimate: | Large < 10 days | ||||||||
| Front End Estimator: | Khalilah Gambrell | ||||||||
| Front-End Confidence factor: | 20% | ||||||||
| Back End Estimate: | Large < 10 days | ||||||||
| Back End Estimator: | Khalilah Gambrell | ||||||||
| Back-End Confidence factor: | 20% | ||||||||
| Kiwi Planning Points (DO NOT CHANGE): | 1 | ||||||||
| Rank: Chalmers (Impl Aut 2019): | R5 | ||||||||
| Rank: Chicago (MVP Sum 2020): | R5 | ||||||||
| Rank: Cornell (Full Sum 2021): | R5 | ||||||||
| Rank: Duke (Full Sum 2021): | R4 | ||||||||
| Rank: 5Colleges (Full Jul 2021): | R5 | ||||||||
| Rank: FLO (MVP Sum 2020): | R4 | ||||||||
| Rank: GBV (MVP Sum 2020): | R4 | ||||||||
| Rank: hbz (TBD): | R4 | ||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||
| Rank: Lehigh (MVP Summer 2020): | R4 | ||||||||
| Rank: MO State (MVP June 2020): | R4 | ||||||||
| Rank: TAMU (MVP Jan 2021): | R5 | ||||||||
| Rank: U of AL (MVP Oct 2020): | R5 | ||||||||
| Description |
|
Description: Notes: |
| Comments |
| Comment by Hkaplanian [ 11/Jan/19 ] |
|
I find myself wondering what this really means and what is required to support this software wise. For example: The more difficult question might be what does it mean to remove a member library? I would assume a series fo steps such as this: I assume this could take months for an orderly migration that includes planning and shutdown. How often does this happen? It almost feels there is enough functionality in place to support this today. I believe the non-easy parts of this are the planning and time involved between the library and consortia in a multi tenant situation. This seem extra interesting in a multi-library single tenant situation. Steps 1-7 pretty much stay "as-is", but starting at step 8: Again, how often does this really happen? It seems in this case that as long as we have a batch operation feature in place so one could remove all holdings, instances and patrons fro the shared files, we should be ok. The tenant tools are not even needed. Data may need to stay in the system for up to 10 years. But patron data will need to be removed or obscured enough to not track an individual. Its more likely for an institution to close. In both cases, what am I missing? |
| Comment by David Dahl [ 18/Jan/19 ] |
|
I just listened to the SIG discussion about this and had three things to add:
|
| Comment by Hkaplanian [ 22/Jan/19 ] |
|
in reviewing and updating
|
| Comment by Hkaplanian [ 24/Jan/19 ] |
|
Lowered priority since this occurs rarely and is complicated from the perspective of planning between the consortia and member library. We will come back to this one once the other consortia features have been further defined as they appear to happen much more often. Once others are further defined, this can be reviewed for any additional tools or features that might be needed for a consortia to carry this out. That said, the command line tool that Okapi provides may be all that's needed once some of the FOLIO batch data operation tools are built (even though it appears the library data will need to be kept for years after the separation). The multi-library/single tenant might prove that a feature is needed to hide all items and title records that are exclusive to those items. There might be more so
|
| Comment by Khalilah Gambrell [ 14/May/23 ] |
|
Hey Dennis Bridges. Is this feature addressed by another ECS feature? |
| Comment by Khalilah Gambrell [ 18/Dec/23 ] |
|
Hey Dennis Bridges and Joseph Reimers - I added the loc label. I removed the old LC1 label as I am unsure if that is still the priority. |