======Reserves Working Page======
//This page is for sketching out ideas for reserves implementation, much to be added here...//

===== Role based permissions =====

[[http://www.reservesdirect.org/|ReservesDirect]] offers a compelling model for reserves support for [[http://conifer.mcmaster.ca|Conifer]]. Almost everything is tied to a user's profile, and a typical interaction involves logging in as the first step.

{{:scratchpad:reserves:elogin.jpg|opening screen}}

//do we want an option to list all openly accessible reserve items without requiring authentication?//

Different options are presented based on permissions levels. Ultimate permissions are given to the admin account.

{{:scratchpad:reserves:opening.jpg|options presented to an administrator}}

ReservesDirect has fairly extensive [[http://www.reservesdirect.org/wiki/index.php|documentation]] and this implementation mostly consists of mapping a few slightly different approaches in addition to using it as a model. Ideally, we could make good use of our campus directory system for feeding and/or prepopulating many of the options. For example, creating classes can be done completely within the system, and this would be necessary for many sites, but it would be beneficial to leverage other campus systems for this information.

{{:scratchpad:reserves:createclass.jpg|dealing with classes}}

The "role" based access levels are quite straightforward. The system includes a role for **Custodian** that allows service desk staff to assist patrons who have forgotten their passwords. The [[http://www.reservesdirect.org/demo/index.html|demo]] site allows access to the system using each of the roles.

{{:scratchpad:reserves:demo.jpg|list of roles available}}

The [[http://www.reservesdirect.org/wiki/index.php/Documentation:_Basic_concepts#Users_and_Permissions|Users and Permissions]] section describes each role in detail, and each of these seems well worth targeting. If we could associate **barcodes** and **campus ids** with the user table, it would be possible to avoid having to allow users the ability to create their own user ids. //ReservesDirect// uses additional fields (**ILS User ID** and **ILS User Name**) for referencing the ILS, but it might be worthwhile to avoid storing more than one ID for a user if possible. Additionally, instead of using a "Not trained" distinction for instructors, there might be scope for a mechanism to suspend access by an administrator.

===== Classes and items =====

The ability to join or leave classes on the fly is a very desirable feature, since campus systems can not always be trusted to have course changes immediately recorded. 

{{:scratchpad:reserves:classoptions.jpg|joining or leaving a class}}

If a physical item is added to the system, a link is made back to the ILS for fuller description. There are also options for creating item records on the fly. Evergreen has a rich permissions system and it would make sense to tap into it for updates within the ILS. Some courses can have a very large number of materials on reserve and it would be beneficial to have several "sort" options if possible (sorting is available within lists). Another useful feature would be an indication of how many times the item has been selected by the user.

{{:scratchpad:reserves:items.jpg|course listing of items}}

===== Reusable lists =====

The ability to deactivate, reactivate, and activate/deactivate by date is highly desirable. There is much functionality hidden in the [[http://www.reservesdirect.org/wiki/index.php/Documentation:_Managing_reserves_lists#Working_with_headings|Headings]] support and instructors would benefit from the ability to define categories for reserves materials, e.g. //Week 1//. 

{{:scratchpad:reserves:heading.jpg|headings screen}}

The system could also be a starting point for building lists of materials, especially if there were strong export options.

{{:scratchpad:reserves:export.jpg|export options}}

//OpenSRF makes for a strong embedded search widget, it would be nice to have a pluggable architecture for this//

===== Timers and load periods =====

When a physical item is checked out, there will be a pass-through to Evergreen. It would be beyond the scope of the reserves system to assess fines but it would be useful if it could provide a notification function and mediate access based on current statuses. For example, a patron with a 2 hour loan item should not be able to request another item beyond the point when the first one is due. Python has some [[http://www.python.org/doc/2.5.2/lib/module-sched.html|scheduler]] support and there has been some work on a [[http://code.google.com/p/django-scheduler/wiki/GettingStarted|scheduler specific to django]], but it is probably best to keep a running list of time sensitive events and consult the list as needed. This might include:

  * when an item is requested
  * when an administrator wants the status of some or all items
  * when the ILS is unavailable

One scenario might be to call out to Evergreen and return the date/time due value as part of the transaction.


===== Graham rocks! =====

Houston, we have some working code.

{{:scratchpad:reserves:screenshot.png|}}