Evergreen DokuWiki

Notes from November 2015 Developers Hack-A-Way

Since Syrup has already set up a viable database structure we can move many of these tables, with some minor adjustments, directly in to Evergreen. We suggest adding a new course_reserves schema into Evergreen.

All of these tables will have OU owner column added:

• syrup_course
• syrup_department
• syrup_servicedesk? - Need feedback from users about whether separate servicedesk is needed or if its purpose can be served through use of copy locations.
• syrup_site (consider renaming site): owner_id field maps will need to map to the actor.usr id for the instructor that leads the course.
• syrup_term

• auth_user - actor.usr
• syrup_item - incorporates bib, volume, and copy data in one table.
  • Will now map copy_id to a course reserves site.
  • This table also contained stored volume/copy parameters that were used for easy reverting. Will address this through distinct development project outside of course_reserves scheme (more details below).

• syrup_group
• syrup_membership

• auth_group
• auth_group_permissions
• auth_message
• auth_permission
• auth_user_groups
• auth_user_user_permissions
• django_admin_log
• django_content_type?
• django_session
• django_site
• syrup_userprofile
• syrup_config
• syrup_z3950target

This project should be distinct from a reserves project as it has multiple applications (e.g. Summer Reading materials, Display materials). However, this functionality should be a prerequisite to course reserves work since it was available in Syrup.

• From the copy bucket interface, add an option to "store parameters of selected items." The option will allow the system to store the following volume / copy parameters for later use.
  • Circ modifier
  • Copy location
  • Call number - work through issue of old empty call numbers.
  • Call number affixes
  • Classification type
  • Copy stat cats
• From the copy bucket interface, add an option to "revert stored parameters" that reverts the copy / volume information to the stored parameters.
• If somebody tries to store parameters for a copy that already has an entry, they should receive an alert informing them that the copy already had stored parameters. The alert should show what the current stored parameters are and should display what the newly-stored parameters will be if the action is continued.
• When reverting parameters, the system should remove the table entry with the stored parameters.