- Chris Creswell
- Johannes Drexl
- Amanda Ferrante
- Harry Kaplanian
- Tod Olson
- Aaron Neslin
- Stephen Pampell
- Philip Robinson
- Jason Root
- Chris Rutledge
- Wayne Schneider
- Zeno Tajoli
- Brandon Tharp
- Reference data upgrade
|5||Welcome||Ingolf||Welcome new member Amanda Ferrante ! Amanda is a Product Manager at EBSCO.|
|30||Reference Data Upgrades||Ingolf, Wayne, all|
Find a recommendation of SysOps to the core platform dev team
See the Discuss post here https://discuss.folio.org/t/reference-data-and-upgrades/2858
Wayne summarized the issues and ideas proposed during last week's discussion in the Discuss post referenced above.
We need to describe what we want to have happen. Upgrading a module is really replacing it. When a new module is replaced, Okapi tells the tenant and passes any parameters it has been told to.
We need to make a clear distinction between sample and reference data.
We need a change log.
Would like a diff between the previous state and the current state for the reference data. If we have this, we can give this to the librarians for review.
We also need a log for anything else that might have changed.
Wayne spoke to a developer. We might actually need 3 classes of data:
System data gets loaded either way. Reference data only gets loaded if "loadReference" is set to "true". Changes and deletions will be done in an "overlay record". A User should be able to overlay but never change. The original record will be preserved as a fallback.
How do we report non-fatal errors? FOLIO only supports "success" or "failure" today. We need to add warnings. More verbose logs are required as well. We need to see the steps that occurred. We just don't know what happened.
A proposal must be created and then presented to the TC since this will impact all FOLIO applications in a future release. Once agreement is reached, this change can be planned for a future release. The upgrades should happen in a consistent and meaningful way across Folio. This is important and critical.
Reference data loaded by the system by default should be kept minimal. I.e. there will be only one default location and only one default user group.
|15+||Review Action Items|
SAML: Tod Olson is collecting needed enhancements for SAML authentication. The most obvious needs are to be federation-aware (see - UXPROD-556Getting issue details... STATUS ) and some awareness of SAML attributes for explicit login authorization and possibly other permissions. Will write a Discuss post to solicit and collect input.
Ingolf: This is more a question for the group now (not just a task for Tod): Do we have use cases for consuming SAML attributes ?
|Happy Memorial Day weekend !|
|Topics for future meetings:|
Report from Support SIG
Report about TC Architectural Blueprint / Strategic Changes
Not before June