Requirements - Evergreen Course Reserves

DRAFT

The following are draft requirements for an Evergreen course reserves system based on Syrup - http://git.evergreen-ils.org/?p=Syrup.git;a=summary. Syrup is an open-source course reserves system that integrates tightly with Evergreen. Syrup is built in Django, the data is stored in a Postgres database (recommended for production use), and also uses OpenSRF with the python bindings enabled to communicate with an Evergreen system.

Notes on this project from the 2015 Evergreen hack-a-way are available at http://wiki.evergreen-ils.org/doku.php?id=scratchpad:course_reserves.

These requirements are divided into two separate projects:

  1. A project to move course reserves functionality into Evergreen.
  2. An Evergreen feature where the system stores previous copy parameters and easily reverts them back to those parameters when the copy is restored to its natural state. This feature is not only useful for materials on course reserves, but can also be used for copies put on display, moved to a summer reading collection, or needed for some other temporary use. This feature was also submitted as a MassLNC idea at http://masslnc.org/node/2579

Feature: Evergreen Course Reserves

Staff Interfaces

A new Course Reserves menu should be added to the web client. The menu will contain the following options:

  • Courses
  • Course Sections
  • Departments
  • Terms

Terms

Terms are the specific period of times course sections are provided. This time period identifies when a section is active when users are searching for course materials.

The Terms interface should display a grid with non-deleted terms that have been added to the system.

  1. The context org unit should default to the workstation organizational unit. Organizational units dispalying in this dropdown menu should be restricted to those that the user has permission to view through the (ADMIN_RESERVES) permission.  The interface should display all terms owned by the selected org unit or by a child of the selected org unit.
  2. The interface should display the owning library, term code, name, start date, and end date.
  3. The default sort for this list should be by start date in descending order, but the user should be able to re-sort the list by any column by clicking on the column header. 
  4. The grid should follow conventions used in other web client grids:
    1. The grid should default to displaying a maximum of 25 rows on the screen.
    2. Users should have the option to change the row count to 5, 10, 25, 50, or 100 rows.
    3. Paging should also be available from the grid. 
  5. Double-clicking a grid row should retrieve the Edit a Term interface. A link to edit the term should also be available on each row.
  6. Each grid row should have a select box, and an Actions menu should be available to Delete terms.
    1. Selecting the action to delete should set the delete flag for the term to True. The term should remain in the database for statistical purposes.
  7. An Add a Term button should display in the interface. 


     
  8. The Add Term / Edit Term interface allows users to identify the owning library, code, name, start date, and end date for a term.

    1. The Owning Library in the Add Term interface should default to the Workstation Org Unit.
    2. When adding a term, this header for this interface should be "Add Term." When editing an existing term, the header should be "Edit Term."
  9. After clicking Save, the user should return to the Term interface and should be able to see the newly-added Term.

Departments

Departments are the main departmental areas under which a college's/university's courses fall.

The Departments interface should display a grid with non-deleted departments that belong to the org unit.

  1. The context org unit should default to the workstation organizational unit. Organizational units dispalying in this dropdown menu should be restricted to those that the user has permission to view through the (ADMIN_RESERVES) permission.  The interface should display all departments owned by the selected org unit or by a child of the selected org unit.
  2. The interface should display the Owning org unit, the department name, and contact name. Using the column picker,  phone number and email address in this grid.
  3. The default sort for this list should be by Department name.
  4. The grid should follow conventions used in other web client grids:
    1. The grid should default to displaying a maximum of 25 rows on the screen.
    2. Users should have the option to change the row count to 5, 10, 25, 50, or 100 rows.
    3. Paging should also be available from the grid. 
  5. Double-clicking a grid row should retrieve the Edit a Deparment interface. A link to edit the department should also be available on each row.
  6. Each grid row should have a select box, and an Actions menu should be available to delete a department.
    1. Selecting the action to delete should set the delete flag for the department to True. The department should remain in the database for statistical purposes.
  7. An Add a Department button should display in the interface. 


     
  8. The Add Department / Edit Department interface allows users to identify the owning library, name, and contact information for a department. 

    1. The Owning Library in the Add Department interface should default to the Workstation Org Unit.
    2. When adding a department, this header for this interface should be "Add Department." When editing an existing term, the header should be "Edit Department."
  9. After clicking "Save" the user should return to the Departments interface and should be able to see their newly-added Department.

Courses

A course is an academic class (e.g. English 101) offered to students. A course may have multiple sections, and each of those sections may have distinct course reserves lists. A course will be associated with a specific department in the college / university.

