Recordings are posted Here (2022+) and Here (pre-2022) Slack channel for Q&A, discussion between meetings
...
Attendees: Ann-Marie Breaux (Deactivated) Timothy Watters Jennifer Eustis Lynne Fors Monica Arnold Autumn Faulkner Jenn Colt Lloyd Chittenden Taylor Smith Lisa McColl
- Lotus Hotfix Bug created for Instance Status request last update date being accidentally reset during import: fix has been made; waiting for 3rd approval for the hotfix. will be releasing this week
- Inventory Single Record Import: Overlays for Source=MARC Instances retain 003 when they shouldn't
- Awaiting Lotus HF approval release for the fix to remove the 003
- Complete fix for the 001/003/035 behavior will be in Morning Glory; too large and risky for Lotus HF
...
- Deleting import logs
- Has been completed for the Landing page
- Still in progress for the View all page
- Get the Lab Rancher env set up (A-M with Kitfox)
- Data Import permissions - which is preferred for users who are allowed to delete import jobs
- Assign 1 permission that gives the user power to upload files, import files, view logs, delete logs (aka import "super-user") - and fix the name
- Assign 2 permissions
- Upload files, import files, view logs (aka import "regular user")
- Delete logs (a separate, additional permission
- Add permission in Nolana (maybe MG) for Access to DI Landing page and View all, and View-only for logs, but not Upload or Import
- Use case: Inventory Single Record Importers who just want to be able to check on jobs, but are not authorized to do non-Inventory imports
- MARC field protections - Initial User Acceptance testing
- As of Morning Glory
- MARC field protections are invoked when action profile is Update Instance, as well as when action profile is Update MARC Bib
- Will there be a problem if you have to have an Update MARC Bib action in the job profile to override field protections?
- Per Jennifer - 5C preference is NOT to invoke field protections when updating an instance
- Have reworked the logic for repeatable vs non-repeatable fields
- MARC field protections are invoked when action profile is Update Instance, as well as when action profile is Update MARC Bib
- See 5 Colleges Jira and TestRail - walk through it on folio-snapshot
- Last step (modification to remove 856) fails
- SRS MARC shows Updated instead of Created; Instance shows Multiple instead of Created
- If an earlier action in the job is Create SRS MARC (Implicit in the Create Instance action), then if there are modifications to the MARC further down in the job, always treat it as create, so that field protection doesn't invoke
- And thus in MODDICORE-248, the 856 would be deleted from the SRS MARC and the e-access info would be deleted from the Instance
- Also change log SRS result from Updated to Created, and Instance from Multiple to Created
- Because these records didn't exist before the job started, and the
- Other scenarios for acceptance testing and TestRails
- Can we walk through any/edit any in today's meeting?
- If notUse Update any of the following TestRails to include other field protection scenarios or use cases:
- MARC Modifications and MARC Field Protections: DRAFT Scenario 1
- MARC Modifications and MARC Field Protections: DRAFT Scenario 2
- MARC Modifications and MARC Field Protections: DRAFT Scenario 3
- MARC Modifications and MARC Field Protections: Remove fields from MARC BIB for OCLC Import
- Also use the lab time tomorrow?
- Homework for next week?: Test the heck out of MARC field protections, and document any bugs
- Once we're confident about MARC field protections, test overriding MARC field protections with MARC Update profiles - document any bugs before and during MG Bugfest
- As of Morning Glory
...