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
