Page Comparison

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.

• 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