Inventory (UXPROD-785)

[UXPROD-2450] Holdings record. Holdings statements notes. Public and Staff only. Created: 08/Jun/20  Updated: 16/Sep/20  Resolved: 04/Sep/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q3 2020
Parent: Inventory

Type: New Feature Priority: P3
Reporter: Charlotte Whitt Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: migration-load, migrations, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Skärmavbild 2020-07-23 kl. 19.05.34.png    
Issue links:
Blocks
blocks UIDATIMP-642 Field mapping profile: Holdings: Add ... Closed
Defines
is defined by MODINVSTOR-543 Holdings. Holdings statements notes. ... Closed
is defined by UIIN-1215 Holdings. Holdings statements notes. ... Closed
Gantt End to Start
has to be done before MDEXP-231 Mapping profile - provide field name ... Closed
Relates
relates to UXPROD-559 Migrate Bibliographic & Holdings data Closed
Epic Link: Inventory
Development Team: Prokopovych
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: hbz (TBD): R4
Rank: MO State (MVP June 2020): R4

 Description   

Overview: When migrating data there is a need for University Chicago, Cornell, Duke and other libraries to have the possibility to mark holdings statement notes either as public notes or non public. As these notes are repeatable in MARC, then the requirement is to have these holdings statements notes in the holdings being repeatable. Having the statements notes being repeatable will make the mapping for Data Import and Data Export easier.

Usecase:
As a cataloger/technical staff I need to be able to distinct between holdings statements notes which data which is to be viewed only by staff (non public) or to be be displayed in e.g. the Discovery, or populated in ILL systems, so these holdings statements notes are to be marked as public notes.

UX-mock ups to be discussed with the MM-SIG 6/25/2020:
https://docs.google.com/presentation/d/1NEmSyiBbEtRNPZiCQNjbv29bioXRRRToxY9R4qfrKZA/edit#slide=id.g80bbd261b6_0_62

  1. Inventory holdings record:
    • When adding a holdings statement in the edit view of the holdings record, the holding statement row have 3 data element boxes:
      • holdings statement
      • public note
      • staff note
    • The two note types are both repeatable
  2. Data import mapping
    • incoming MARC records with holdings statements notes: If there are multiple $x or $z in an one incoming 866/67/68 field, these will be migrated as separate data elements for each $x and each $z. The display in Inventory will be aligned with the display in a potential underlying MARC holdings record in SRS.
  3. Data export of MARC formated holdings records
    • then the mapping out will also be having each staff note data element to be mapped into separate $x and each public note data element to be mapped into separate $z.

At meeting 6/25/2020 the MM-SIG decided not to follow the general UX for notes as implemented for instance notes, holdings notes, and item notes.

NOTE (from Ann-Marie Breaux) This has relevance for Data Import, Data Export, and Data Migration since the schema change will affect how data is mapped from incoming MARC Holdings, mapped to outgoing MARC holdings created on-the-fly, and existing holdings data that is being migrated into FOLIO. Data import and Data export will probably be dealing with this in Q4 2020. Not sure about the timing or urgency for Data migration. cc: Magda Zacharska Ian Walls



 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 20/Jul/20 ]

Hi Charlotte Whitt and Ian Walls This seems to me to be a blocker for migration of holdings data. Right now, if a library migrates their holdings notes into the Inventory Holdings record, public and staff notes will be smushed together. Then when the two separate fields are created for the Inventory holdings record, that data will need to be split somehow. Is there any chance of increasing the priority for this so that it gets done in Q3??

cc: Cate Boerema Hkaplanian

Comment by Ian Walls [ 22/Jul/20 ]

If one is planning on using the mapping rules to build their Holdings records, then yes, this could throw a monkey wrench into the works. But up until now, I've just made my Holdings record without the mapping, relying on custom scripting.

What volume of data is expected to be impacted by public/non-public notes on the holdings statements?

Comment by Ann-Marie Breaux (Inactive) [ 23/Jul/20 ]

I'm not sure - it would probably be worth a convo with MM SIG - maybe just on the Slack channel. Will it be a discovery, migration, import, and/or export issue, if the public/staff notes for holdings statements are smushed together for now, and may be separated in the future, when separate public/staff options are available? If it's an issue, can you estimate how many records or percentage of records might be affected for your library? Other thoughts? I'm happy to post to the Slack channel if you think it would be helpful

Comment by Charlotte Whitt [ 23/Jul/20 ]

The thing is, that this could be solved easily by just adding an extra element to the holdings statement array, but if we are suggesting having multiple staff notes, and multiple public notes to one statements, then remodeling is needed.
I'll reach out to uChicago, which felt the strongest about having the possibility to add multiple notes.

CC: lew235

Comment by Charlotte Whitt [ 23/Jul/20 ]

Christie Thomas Natascha Owens and I reviewed the suggested solutions and we agreed upon implementing the solution adding one extra data element to the existing array, which will make it possible to distinct between staff notes and public notes. Multiple notes from each category will then be concatenated, and separated by a ";"

Comment by Ann-Marie Breaux (Inactive) [ 23/Jul/20 ]

Excellent! That sounds like a fine solution to me. Any ideas on when this might be implemented? Did Chicago say whether it was important to have it sorted out at point of migration, or could they wait? Duke is the other one that (I think) would have a strong opinion about it.

Comment by Charlotte Whitt [ 23/Jul/20 ]

Ann-Marie Breaux yes, I'll talk with Cate Boerema and let's hope we can have this tabled rather sooner than later.

Comment by Cate Boerema (Inactive) [ 03/Sep/20 ]

Hi Charlotte Whitt. I think this UXPROD can be closed.

Generated at Fri Feb 09 00:24:04 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.