Extend Reservations

[yalestc]

Extend Reservations

[mnquintana]

This is a great idea!

Would only admins have permissions to do this?

[dgoerger]

Don't we generally need LAL approval for this? Because admins can already edit reservation due dates (on rails3_stable at least). I suppose we could suppress the code in our implementation, if we want students to be able to self-extend in other implementations (BMT might want it? not sure).

@caseywatts please clarify intent.

[caseywatts]

The original request for this sounds like it came from a checkout_person, and I think they want this at the BMT desk. Let's accomplish that in this issue!

Self-extending checkout would be a related but separate feature, let's make that a separate, June II bug instead. #83 is for self-extension.

[mnquintana]

So would checkout people have authority to actually extend reservations? Or would they only be able to make a request for an extension that would then need to be approved by an admin? (If the latter, there would be basically no advantage for a BMT to "extend" a reservation over a user self-extending a reservation. If the former, BMTs could just extend everything if they wanted to. Not sure what the best route is here.)

[caseywatts]

I think we only want them to have an "extend" button if the student could alternatively check it in and back out - that's the only situation we want to deal with right now

[dgoerger]

so if the total number of not-checked-out reservations for that model =< the number of not-checked-out items of that model? would that be a good, fun test to run?

And we just want a button to, for instance, increment the due date by one?

[dgoerger]

talked with nick maas, test: if available_count(date) for the model > 0

[dgoerger]

My idea had been for a +1 Day button for reservations, but Casey pointed out libraries and things actually function on a model of doubling the reservation (i.e., renewing).

Stalling until we hear back from Erin (BMT) about what BMT's actually want, because they could be wanting some other functionality; it's not clear.

[dgoerger]

So we go for an intelligent button that has calculated the max number of days the equipment is available for (regarding is_available?), with an overall max_allowable_renew defined in the App Config. Students will be able to renew for the lesser of these max's.

Erin said:

---

Would it be possible to make it more friendly to the user-end, so that a patron doesn't have to come back to the Library for a renewal? We could, of course, create/change policy so that it can only be done in person, via email or over the phone, but I think that the added functionality of being to renew it yourself for a max of 3 days (less if only available for those times) would help with the customer service experience.

Ideal situation: Susie checks out a camera for three days; realizes that she'd like it for more. Heads to Reservations interface, clicks "renew!" button, gets it for three more days. Cannot renew until Day 3, so that other patrons have a chance to reserve for days 4, 5 and 6. Once "renew" is clicked, she is given an option to renew for 1, 2 or 3 days. If camera is not available concurrently, then she is offered less options. (Ex: Camera is available day 4 and 6 but not 5, she is only offered day 4 for a renewal.) If not able to renew at all, a message comes up that says something like "All equipment is reserved for the requested renewal. (Can the text be editable in App Settings?)

[dgoerger]

also need to make sure that Renew option only visible beginning the day before the equipment is due -- to prevent abuse.

it would also be nice if we could define a cap on the number of times one is allowed to renew

[dgoerger]

define max_renew_length and max_renew_times (the max_allowable_renew above) for the model and not in app config b/c some items more popular than others / it really should depend on the model and in any case should be easier to implement i think

[dgoerger]

it's fully functional on my branch david_renewals, as of commit cbbbeb. i still want to add the settings for the Categories, though, and implement inheritance to the equipment models if set to NIL in the model. After that we'll be ready for the merge woo! :-D

[dgoerger]

change button to post or put request as per #192