[Feature req] Confirmation when booking reservation

[massey21]

When booking a tool reservation a confirmation pop-up would be helpful. This could be a user preference, in case some users prefer the no pop-up experience.

To (presumably) minimize additional code that needs to be written, one implementation might be... After dragging out a time slot, pop up the "reservation details" window that normally appears when you click an existing reservation. Add a "confirm" button to this window, beside the existing cancel button.

[rptmat57]

Can I ask what the reason behind this feature request is? Do people miss click and then have to cancel reservations?

[massey21]

Yes, that's essentially it. People mistakenly click (frequently) and have to either cancel or modify the reservation, which generates multiple calendar emails to deal with, and so on. This 'feature' wouldn't enable new capability, but would just be quality of life change to address a point of irritation that a couple of users have raised to me.

[rptmat57]

one thing you can do is to require a minimum of 30 min reservation for each tool. then a quick click would break the policy and show the dialog. not ideal, but it's something

[abuckles-uci]

This is a customization we've implemented at UC Irvine as well. Our users didn't want to accidentally create reservations.

It uses a JavaScript prompt so users can click "Ok" or "Cancel". We have some code for it, but may need to add a toggle in the settings to enable or disable this feature.

[rptmat57]

I think that would work well here. I am debating whether this should be a general setting or if this should be something each user can enable in their preferences, or both:

1. General setting, same for everyone
2. User preference setting, set for each user individually
3. General setting, and if enabled, then an override would be available in the user preferences to turn it off

3 is the most flexible but slightly more complicated to implement

What do you guys think?

[abuckles-uci]

I think 1 or 3 work best for us so that we can enable it for everyone by default. I agree 3 is probably the best since it's the most flexible.

[massey21]

I favor user preference settings since it's impossible to make everyone happy, so my vote would be for 2 or 3. 3 has the obvious benefit of flexibility, but given the extra implementation effort involved, I wouldn't be opposed to directing users to take the 30 seconds to set the toggle themselves if they have a strong opinion one way or the other. Effectively, crowdsource the effort of making a selection. Half the users are going to want to toggle their preference anyway, so I don't feel strongly about whether the setting is default on in code, default off in code, or default on/off based on a toggle I set.

[rptmat57]

looks like 3 is the way to go

[abuckles-uci]

Ok, I'll work on an implementation for this feature