...
Convener and notes:Martina Schildt
Recording: https://recordings.openlibraryfoundation.org/folio/app-interaction-group-mondays/2024-06-03T12:00/
\uD83D\uDC65 Participants
...
...
Time | Topic | Notes |
---|
| 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 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
|
| 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 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 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; Vivian: flexible and rather supporting having less fields being mandatory 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 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 Martina: maybe focus n smaller feature that is doable instead of extending the requirement Kristin agrees, talk about rewuirements separately 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: 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. 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
|
✅ Action items
- Make material type optional: Ryan Taylor and Christine Schultz-Richert will contact Martina Schildt when topic and related ticket:
Jira Legacy |
---|
server | System Jira |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-2178 |
---|
|
are ready to be reviewed