2024-06-03 Meeting notes: Material type: make optional or keep required

5 min

Announcements

@Martina Schildt

• Planning to join PO meeting - decide on date

  • June 19 (2 votes)

  • July 17 (2 votes)

Open

• https://folio-org.atlassian.net/wiki/spaces/AppInt/pages/183402590

15 min

Schema changes planned for Ramsons

@Ryan Taylor

Presentation of planned changes

40 min

Material type

Presentation of use case and discussion

@Kristin Martin

All

Use cases and arguments: https://folio-org.atlassian.net/wiki/x/AQAqD

Announcements

• June 19 is a public holiday in US

• we will need another option

• @Martina Schildt will check with Khalilah

Schema changes

• Main idea: add new fields for subject type and subject source in instance source

• UXPROD-4445: Subject Heading Granularity Updates - Instance schema changes (Folijet)

• new fields would live under subject headings

• Charlotte: better presentation for MARC authority data

  • maybe adjustments for Bibframe and Linked Data app are needed

• Folijet is assisting with linked data app > means both teams are in communication

• will be part of Ramsons - and is on a good way

• There seem to be paired values part of the new schema: if you have subjects, do libraries need to have subject type and subject source

  • they are scoped out to not be required

Material type

• not much is required in the item, but the material type is

• it is not used by all institutions, e.g. Chicago does not use material type

• it is required on the POL as soon as a user wants to create an item in Inventory

• Chicago had issues with data import and material types when migrating to Poppy CSP#4

  • part of migration needed to be rolled back

• the proposal of making material not required has been around for a while

• as we are making “breaking” changes with the schema changes

• Laura in chat: My ideal solution would be to allow us to determine, via settings, what is or is not required. Our staff are perpetually confused between the elements FOLIO requires vs the elements we have locally decided should be required.

• Thomas: no issues with making it optional > we may need adjustments to circ rules

  • chekc that circ rules cover material type

• Charlotte in chat: Is it possible to do an analysis of, how much this breaking change will require of changes of existing apps and modules. To get an idea of how big of a development task this is, if we decide to implement this solution

• Julie: you do not need to use material type in circ rules; it would be a breaking change

• Thomas: we are using material type quite heavily;

  • possible: enforce via UI

• Vivian: flexible and rather supporting having less fields being mandatory

  • materials types have to be standardized acrioss tenants

  • having option to make field required or not

• in general: being able to make all fields required or not in settings could cause problems

• larger requirement: define per institution which data element is required or not > there we would need technical input

  • would be a separate feature

  • Jenn: I think the two features would need to move together though so that people who need them required don’t lose that

  • Thomas and Julie agree

• Thomas: Maybe.. since the requirement could be UI only it would not be an issue for other apps.. If it goes down to API then it could be and at the DB level it defiantly would be an issue.

• Users app: patron type is required in UI, but not in the backend; when loading data via data import without specific data in such a field > the field will not be editable

  • it is only editable if there is a value

• Martina: maybe focus n smaller feature that is doable instead of extending the requirement

• Kristin agrees, talk about rewuirements separately

  • why did we give the field such a special status when it is not required for circ rules

• Thomas: Side thought. I wonder why the field was made required in the first place? Was it for circulation? If so having it not required may be moving down the path of having the apps less intertwined.  (random thought)

  • Julie: The loan type is also required. I wonder if it's because it is a criteria in the circ rule Editor.

  • Wouldn’t surprise me.

  • That is my thought.. In that case would loan type them become an optional field.. or could it be an optional field.

  • I believe it’s because we also need to support item records with no barcodes

• Charlotte: Having the Settings page, where an institution who use Open RS then can set item material type as required

• Owen: if a field is optional we need to be able to store it as an empty field

  • making field by API is different from making it optional in UI > where does rule live that field is required

  • going the other direction is harder than making something optional > when happens when switching between the 2 states

  • Charlotte: What Owen describe would be some strong arguments to include in the feature description

    • Thomas and Laura agree

• Thomas: At the API level it would have to be checked with business logic before it hits the DB. It’s not an unforeseen approach, but it does open the door for more error.

• Julie: have a default material type like we do with loan type

  • Kristin: that could help; but how would that impact data import; would be a lot of extra data

  • similar to what Julian suggested; just not hidden

  • Vivian: Julian’s suggestions is a very good way > default value to unspecified

• Laura: What's being developed for MARC validation might give us some ideas -- there are errors that can trigger warnings but not prevent saving a record.

  • Maura and Thomas agree

• Templates would be a good idea

• Laura: Inventory needs templates

• Charlotte: We have features for adding templates for instance, holdings, item

• there are no objections to making material fields optional

• caviat: we are taking away fuctionality that exists and would be harder to get back

• Dung-Lan: I'm in support of eventually making material type not a required in POL eventually once all ramifications involved are sorted out

• Ryan and Christine would be the POs who pick the task up

• will review existing ticket and update it based on discussions today

• share with dev side and hear their thoughts

• re-convene in App Interaction when Ryan and Christine have gathered information

• Laura: I don't think MM needs to re-review at this point