Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

Attendees

Andrea Loigman

William Weare

Joanne Leary

Anya Arnold

Beth Chenette

Darcy Branchini

David Bottorff

Deb Lamb

Emma Boettcher

Jana Freytag

Kai Sprenger

Katharina Haas

Kimie Kester

lisa perchermeier

mey

Rameka Barnes

sthomas (Deactivated)

Mark Canney

Cheryl Malmborg

Cate Boerema (Deactivated)

David Larsen

T Paige



Discussion Items

Permissions updateUpdate RA SIG on current situation for permissions and determine next steps for POs
https://docs.google.com/presentation/d/1hUWd6DTTIAwKOzcK2E3Ywx0vNKGnNimazgDOd3lGvtc/edit#slide=id.p1
TimeItemWhoDescriptionGoals
5minHousekeeping
30min



45minRequestsCate Boerema (Deactivated)30minRequest queue re-ordering and moving requestsCate Boerema (Deactivated) - Review revised request queue mock-upsMoving requests from one item to anotherMoving requests from one item to another:
- Do SIG members think this is a priority? We haven't discussed it yet (to my knowledge) but it seems important (it's needed by Chalmers to go live). A UXPROD feature has been created: https://folio-org.atlassian.net/browse/UXPROD-1653
- Review deck: https://drivedocs.google.com/presentation/drived/folders/1ADrLDD09Ub9AKL7Vu704viS8EVPSB8xv
-These are based on the original mockups created by Tania and Kimie with Requests sub-group. A couple changes were made:
-- Queue was "split" between recalls and holds because, per earlier meeting, recalls should be auto-prioritized over holds
-- Reordering capability was added (drag and drop)
-- Ability to move requests from one item to another:
--- This is not something we've discussed in this group (as far as I know)
--- But some use cases have been raised outside of this group that seem to warrant this such as: moving requests from an item that has gone missing and moving requests to a newly received copy.
--- Does the SIG think this is a valuable capability?
--- There will be some challenges, if we do this, as requests allowed on one item are not necessarily allowed on others per request policies and whitelist1E05xd9q8C8XJ6AReGr0WuiMneuZzEPkBmzLm0uL4R5o/edit#slide=id.p
- Collect feedback
10minNoticesDarcy BranchiniContinuation of discussion of tokens in notices

Determine the use of locations/effective location in notices–

Patron notices why do we need barcode token operator needs an unique identifier to help identify user (both barcodes and patron id are in user management record–looking at more fields in user management - University Id)

All contributors token- what happens if there is no primary contributor (author) --if there is no primary checked then get the first in sequence that will be primary; if no contributor then it would be entry–Questions for metadata management

Other questions: Check in receipts: do you need dates of when check in and back dated date; for fines just check in date

date and time always needed - best if for long terms loans drop the time; can we identify long term from short term, is it in the loan policy table? FOR now just have date and time

Number of renewals and cap – do patrons need the number of renewals on the notice, show how many renewals patron made? Last renewal date would be good to have on patron notice



Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Comments

e.g. loans, fees/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
RequestsQ2

Moving requests from one item to another:

  • Seen as valuable by German institutions (GBV, Leipzig) which purchase lots of copies of course books and allow them to be requested
  • Seen as a nice-to-have rather than a must have by US institutions, as they don't have this feature today.  Some might not use it (much) as:
    • They typically only have one item per instance (Chicago and Lehigh) unless you are talking about eBooks
    • They don't do this often today (Cornell) BUT they do have title level requests (Voyager) so that might be why.  Joanne didn't really have the details on how that was working.
    • They aren't sure they are ever in this situation (Cornell).  The things people would like to request the most are reserve items and we don't allow requests on reserve items.
    • This is rare enough that people just cancel requests and create new ones (Chicago, Cornell)
    • Andrea thought she would happily use this at Duke if it were available especially if it came with reports regarding where there are queue imbalances
    • People thought this would be useful for public libraries
  • People thought true title level requesting was really complicated and that moving requests would be a simpler thing to do to start
  • Reviewed: https://docs.google.com/presentation/d/1E05xd9q8C8XJ6AReGr0WuiMneuZzEPkBmzLm0uL4R5o/edit#slide=id.p
    • Selecting destination item:
      • To start, you would need the ability to move to another copy in the same instance (moving to an item in another instance can be handled later if needed)
      • Should display Instance name in the popup
      • Should change the status column to item status for clarity (this is the availability status)
      • Would want to see call number and enumeration as columns
      • For journals or multi-volume sets, there could be hundreds of items
    • Patron notices - generally you don't want these to be sent.  In the cases where you would want to send a notice, you'd just email the patron (would be nice if there was an email patron feature that would capture a record that the notice was sent)
    • When all requests on a Paged item are cancelled or moved, the item state should return to previous state (which can only be available now but eventually that could also be recently returned).  A popup should tell you what state it will be changed to as a heads up.  Would be nice efficiency to give the choice of changing to available or missing, but it's not a must-have since you can pretty easily just mark it missing from item record
    • When a page at the top of the queue for a paged item is cancelled or moved, the requests behind it do not need to be converted to page requests.  They can stay as holds or recalls or whatever as long as they show up on the pick list report.  People agreed that, what you want to have happen in this scenario, is that the item is picked up off the shelf and scanned into Check in so that fulfillment can begin on the next request in the queue.  

RequestsTBDAndrea put out a call for a Title Level Requests subgroup.  Siska from Chalmers will attend, Jana (GBV/VZG) thinks she has someone who might be able to participate.  Anya will also participate.  Others should contact Andrea if they want to join.