The Course interface should display a grid with non-deleted courses that belong to the org unit.

  1. The context org unit should default to the workstation organizational unit. Organizational units dispalying in this dropdown menu should be restricted to those that the user has permission to view through the (ADMIN_RESERVES) permission.  The interface should display all courses owned by the selected org unit or by a child of the selected org unit.
    1. NOTE: Courses will inherit its owning library from the Department table. 
  2. The interface should display the Course Code, the Course Name, the Department, and the Course notes. 
  3. The default sort for this list should be by Course Code, but the user should be able to re-sort the list by any column by clicking on the column header. 
  4. The grid should follow conventions used in other web client grids:
    1. The grid should default to displaying a maximum of 25 rows on the screen.
    2. Users should have the option to change the row count to 5, 10, 25, 50, or 100 rows.
    3. Paging should also be available from the grid. 
  5. Double-clicking a grid row should retrieve the Edit Course interface. 
  6. Each row should also display:
    1. a link to edit the course
    2. a link to add a section to the course
  7. Each grid row should expand to show all non-deleted sections attached to a particular course. (AngularJS ng-repeat appears to support expanding of grid rows).
    1. When expanded, the interface should display the course code, instructor name, and term. 
    2. The list of sections should be sorted by term in reverse chronological order.
    3. Links should be available to edit the section, delete the section, and to perform a term changeover on the section. More info on term changeovers is below.
  8. Each grid row should have a select box, and an Actions menu should be available to delete a course.
    1. Selecting the action to delete should set the delete flag for the department to True. The course should remain in the database for statistical purposes.
  9. An Add Course button should display in the interface. 


    Courses interface: The plus signs on the left can be used to expand a course to see its associated sections.


    The course interface with an expanded course.
     
  10. The Add Course/Edit Course Interface should allow users to add the course code, course name, department, course notes, and owning library. The department should be selected from a select menu displaying all of the active, non-deleted departments the user has permission to view from their registered workstation location.


    1. When adding a course, this header for this interface should be "Add Course." When editing an existing term, the header should be "Edit Course."
  11. After adding a course, the system should provide the user with the option to add a section for this course or to add a new course.

Course Sections

The course section (previously called course site in Syrup) is an individual class with a specific instructor(s) that occurs during a specific term. A section will be associated with a specific course. The reserves list of materials is associated with the course section.

  1. The Course Sections interface will list undeleted course sections and allow users to manage and perform batch actions on those sections.
  2. The context org unit should default to the workstation organizational unit. Organizational units displaying in this dropdown menu should be restricted to those that the user has permission to view through the (ADMIN_RESERVES) permission. The interface should display all course sections owned by the selected org unit or by a child of the selected org unit.
  3. Default display fields should include:
    • Owning library
    • Department
    • Course Code
    • Course Name
    • Instructor Name
    • Term
  4. Additional display fields should be available through the column picker, including:
    • Section code
    • Campus
    • Active flag
  5. Default sort should be by Course Code. The user should be able to re-sort the list by clicking column headers.
  6. The user should be able to filter this list by any of the display fields.
    1. A dropdown menu should be available to allow easy filtering by Term.
      1. This dropdown menu should default to the current term, as determined by the start and end dates for the term. 
      2. If the current date does not fall within a term, the dropdown menu should default to the most-recently finished term.
      3. The dropdown menu should only show non-deleted terms.
    2. Other fields should be filtered using conventions established in other web client admin screens. If no conventions have been established at the time of the project, the developer should work in consultation with MassLNC to identify the best method for filtering using standard tools available in AngularJS.
  7. The grid should follow conventions used in other web client grids:
    1. The grid should default to displaying a maximum of 25 rows on the screen.
    2. Users should have the option to change the row count to 5, 10, 25, 50, or 100 rows.
    3. Paging should also be available from the grid. 
  8. Double-clicking a grid row should retrieve the Edit Course Section interface. A link should also be available to edit the course section.
  9. An option should be available to view section details / add items to a course. 
  10. Each grid row should have a select box. An Actions menu should be available to delete a course section and to perform a term changeover on selected sections.
    1. Selecting the action to delete should set the delete flag for the course section to True. The course section should remain in the database for statistical purposes.
    2. Selecting the action to perform a term changeover should implement the behavior described in the Term Changeover section.
    3. An Add Section button should be available at the top of the screen. The Add  Section action will bring the user to the Add Course Section interface.
      1. Users can also reach this interface from the Course interface and from the Add Course confirmation page.
      2. The Add Course Section interface should allow users to add the owning library, add an instructor(s) from the actor.usr table, add the course, and add the term. Free-text fields for campus and section code are optional.
      3. If the user arrived at this interface from the Course interface or from the Add Course confirmation page, the Course menu should automatically populate with the course selected from the previous page.
      4. A Course Section may have more than one instructor. An "Add Another Instructor" option should be available to allow the user to identify more than one instructor for the section. If the option is clicked, a second instructor box should be added to the interface. An x should be available to remove any secondary instructor fields from the form.
      5. The user will identify the instructor by barcode number. After entering the barcode number, when the focus leaves the barcode box, the interface should display the user's first name and last name so that staff can verify they entered the correct barcode.
        1. A tab should be available to search for the instructor in case the user does not know the barcode. Clicking the tab will bring up the patron search form.  Note: This tab will be similar to the tab available when building an acq invoice that allows users to search for a lineitem to add to the invoice. 
        2. The organizational unit selector on the instructor search form, on first load, should default to the workstation library. 
        3. The selections made in the organizational unit dropdown and the Profile Group dropdown should be sticky. The next time the instructor search form loads, these fields should default to the most-recently-selected option.
        4. When patron results display below the form, the user should be able to select a user and click an option to add the user as in instructor to the section. If multiple instructor fields are open in the Section form (due to clicking the "Add Another Instructor" link), the instructor should be added to the bottom-most Instructor field on the form.
      6. For the Course and Term, the interface should use select menus that only display non-deleted courses and terms that the user has permission to view from the registered workstation. The Course should display in the following format: Course Code : Course Name.
      7. ​After adding a course section, the system should provide the user with the option to add items to the course section, to add another course section for the same course, or to add a new course section for another course. Selecting the 'add items to the course section' option should bring user to the Course Section Details interface. 

