2023-03-17 Acquisitions Meeting notes
Date
Attendees
Agenda
Housekeeping/announcement -
- U.S. daylight saving time started Sunday, March 12. Please check & adjust FOLIO meetings time on your calendar if applicable
- Orchid bugfest runs thru March 17, please participate if you can
- Next meeting - Tuesday, March 21, at 1 pm Eastern
- Martina Schildt's presentation re: "Claiming levels requirements analysis" postponed until Tuesday, March 28
- Appinteraction_crossapp group will meet on March 22 from noon - 1 pm Eastern to discuss printing in FOLIO. The group is collecting printing use cases and requirements here
- Seeking a volunteer to take notes for today's meeting
PC update (Kristin Martin) -
- From 2023-03-16 meeting:
- Revised FOLIO terminology being reviewed by councils, and will be added to wiki, docs if affirmatively approved.
- Next Tri-Council meeting is on 4/13 - will look at Evaluation Process for New FOLIO Functionality
- 2023-03-09: SIG updates
Business -
- Discuss Implementers Topics - starting with Topic #81 ( André Hohmann) and then #83 and continues
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
:01 | Housekeeping | Dung-Lan |
|
:05 | PC update | Kristin Martin |
Kristin described the FOLIO councils and let the group know about upcoming elections and that there will be a call soon for new members Dennis mentioned the idea of having a BugFest champion to increase engagement in BugFest.
|
:16 | Implementers Topics | Dennis | Starting with Topic #81 ( André Hohmann) and then #83 and continue André Hohman (Dresden): We want the ability to deprecate values in Settings that are no longer active across FOLIO. Martina Schildt mentioned that this functionality already exists in the Licenses app. For PO number Prefix, they use the year as a prefix and they want to deprecate prior years so colleagues won't accidentally apply those prior years. They don't want to delete these values since they are in use. Similarly, Acquisition Units. Owen Stephens 9:19 AM From Joe Reimers in chat: Is there still a need to be able to search on those? Disable for new, keep available for searching
Dennis: We don't allow deleting them to avoid data correction. It makes perfect sense that you might want to stop using a value. Owen: In licenses the deprecation is at the term level which is more like deprecating a field. If you were to create or edit a license after deprecation, the term will no longer appear in the drop-down list. If you've already assigned a term, it would be labeled as "DEPRECATED" in the UI. In Search it will also show it as deprecated, so you can search by and view the values, but they are clearly indicated as deprecated. Owen asked whether the prefix changes every year? Yes - André reported. For migrated data they don't want to show the prefix from prior years. Dennis asked why they apply the year as a prefix. André thinks Sven from Leipzig might know. The accession numbers are also structured this way. Sven thinks it's to get a grip of when the order was placed - it's a very usual thing for them to use the year as a prefix for data values. Dung-Lan reports that Skidmore also uses a prefix controlled vocabulary. Dennis asked whether a user would ever use a prior year's value. At any given time, the only non-deprecated value is the current year. André confirmed that this is the case. Dennis explained that identifying a default value would make sense so the user doesn't have to choose a value from the list. André will take that suggestion to colleagues at Leipzig. Owen Stephens 9:33 AM Dennis asked whether having a default value would be helpful for others? In chat:
Owen Stephens 9:37 AM Dennis: If other institutions can share use cases when a default would be helpful, that would help this feature. Dennis will create a story after Andre as a chance to consult with Leipzig and get back to him Topic #83 John Banionis (Villanova) Villanova implemented FOLIO at winter break, looking for a way to extract the list of transactions from FOLIO. They've created their own solution using LDLite and DBeaver to get what they need, but it seems like having this native in FOLIO would be useful for others. John shared his screen and suggested that providing more information on the transaction list at the top level would help. The user has to click into the transaction row to see full details. The description would be helpful to see, for example. Current view of transaction list: They exported the data and enhanced it to include the following columns
Dennis: Does this spreadsheet list this for all funds? How did you create this spreadsheet?
Dennis: What are the use cases for why you needed this?
Kimberly Smith - if something was fund coded to the wrong fund accidentally it would be very easy to find it if this were available.
Dennis: It's a performance problem to add a lot of this data into the results list. The order id and other info isn't stored in that module and requires a call to another module. This is a recurring problem and is why we have the third pane view so that we only make the call when you click on a result. We have a pattern for export, so if we can't show it in the result list we could provide an export to CSV that contains all the needed fields. They'll create a feature for this and folks can add their thoughts to it. And that is why then being able to get it out to look at and review/browse is that more important! Sara: Has a question about the description field - she doesn't know how to put data into that field?
|
Next meeting is on Tuesday, March 21 and an agenda will hopefully be posted prior to the meeting, if possible. |