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
