Reservation 'requests' for extended reservations that can be approved by admins

[adambray]

If you try to create a reservation that exceeds certain validations (length of reservation, number of items) it would be nice if you could put in a 'reservation request' for an admin to approve.

This reservation request would not impact availability of items for other people (i.e. the model availability count method shouldn't factor in these requests).

But once an admin approves the request, it should automatically notify the requestor and create the reservation(s).

[ncmaas]

Adam and I just discussed this, and we agreed that this should also be the default behavior for how somebody receives training for "required" equipment as well.

[dgoerger]

General strategy (updated! 2012.08.03-16h52 EDT):

• New table in database, modeled much after @ebmaher 's CartReservations, to store unapproved reservations done
• new columns needed in this table (relative to reservations table): approval_status (flagged, approved, denied), last_updated_by (who approved / denied it), email_sent (is this necessary for the table? we do need to send students emails), notes_for_email (so admins can send personalized notes to patrons in the approve / deny emails; alternatively, can we just use the regular reservation.notes field name [in this separate table, though] and copy the text over upon reservation creation?) done
• either store error messages in an array (the output of object.errors.full_messages, to the database), or fetch them later by calling object.valid? and NOT passing the 'skip these validations' parameters call Reservation.validates_set() as per below
• in the views add tabs on the reservations index (for all users, though separate by user type) for 'requests' and 'denied'; include counts as for all the other tabs (done for admins)
• define routes for requested_reservation_path, so that the tabs don't crash things
• define user.requested_reservations to work like user.reservations, so non-admins can have a tab view, too
• an 'approved' tab for admins on index (to review approved requests, and who approved them when), but do not allow editing / denial of the reservation from this view; that would just be cruel to grant a request and then say "jk you can't actually"
• for admins on the requests and denied tabs, add 'Review' button column to take to a page to review errors (why failed validations), edit reservation, and approve / deny request. Also we should include the model available count on this page, and a textbox for notes input (emailed to patron).
• the reservations show page should not be affected in any way, since these will not be real reservations until approved
• patrons should be able to cancel their own requests
• waiting on Admin overrides for reservations #220: skip any validations the admin can override: no_overdue_reservations?, not_renewable?, duration_allowed?, quantity_eq_model_allowed?, and quantity_cat_allowed? (Admin overrides for reservations #220)
• add to table if fail any of these ^^ validations
• for approval action, waiting on Admin overrides for reservations #220 admin-bypass of validation; currently it's just going to fail D-:
• refactor New Reservation view to accomodate and allow patron input of Reason For Request
• get emailing for approval / denial actions
• optimize workflow
• should all banned users' reservations be sent to this queue by default?

[ebmaher]

the ReservationValidations module doesn't require that classes than inherit from it run all the validations, so we can just pick and choose which ones we want this type of reservation (PendingReservation?) to run. This keeps us from having to skip validation or store errors -- we can just run the PendingReservation through Reservation.validates_set later to get full error messages.

• a PendingReservation inherits: start_date, due_date, reserver/reserver_id, equipment_model/equipment_model_id. done
• a PendingReservation needs (from what @dgoerger said above): approval_status, last_updated_by, notes done
• a PendingReservation also needs a way for the patron to specify why they are requesting the reservation. reason_for_request

[ebmaher]

There should be an option to create PendingReservations when you fail anything the admin can override (#220):

• no_overdue_reservations?
• not_renewable?
• duration_allowed?
• quantity_eq_model_allowed?
• quantity_cat_allowed?

This means that the validations that will be included for PendingReservations are:

• not_empty? done
• start_date_before_due_Date? done
• not_in_past? done
• available? don't do this

[ebmaher]

Going to call these "RequestedReservation"

[dgoerger]

This issue is currently waiting on #220, admin-overrides for certain validations.

@adambray question about workflow: Let's say Jane tries to make reservations for three items (simultaneously); one of them fails validations, but the other two are fine. How should error messages on the New Reservation page be handled, alongside the question of, more specifically: Should the form offer to create reservations for the ones it can, and requests for the ones for which valid requests can be made (invalid request being something an admin cannot override, I think)? Or if there is an error with one to create all of them as requests? (I favor the former, although it'll be a bit trickier I think in the controller; or perhaps not, if we pass it around as an appropriate hash, hmm)

Additionally: Should it offer to file requests for a user only if the failed validations are things which an admin can override? Or should it be in any case? I guess the case I'm thinking of here is (available?), if a 'priority patron' (however defined) wants to request something, and the admin is prepared to do a recall / subsequent PR handling. Probably not likely, but it occurred to me. Anyway, we could also make it an AppConfigs setting (admin override (available?)) -- with appropriate explanation of the use cases in the Hint -- but I'm not sure if this is something we actually would want to do.

[adambray]

In short, we should:

a) offer to create reservations for valid ones
b) offer to create requests for all other ones
c) let the admin deal with valid/invalid requests, by showing them as such

For c) for example, if there are two requests, one which is valid, and another which is invalid, we should indicate this somehow. The admin can approve/deny the valid request, and figure out, how to resolve the conflict for the invalid request (i.e. move or cancel reservations). Then, once the conflict has been resolved, the request would be 'valid' and eligible for approval.

An invalid request could be denied at any time (since there's not conflict in doing so).

[adambray]

Also, to clarify on the workflow for a & b, there should still only be one 'finalize reservation' button on that screen, which will simultaneously create all valid reservations, and requests for all invalid reservations.

If someone doesn't want to do that, they should have to edit the cart to remove whatever they don't want. This keeps the workflow simple and straightforward I feel.

[orenyk]

This is almost the "parent" issue to #297, quoting from my comment there:

Ultimately, we need to figure out a mechanism through which admins can grant exceptions when necessary without removing the user's ability to make new valid reservations for themselves.