Course Section Mockups

Course Section List

 

Add Course Section form


 

​​Instructor Lookup

 

 

Edit Course Section

 

Course Section Details

The Course Section Details page is the central area where staff can add/remove items from a section, add public/private notes for the section, perform batch updates on items on reserve for the section and move those items to a copy bucket.

  • The top of the Course Section Details interface should display the Section Details that were added via the Add Course Section form. 
  • Staff should have the option to make the course section inactive or active from this interface. New course sections will start as inactive sections. Staff must make it inactive for the section to be visible to the public. 
  • Staff should have the ability to add notes to the section.
    •  Notes can be private or public. 
      • ​All notes should display in the Course Section Details interface.
      • The public notes should also appear in the public course reserves interface. 
    • A course section should have the ability to contain multiple notes.
  • The interface should provide an option to add items or links to external resources to the course section.. The options should include:
    • Adding items by barcode. When selected, the system should provide a barcode entry box where staff can scan barcodes for items being added to the course section added. After the barcode is scanned, the title, author, and barcode should be listed below the barcode entry box. The cursor focus should remain in the barcode entry box at all times.
    • Adding items from a copy bucket. When selected, the system should request the ID of a copy bucket. All items from that copy bucket should be added to the course section.
    • Adding links to external resources. When selected, the system should provide a form for staff to enter details about the external resource, including URL, title, author, publication title, and date of publication. These external resources will only display in the course section list. They will not be searchable in the public catalog.
  • Items will be displayed in an Items on Reserve grid of the Course section details page. The external resources will be displayed in an External Resources grid on the Course section details page.
  • The following actions should be available in the actions menu for the Items on Reserves grid
    • Remove selected items from the list.
    • Add selected items to a copy bucket.
    • Edit selected items. Choosing this option will launch the copy editor for the selected copies.
    • Create temporary parameters and restore permanent parameters (After implementation of the temporary copy parameters project)
  • The following actions should be available in the actions menu for the External Resources grid.
    • Remove selected items from list.
    • Edit selected items.

 

Mockups for Course Section Details

 

 

Term Changeover

  1. The term changeover feature will allow staff to copy a course section and all of its associated physical copies and electronic resources to a new term. The term changeover can happen from one of two places:
    1. From the Courses page: After expanding a course, the user has the option to perform a term changeover on a particular section.
    2. From the Course Sections interface: This interface allows users to perform a term changeover on a batch of sections.
  2. Selecting the term changeover option will generate a dialog that:
    1. Lists the sections that were just selected (Course Code : Course Name, Instructor name, current term)
    2. Provide two dropdown allowing staff to identify the term that the section should be moved to:
    3. A checkbox option to delete the section from the previous term when the operation is complete:
      1. This checkbox should be sticky and remember its state the last time a Term Changeover operation was done.
  3. After clicking Continue the system should:
    1. Create the new course sections under the new term(s) that was selected;
    2. Automatically link the same physical items and electronic resources to those sections;
    3. When the checkbox is selected, change the delete flag to the prevous course sections and its mapped items to 'true.'
  4. The system should display a Confirmation screen verifying that the Term Changeover operation is complete. This screen should display the list of sections that was created (Course Code : Course Name, Instructor name, new term). A link should also be available to return to the Course Sections interface or to the Courses interface (depending on where the user started.)

Public Interfaces

