Skip to end of banner
Go to start of banner

2019-3-4 Resource Access Meeting Notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Date

Attendees

Discussion tems

TimeItemWhoDescriptionGoals
5minHousekeeping


  • Notetaker -

25minCirculation history Emma Boettcheroverlapping features, part 2Determine what information is needed at a glance regarding an item's circulation history
10minRequestsCate Boerema (Deactivated)Can inactive users make requests?Can inactive users make requests. If not, how should we prevent this?  
20minDeclared lost interaction w/ manual fines/feesIf an item is declared lost but does not have an associated fee/fine policy for automated fee creation, what is the desired behavior? (May only be needed by a few schools?)

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
Loans
Discuss with Rameka (TAMU) to make sure fees/fines will accommodate manual billing without affecting automated billing, and bring back to the group
Item stateEmma Boettcher

Display counts by shelving location to accommodate reserves

Most important piece of history is "Where is it?" - the rest can be a click away


Requests

  • Inactive users should not be able to request
  • Should display popup preventing this similar to what we do when an inactive user checks out
  • Should we include inactive users in the requester select popup? Yes because otherwise you may be confused why there aren't there.
  • Many on call actually thought they should be included by default in user lists (currently you need to check a box to see inactive users)
  • No override functionality is needed for this, as the best practice will be to go to the user record and set the user to active

Notes

  • Automated fees discussion
    • Staff can manually mark an item as lost (e.g., as self-reported by patron)
    • What happens if automated fees/fines are not set up to be applied when an item is declared lost
    • How many institutions do not use automated fees?
    • TAMU-mixture-automated lost item processing fee, and then manually apply replacement cost-tracked by a report
    • The question is whether there has to be a different workflow for manually marking something as lost or if it can simply invoke the same process as the automated process
    • if there is no automated fee fine, how do we know when the matter is settled and the loan can be closed?
    • Is the loan processing fee charged by TAMU sufficient for the proposed manual approach or is something more needed?
    • Emma will work with Holly and Rameka to arrive at a solution for TAMU and bring it back to the group
    • Holly will bring back the fee/fine policies discussion to the group as a reminder
  • What can one see in item circulation history
    • current item state and when the state changed
    • # CKOs, #IHU since acquistion
    • Dates for last loan, last IHU
    • Are these the only stats that are needed?
      • It needs to be able to distinguish between locations (was the item on reserve or not for the count of loans, IHU, etc.), likely no more then 3-4 locations over their lifetime
      • last date that it was loaned tied to count, last in house use date to that count
    • who/when/where when item was last touched - how extensive?
      • current and previous borrower
      • the most recent touch (who/when/where) and ability to quickly get to a more extensive history of all touches
      • difference between states, item state as opposed to processing state
      • ability to distinguish between item state update and a check-in that does not update the item state
      • okay to get to the broader history by clicking off the item record screen to another screen
    • should an inactive user be able to create a request?
      • consensus is no
      • pop up would tell you that the person is not allowed because requestor is inactive
      • this also needs to be released via API to the discovery layer for inactive users
      • Is there any need to be able to override this block and allow the inactive user to place the request? Or can we fix the inactive state and then do the request? We agree on the latter
      • Also we need the default view in all user lookups to be showing both inactive and active users, current default is active users only
  • No labels