Page tree
Skip to end of metadata
Go to start of metadata

Date

Attendees

Holly Mistlebauer

Erin Nettifee

Elizabeth Chenette

Marie Widigson

Andy Horbal

Mark Arnold

Molly Driscoll

Anya Arnold

David Bottorff

Brooks Travis

Kimie Kester

Andrea Loigman

Martina Karlsson

Kelly Drake

Cornelia Awenius

Lisa Perchermeier

Kristin Olofsson

Erin Weller

Martina Karlsson

Laurence Mini

Darcy Branchini

Cheryl Malmborg

Joanne Leary

Mary E Yokubaitis

Thomas Paige

@Christine Tobias

Jana Freytag


Discussion Items

TimeItemWhoDescriptionGoals/Info
2minAdministrivia


20MinRe-setting an in-process request to “Open - not yet filled'

 UXPROD-897 (Re-setting an in-process request to “Open - not yet filled”).

Specifically, I’m wondering if we can remove the requirement to permission this action.

I’d also like to ask folks to re-rank if they are so inclined.


30MinTitle level requests

Gathering requirements and accessing interest for title level requesting
Timeline:  We would like to have requirements gathered by March 15, 2021

Comments can me made on the User Story Doc


WOLFCon20 discussion on title level requests find recordings/presentation by Magda Zacharska  here

8minClaimed returned fees/fines work delayedHolly MistlebauerSee details on spreadsheet at https://docs.google.com/spreadsheets/d/1XYOm_iewgHAW8AOxzjjUQGfWkS46_vW33ugPS-DFJSg/edit?usp=sharing

Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to supporting materials

Comments

e.g. loans, fees/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
  • Because...
  • Because...
e.g. mock-up, JIRA issue




























Notes

  

1. Re-setting an in-process request to open (UX-PROD 897)
Do we require an extra permission for this action or could the permission be split of from this ticket and done later?
until then the umbrella permission would be edit requests
nobody feels strongly about needing it - better to get this moving forward
related to the story UIREQ-577 (second set of scenarios)
everyone should consider re-ranking

2. Title level requests
currently requests are only working on the item level, moving requests between items has do be done manually
requirements for title level requests should be ready until March 15th
Chalmers is working on it, who else wants to be involved? Erin, Jana ...
might be worth to reach out to Spokane Public library or other public libraries
Chicago doesn't care about title level requesting
Duke doesn't have it, but wants it
Missouri State doesn't have a lot of multiple copies
Joanne: would be a nice option, maybe more useful for staff?
Marie from Chalmers: great demand by patrons, because they want to be treated fairly and get their copy when it's their turn in the queue

possible problems: what about if you need a specific copy (from a special collection)?
within several items in a holding, there might be different volumes or material types
keeping the item level request is important

what about configuration? will be specified later
Kelly: Koha has both, you could limit it to either one but don't need to
Marie: in EDS, it looks like requesting on title level, but the Folio logic doesn't follow through
Molly (in chat): Symphony had a choice at the hold level, where you set a default in that wizard's config. I believe Polaris did too. From a public perspective, the title level request was paramount. We also needed the way to do what Polaris called "group holds". So, say a patron wanted Harry Potter & the Sorcerer's Stone, but they don't care if it's large print, regular print, or audio. You'd place a title level hold on each format, then group these holds. When one format arrived to fulfill the hold, the holds on the other formats would be cancelled. In Symphony, there was a similar (though less elegant) function called Blanket Holds; in Evergreen, this was called a meta record hold. I don't think this is part of the initial scope, but from a public perspective, I could see this being a "piggyback" request. *enhancement/feature request*

Anya asks about discovery platform/API needs vs. ILS - would we need examples from different discovery systems?
Kelly: we gather user requirements right now independent from specific platforms
what are the patron information needs?

everyone who is interested should contact Kelly and/or make notes on the User stories doc
topic will be rescheduled for next Monday

3. Claimed returned fees work 
some features are at risk of not getting finished in time for the next release: 
- no overdue fines charged when item is found in the library (workaround: cancel overdue fines immediately)
- suspending lost item fees when aged to lost item is claimed returned and declared lost after this - patron should only get charged the declared lost fees, not aged to lost fees (workaround: cancel lost item fees before declaring claimed returned item lost)
second issue is more important to implementing libraries

- display fees as suspended: completed in fee/fine history and details, but not in user information (will display as open) or check out (suspended fee/fines will not be included in patron blocks)
- not allowing action on fees/fines for claimed returned items
second issue is more important

notices: claimed returned notices are not ready yet, but overdue and aged to lost notices will stop when item is claimed returned