Search Course Reserves

UPDATED MOCKUP NEEDED TO REPLACE LIBRARY LINKS WITH A LIBRARY SELECT MENU

  • A new config.tt2 variable should be available to set the default reserves location if the Evergreen site wants it to be different from the default search location.
    • This will be needed for libraries that typically set the default search location to the consortium, but want the course reserves list to default to a specific library.

Course Search Results

  • Edit Course Section Only Displays when displaying for staff.
  • Sorting not only changes list sort, but changes the heading to whatever the sort field is.

To Dos

  • Reporting Needs
  • Permissions
  • Reserves Fields to be added as column picker options and where to add them.

Course Reserves List

UPDATED MOCKUP REQUIRED TO REMOVE PLACE HOLD LINKS AND TO ADD COURSE INFORMATION

  • The course list is the same as the TPAC search results page, but will add a parameter that changes some display elements if it's retrieves as part of a reserves search:
    • Remove the search facets
    • Remove the Place Hold links
    • Display the specific parts information that are on reserve. We'll need a new CSS class for this information so that sites have flexibility in how they highlight this information.
  • The course information should display if it's available regardless of whether it is a reserves search.

Record Summary

  • Display of copy information for all TPAC searches adds course information if it's available. Multiple courses may display here.

Feature: The ability to create temporary copy parameters and to restore permanent parameters

This feature will allow users to create temporary copy parameters prior to moving the copy for some temporary use. When the copy is no longer needed for that temporary use, the system will also provide an option to easily revert the copy back to its previous parameters.

Definitions

Permanent parameters: Permanent parameters are ones that represent the copy when it is in its normal state. The permanent parameters are the ones that will be stored when a user selects the option to store parameters. They are also the parameters that will be re-applyed to the copy when the user chooses to restore permanent parameters.

Temporary parameters: Temporary parameters are ones that are used when the copy is moved elsewhere in the collection for a special purpose, such as  a special display or course reserves. During this time, the item is not only in a new location, but may also circulate for a different time period or possibly use a different call number. The temporary parameters are what get removed from the copy when the user chooses to restore permanent parameters.

  1. A new action menu item should be available on the Copy Buckets, Holdings View, and Item status screens to create temporary parameters
  2. Another action menu item should be available on the Copy Buckets, Holdings View, and Item Status screens to restore permanent parameters of selected copies.


    Actions menu in Copy Bucket interface


    Actions menu in Holdings view 


     
  3. When a user selects the option to create temporary parameters, the system should present them with a dialog to change the values for some parameters.
    1. The parameters available from this dialog should include:
      • Circ modifier
      • Shelving location
    2. The dialog should provide dropdown menus for circ modifier and shelving location that will allow the user to update the values. 
    3. The dialog should match the style of similar dialogs used in the web client. 

      UPDATED MOCKUP REQUIRED TO REMOVE VOLUME FIELDS

       
    4. Note: If the user is creating temporary parameters for just one copy, the dialog should say "to this copy".
    5. After a user selects/enters temporary parameters and clicks continue, the system should do the following for parameters where new values were entered/selected:
      • save the previous values in a new database table that is responsible for storing permanent parameters while the temporary parameters are in place. This database table should be in the asset schema. 
      • update the asset.copy tables with the new values.
    6. If the user does not select/enter values for some parameters in this dialog, the system should not make any changes to those parameters and should not store permanent values for those parameters.
    7. The system should only store one permanent value for a specific parameter on a specific copy at one time.

      If a user attempts to create temporary parameters for a copy that already has a permanent value for that parameter stored in the database, the system should generate an alert telling the user that this copy is already using temporary copy parameters. The alert should display the parameters that were previously stored and provide the user with the option to create the new temporary parameters with or without overwriting the previously-stored parameters.

      A new  permission should be created to allow overwriting previously-stored parameters.


       
    8. Any grid with column picker options to display circulation modifiers, copy locations, or call numbers should also provide an option to display permanent parameters.
       
  4. When a user selects the option to restore permanent parameters, the system should generate a dialog asking the user to confirm that they want to restore parameters previously set for the selected copies.
    1. Users should have the update copies permissions to be able to restore copy location and circ modifier parameters. 
    2. When a user confirms the action to restore parameters, the system should update any parameters that were previously stored for the copies.
    3. After the parameters are reverted, the system should remove the stored parameters for that copy from the database.
  5. At checkin, if a copy has stored permanent parameters and also has a current copy location for which the checkin alert field is set to True, the alert should provide an option to revert the parameters. 



    Copy location alert with the parameters text and restore option added. When alert appears, focus should land on OK/Continue button.

Syndicate content

Creative Commons license icon
This work is licensed under a Attribution Share Alike Creative Commons license