UIs for MARC field mapping detail screens

Purpose: To hold the various stories involved in sorting out the UI details for field mapping as well as the syntax that will be used

Key links:

• Spreadsheet with all fields and syntax: https://docs.google.com/spreadsheets/d/17kCccovBR-RAVK-coW7fpXvJfaRmYA2mUHoVLSF9Spo/edit#gid=141717922
  • Syntax examples are the last sheet
  • List of all combined fields is next-to-last sheet
• Prototype of item record field mapping details: https://ux.folio.org/testing/data-import/1004/
• Intro meeting recording: 20200108 Field Mapping Details Intro Mtg
  https://ebscomeetings.webex.com/recordingservice/sites/ebscomeetings/recording/playback/82e2b90f72124c6b88734217c49a5537
• What else?

Key concepts on the field mapping details screen

• The field mapping screen looks as similar to the record's normal create/edit screen as possible in terms of labels and layout, so that it is familiar to the user
• All fields from the record's create/edit screen shows. If they are not editable for the user, they are greyed out (e.g. HRIDs)
• Accordions
  • For Create, start with all accordions expanded
  • For Edit, start with all accordions closed, but have an Expand all/Collapse all option
  • For View, start with all accordions closed, but have an Expand all/Collapse all option
  • If too difficult, start with all open, but then refine in the future
• A toggle indicates whether each field is affected by the field mapping profile. It starts as grey/unaffected, and then changes to blue/affected when someone enters data into the field or clicks the toggle. It automatically changes back to grey if the field is emptied by the user or if they turn off the toggle, the field is emptied.
• Fields may have a value that indicates a field from the incoming record and/or a default value
• Fields may have a sequence of values, e.g. "look in this field first; if not there, then look in this field; if not there, then assign this default value"
• The field mapping screen has to be responsive to changing record schemas (first pass: make the form work, then how to account for changed schemas)
• Field names have to be responsive to the tenant's customizations (e.g. when custom fields are added to a particular record type in the future, those fields need to show on a tenant's field mapping screen
• Values for dropdown lists in the field mapping screens will vary from tenant to tenant, and will often come from the settings for various apps (usually mod-config, I think?)
• Fields that are controlled by default MARC-to-Inventory map are greyed out/not mappable. These fields will vary from tenant to tenant, so must be responsive to the tenant's default maps. Maybe in the future, the tenant's default mapping will show in the greyed out fields, when we have a UI (instead of just the CLI) to edit that default mapping.
  • How to decide what is not mappable/editable; e.g. controlled by Source = MARC in Instance
• Required fields are indicated with an asterisk.
  • TBD: should we make them required or no? Would be good if the action is create, but maybe not good if the action is combine/overlay
• The required fields may vary within a record, depending on which options are selected (e.g. order screen when you choose one time vs ongoing, physical vs electronic)
• Validation needed when creating/updating the Field mappings
  • The syntax and punctuation
  • MARC fields (numerics, subfield indicator)
  • Non-repeatable fields
  • Dropdown lists: validate any text entries to ensure they are acceptable values
• Potentially add a "test" button in the future (not initial implementation); have to think about how this will relate to the Preview function; also would need sample data to test against, but appropriate data would vary from file to file.

From filipjakobsen
Stripes Force work
Components and props we need @zburke, @j.coburn and @Rasmus Wølk to create:

• Toggle button with medium and small size prop values
• Key-value pair with Toggle button
• Input/Select with Toggle button
• Repeatable field area with Toggle button
• Checkbox null state
• Checkbox with Toggle button

Development sequence for the details screens: (create/edit/view)

1. Item record
2. MARC Bib (covers SRS and MARCcat; may just start with SRS if MARCcat not ready)
3. Instance
4. Order + Order line (2 screens, need to be mappable as 1)
5. Inventory holdings
6. MARC holdings
7. Invoice + Invoice line (2 screens, need to be mappable as 1)
8. MARC Authorities

Factors to consider:

1. Field mapping will include
   • Data from incoming records
   • Constant/default data supplied by the user in the field mapping profile
   • System supplied data (e.g. creation date, update date)
2. When creating/editing a record, a user fills data into the various fields, selects from dropdown lists, or marks checkboxes. For the mapping screen, instead of filling in data, the user will fill in a mapping (or possible a cascade of mappings) based on the incoming record type. Instead of a mapping, they may also fill in a constant data value.
3. It may be useful to make sure we follow a similar pattern for each type of field across all records (e.g. checkboxes vs free text vs dropdown list vs date picker, etc)
4. Some of the record schema are still evolving. How do we ensure that our create/edit screen stays synchronized with the current version of the other app's create/edit screen?
5. Field mapping profiles work in coordination with action profiles, in response to a definite match (matching to only 1 record) or non-match. We have not yet sorted out the behavior when there are multiple matches. It's very important to understand how each action affects existing FOLIO records:
   • Create: record does not yet exist and is being created for the first time
   • Combine: updates an existing FOLIO record; replaces some fields in the record, but retains some fields from the existing record, so the resulting record is a combination. I think it's likely that Combine will be used more often than Overlay
   • Overlay: updates an existing FOLIO record; replaces all fields in the record except HRID/UUID (probably will have to include a way to protect a few other fields as well)
   • Modify: updates an existing FOLIO record; only applies to MARC records in SRS and MARCcat - edits that will be made to the record by FOLIO before the final version is stored in SRS/MARCcat at the end of the import process
   • Delete: removes the record from FOLIO (or possibly marks it for removal). Details of this still need to be sorted out. There are lots of implications, especially when there are linked records (such as Inventory instances that have related holdings, items, orders)
6. Currently when a MARC file is loaded, we automatically create the MARC record in SRS. In the future, the MARC record will only be created in SRS if there is a Create action for the MARC record in the job profile.
7. If an Inventory Instance does not have an underlying SRS MARC record, it may be linked to an SRS record at a later date via an import. Right now, that would be just an intrinsic part of an Overlay or Combine action, without an explicit Link action. Is that an issue?