2018-11-5 Resource Access Meeting Notes
Date
Nov 5, 2018
Attendees
@Anya
@Rameka Barnes
@Cate Boerema (Deactivated)
@Emma Boettcher
@David Bottorff
@Darcy Branchini
@Tania Hewes
@Jana Freytag
@Katharina Haas
@Kimie Kester
@Deb Lamb
@Joanne Leary
@Cheryl Malmborg
@Holly Mistlebauer
@Schwill, Carsten
@Kai Sprenger
@sthomas (Deactivated)
@William Weare
@Wendy Wilcox
Discussion tems
Time | Item | Who | Description | Goals |
|---|---|---|---|---|
5min | Housekeeping | @Emma Boettcher |
|
|
| Notices | @Darcy Branchini |
|
|
25min | Item States - states history | @Emma Boettcher |
| Determine scope of states history: Availability as well as Process? What information? How far back? |
Meeting Outcomes
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 |
| e.g. mock-up, JIRA issue |
|
Requests | @Cate Boerema (Deactivated) | Q4 2018 Q1 2019 | Agreed that, for Requests, it would be appropriate to show no request results by default (similar to Users) |
|
|
|
Notices |
|
|
|
|
|
|
Item states | @Emma Boettcher | Q1 2019 (or later) | When displaying states history, unify availability & process in one column |
|
|
|
Notes
Cate view requests
how to view requests, default behavior like users app where nothing is shown - yes this is okay
needs filter for paging for service point equal to the effective location
need for eventual in app report for paging and other workflows
Darcy notices
notices related to loans specifically
individual policies vs notice policy is tying in notice policies via circulation rules versus some of them in the loan policy
cheryl-ability to resuse notice policy in multiple loan policies, no loss anywhere
notice policy allows for chronological view and likely allows better swap out when recall notice policy is needed
conclusion is that notice policy is the way to go
template feedback how does the recurring option work
missing the start trigger for upon/before/after
then recurring
do you need the until
multiple untils, but would this be a logic implied policies, etc.
does anyone need/want recurring, perhaps but maybe not on regular intervals, could just add multiple upons
we don't want the until because it should know the events that would cause this to not happen
use of fields/tokens for things like "number of days", "amount of fine accrued at this time" will reduce the number of different notices (courtesy 1, 2, 3)
do we like the ability to set a recurring notice? as long as there is a starting event trigger YES
Emma item state history
less time sensitive
display of three item states
how would this concept work with displaying the state history of an item?
is state history of availability, date and time, service point, source
Is "what process was it in" a question
can show a second block for an item's process but this seems confusing because of multiple timelines
is there a way to unify this information?
Show in process (which process) in parenthesis, consensus is that this is okay
some updates and processes won't have a service point, but that's ok
there should never be a point where you can't see the history, display in reverse chronological order and if necessary truncate display by letting it scroll down off the page or display X rows at a time by dropdown menu
history of requests as well? requests and needed for? is this also needed? yes in some fashion
could you click on process or needed for status to get to history of process or history of requests
this would live on the item record
is the date of a process relevant, should it be treated as separate columns for availability and process and dates?
Emma will revisit and revise and will revisit