User Tools

Site Tools


Moving Syrup Course Reserves to Evergreen

Notes from November 2015 Developers Hack-A-Way

Notes on Database

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.

Syrup tables that can be added to course_reserves schema

All of these tables will have OU owner and delete 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. Many-to-one relationship so that two instructors can be assigned to course sites.
  • syrup_term

Syrup tables no longer needed because the data already exists in Evergreen

  • 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 tables supporting features that won't make phase 1

  • syrup_group
  • syrup_membership

Syrup tables no longer needed

  • 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

Storing and Reverting Parameters

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.

Staff Interfaces

  • Staff interfaces will be largely the same as they are in current Syrup, but should follow the same guidelines as the ones used in the web client.
    • Web client UI style guide would be useful here.
  • May be no need to add service desks. Ask opinion of course reserves users.
  • Need to add a logical progression for the following tasks: Create Course –> Create Course Site –> Add materials to Course Site
    • Example: After creating course, add a link that provides the option to create a site (section) for that course or to create another course.
  • May not need granular permissions for viewing a course site. Maybe just make use options for public / private.
  • Add an option from course list to add all / selected copies to a copy bucket or to load copies from a copy bucket.

Public Interfaces

  • A new tab for course reserves search.
    • Search should be by course, department, professor. Toggle for searching active / all courses.
    • Also need a link to display all courses for that OU (how do we know what OU to display here if a parameter has not yet been set?)
  • Course site - search results page styled a bit differently (e.g. no facets).
    • We need to handle parted copies differently than we do on a typical search results page. A parted copy should show up as a distinct entity on the search results page. Example: A professor puts volume 2 and volume 3 of The Book of Evergreen on reserve. The course list should have a distinct entry for each volume and should only display copy details belonging to that part. Students don't need to worry about volume 1 because it is not on the reserves list.
  • Record summary page essentially the same as current page, but with active course information added to the copy details.
scratchpad/course_reserves.txt · Last modified: 2016/01/13 16:46 by klussier

© 2008-2017 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.