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

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
5 minHousekeepingAndrea
  • Note-taker - Rameka Barnes
  • RA Forum reminder
5 minFOLIO meeting updateCate 
50 minRequest screens and introCate 

Notes

3 Comments

  1. The first 3 attached files represent one notice configuration screen.  The example is a recall overdue notice.

    The configuration allows for customized text in the notices body and a separate footer.  The notice subject line is the email subject line.  We think it is important to highlight the type of notice in the email subject rather than just in the body.

    The second file is the patron information.

    The third file is the item identifying information.  The first column contains the available fields for the notice.

    These will vary slightly depending on the type of notice. The second column contains the desired labels.  These are free text.

     

    The second 3 files are for a recall notice.  On this notice we have both the original due date and the NEW due date assigned because of the recall.

  2. Cate asked the following questions:

    Proxy section:

    (1) Request collapsing counters- What should it count? Inactive, Active or Both- Group decide it should only count Active only status

    (2) What is the purpose of the related transactions count in the sponsor section?  No one could remember. Sparked a discussion and group agreed as a priority that we would need a loan list screen.  Need the ability to see the list in the discovery layer. Andrea suggested an all open proxy transaction button.

    (3) If a user has been manually set as expired should the proxy user relationship expire also? Group agreed that it should

    Loan Screen section:

    Discussed that the Title link (takes us to the instance) and Barcode link (takes us to the copies)

    Sorting columns:  Sorting item with multiple value can be complicated. Decided on Authors- sort on first author.

    Call numbers: Decided that it has to be able to normalize call numbers.  Voyager has call number and normalize only on multiple. Call numbers need to display and have behind the scenes button.  V1 need a normalize call number.  

    Creating a notification sub system: 

    Cate wanted to start with the recall process:

    Recalls should trigger a notification

    Andrea talk through the process of what happens when an item is recalled.

    Need to be able to configure email, text, and snail mail for recall notice notification.

    Screen shot requested by Cate from David or Cheryl of example of templates for notifications.  Cheryl has provided those examples in her notes above.

    Andrea stated that we need to get to the other set of loan rules. Cate agreed that it would be addressed at next meeting.

     

  3. Thanks for the notes, Rameka!  Just one correction on #3 under proxy.  My takeaway was actually this:  If a proxy relationship is manually set to inactive and then _later_ expires, moving the expiration date into the future should make the relationship active again. There is no need for the system to remember that it had been manually switched to "inactive". We assume that, if you update the expiration date, you want the status to become active again without an additional step. Of course, if either party's user record is inactive, the proxy relationship needs to stay inactive.

     

    Similarly, if a user status is manually set to inactive and then _later_ expires, moving the expiration date into the future should make the relationship active again. There is no need for the system to remember that it had been manually switched to "inactive".  Manually changing user status is quite an edge case so we don't need to do anything complicated here.  The RA SIG's perspective aligned with that of the UM SIG's.