2018-12-10 Resource Access Meeting Notes

2018-12-10 Resource Access Meeting Notes

Date

Dec 10, 2018

Attendees

  • @Andrea Loigman

  • @Emma Boettcher

  • @sthomas (Deactivated)

  • @Cheryl Malmborg

  • @Kai Sprenger

  • @Jana Freytag

  • @Joanne Leary

  • @Mark Canney

  • @David Bottorff

  • @Anya

  • @Deb Lamb

  • @Katharina Haas

  • @Kimie Kester

  • @Rameka Barnes

  • @Susan Kimball

  • @William Weare

     

Discussion tems

Time

Item

Who

Description

Goals

Time

Item

Who

Description

Goals

5min

Housekeeping

@Andrea Loigman

  • Notetaker - @Rameka Barnes

  • Meeting schedule

No RA meetings - 12/20 to 12/31

10min

Check in/check out notes (read)

@Emma Boettcher

 

Approve read-version of check in/check out notes

25min

Check in/check out notes (other interactions)

@Emma Boettcher

 

Decide priority of other interactions (print, delete, edit existing - others?) with check in/out notes from check in/check out app

5min

Clarification on Circulation Rules 'inheritance'

@sthomas (Deactivated)

 

Group understanding on limits to inherited properties in Circulation Rules modeling

Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to Supporting Materials

Comments

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to Supporting Materials

Comments

e.g. loans, fees/fines

Name

e.g. Q4 2018, Q1 2019

Clearly stated decision

  • Because...

  • Because...

e.g. mock-up, JIRA issue

 

Loans

@Emma Boettcher

Q1 2019 (read-version)

Include operator & date on checkin/checkout notes

Deleting notes at checkin/checkout is accessible through ellipsis menu, but not on the same screen as initial pop-up

  • operator and date is not so distracting that it couldn't be shown to everyone

  • Including delete options for notes right at checkin would be distracting, and can be hidden

 

Assumes that there is a tenant-level setting about whether operators should be tracked at all, and that if operators are not tracked, that information is not shown

Circulation Rules

@sthomas (Deactivated)

Q1 2019

Clarification on Circulation Rules 'inheritance'

 

 

Sean clarified that the Q1 version of the Circulation Rules Editor would support both the inheritance of a 'fall-back policy' if one were not specifically declared and would retain the inheritance structure currently present for nested attributes defined in the creation of a circulation rule.

Notes

Check in/check out notes (read/interactions) - Emma

Should the operator ID and date be displayed at check in?  Yes

Need note column to be larger to avoid text wrapping.  Emma will check to see if there is a character limit for the note field.

Discussed needing a tenant level setting for institutions not wanting to track operators. Need the setting to not display operators. Side note, for possible future discussion, if needed: Need to know any transactions that would need tracking if a tenant level setting is placed and how the institution would be able to retrieve the information, for ex. Financial info.

Discussed if we should be able to delete notes during the check-in process?  

Options to split the notes:

1. Check- in item to cancel and confirm

2. View check- in notes

Initial solution to delete from module or not have the ability to do it, have ability to use ellipsis

 

Circulation Rules - Sean

Sean- Talked about there being a fallback policy for each type that would be used if nothing else was specified - fallback inheritance will exist. Additionally, there was confusion in earlier meetings about whether the existing functionality to allow inheritance through nested properties would still be allowed in the Q1-2019 version.  Sean confirmed that this would be the case.  Earlier conceptual mock-ups included other 'inheritance types' that will not be developed as part of the Q1-2019  release - i.e., 1) the ability to define a common 'default' policy that could be inherited by a shorthand reference and 2) the ability to define, on the top line of a rule, a grouped set of policies that would be inherited by all nested properties beneath it.