Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/527543204. The meeting password can be found here.
...
| Announcements | The Folio wiki space has been changed over from Confluence to Atlassian. The base location changes are:
For the time being, old links are being auto-redirected to the new links (no idea how long this will last). If you are having issues with logging in, finding previously used pages, or missing functionality, please post in the #folio-atlassian-migration Slack channel. | |||||||||||||||||||||||||||||||||||||
| Discussion of the 3 part item state | Joint meeting with RA SIG. Will discuss the original plans for the 3 part item state and future possibilities. 3 parts: Item Status; Process; Needed For
TT: Trying to rework this for the current FOLIO environment. No bandwidth in developer time at the moment since this is so complex. In order to do customizable item states would mean changes across entire Folio ecosystem. Possibility of having these as separate elements on the item? DB: Came out of the desire to support workflows that other systems do. Flagging things for cataloging review for example (avoiding creating dummy patron accounts/workarounds). Also would support workflows (moving from different areas of technical services, for example). Other missing features that would help make items states useful is a customizable Workflow engine–to automate the processes within the item states. TT: Why are there three item states? What about having an item status and a process state instead? Incorporate checklist app instead of needing a workflow engine. You could reorder the processes instead of the "needed for." RW: Never understood the 3 parts either. Smaller institutions would not have the problem of figuring out where an item is in the process. We do need some kind of flag at time of check-in if it needs to go to cataloging for instance (Check-in notes are sometimes overlooked). Why are process and needed-for separated? The less requirements we have, maybe the faster we might get something. It would be easy to look up things that are flagged (instead of just having a check in note). TT: Larger institutions might have more complicated workflows with more people involved. SC: We have no way to say that status is never received or is claimed. We do create items for all of our periodicals and we don't want to have a gap in holdings but want to reflect if one has been claimed. Are we talking to the Serial group (newly created group). DB: That does raise a lot of interesting questions. We had to get the first part of item state out as a thin thread–it wasn't supposed to be hard coded in this way. You would need to be able to create customizable item states which we can't do now. worth exploring if Needed for is actually a separate item state or falls under process. TT: How to get them out of hard coded area into a customizable area? Are item states part of Inventory, circulation or its own separate app? It kind of makes sense that it is its own separate entity. JE: For larger institutions, our in-process there are many hands that are touching a record/item and it is not possible to know which unit it might be found. Not the in-process that is the issue but not having an audit trail is the problem. Likes the idea of needed-for–they are needed for digitization, repair, reserves, ILL rush, etc. And for these we create a bunch of dummy users and maybe instead we can leverage item state for this. DB: Originally envisioned to be customizable to see where in the process an item might be. JE: Five Colleges has items on all of their e-resources and they all say available that doesn't necessarily make sense as an item state. Not sure if this is an edge case. SC: Previous system had a state "library use only"–have been trying to figure out how to have this in Folio. DB: What shows to public is dependent on discovery layer. Customizable item states would help with this situation. [Discussion about how various institutions use current item states with discovery layer] TT: 3 part item states can probably be split and done separately. Extra data hanging off the item that don't effect requests or circulation rules. DB: Danger of that is you end up orphaning them from each other. You want the system to tell the staff person what they have to do with the item but you also want the item to change to the appropriate status. Could be done in parallel. Automated workflow is still desired – otherwise it is creating more work for everyone. Staff in Tech Services should not have to check an item in so that they can manually change an item from in-process to available. CM: Questions whether "needed for" would not affect circulation -- there are scenarios where it would. DB: If something is need for three different things, where would it go first? Institutions should be able to set their own priorities and do manual overrides. Part of needed-for is that it was intended to encompass both staff process needs as well as patron requests. TT: Was there a point where the requests app was going to be reflected in the process of needed for? DB: That was the original intent. To view and control the hierarchy of needs. TT: Going back to having states and processing (with needed for merged into those) – if there are multiple needs they would have to be re-ordered based on priorities (automatic re-ordering?). DB: If you had to pick between custom item states or process, which do you do first? TT: Sees adding the process first as the path of least resistance. It would be adding another element to the item. Changing to customized items states would require many different releases and would have to be across every single app. Would it make sense to add more filters to circulation rules - circulation rules dictate what can be done in the system. BT: Item status still governs as it exists now. The way that the current statuses effect circulation behavior, do they represent all of the possible behaviors in circulation? TT: So a way forward to customize item states would be to map custom states to existing circ rules. DB: Existing rules were a compromise within RA. Long term we need to tear out the hard coding and figure out where the logic should live. CM: Main objection-- you would just be pushing getting true customizable items statuses down the road again. A big hole in FOLIO compared to what other systems can do. DB: Need to let developers figure out the best way to do this based on our needs. TT: A lot more to be discussed. Will probably put out a call for a working group so people from RA and MM can come join if interested. JF: Proposes the idea of meeting again as a joint session between RA and MM. | |||||||||||||||||||||||||||||||||||||
| PC updates | Charlotte Whitt | 2024-02-08 Product Council Agenda and Meeting Notes Announcements: Asian-Pacific meeting - to be held on 2/21 (2/22) Evaluation Process for New FOLIO Functionality: The PC had a good discussion on the evaluation process for new functionality. The PC aims to offer a recommendation and works in concert with the TC and CC for new functionality. With that in mind, many felt that clarifying what is needed to present to the PC was necessary. You can see the Easy RetroBoard for more details. | ||||||||||||||||||||||||||||||||||||
| BELA (Bulk Edit and Lists App) | In last Tuesday's meeting, 2024-02-06 BELA Meeting Notes, the working group worked more on how to handle warnings and errors especially when no changes were made to a field and changes were made to a different field. | |||||||||||||||||||||||||||||||||||||
| Data Import Working Group | In last Wednesday's meeting, 2024-2-7 Data Import Subgroup meeting, the issue of MODDICONV-361 and 365 came up. 361 is a bug where action profiles are unlinked from job profiles post migration. 365 is a bug where action profiles are unlinked from job profiles during migration. Issue 361 is under review and 365 is being investigated. The hope is that CSP #1 for Poppy will address 361.
|
...