John brought this up at our internal PCM meeting yesterday. I'm surprised it hasn't come up before.
There is an issue running MERCI as a staff run solution. Even though a staff member in a role with the Administer MERCI permission can change the author of a Reservation to be the user making the reservation, the validation functions for availability based on role and time are written to check based on the logged in user... not the the author.
MERCI wasn't designed to be a staff service solution.
Users with the Administer MERCI permission aren't limited by the checkout's hours of operation or dates the checkout is closed. We came up with 2 potential solutions, each with a downside...
1) Use Devel's User Switch feature The Devel module allows to switch between users. This solution would alter the workflow so that before making a Reservation the staff member would 'become' the user they are making the Reservation for. That way all of the validation that would normally be enforced on that user would still be enforced. The downside is we normally leave users blocked after an import so that the station controls the rollout. You can't switch to a blocked user. If the site is on a public IP, users could start requesting password changes and Drupal would email a a password reset link to their email. Basically, the station would lose control of the rollout unless an .htaccess password was added or access was controlled some other way.
2) Add a Userrefence to MERCI and rewrite validation functions I'm guessing this would take 4-6 hours to write and test. Unfortunately I don't have time to do that between now and the end of the ACM... and likely the end of July. This is something another developer could do, but would likely take longer than 6 hours for anyone who isn't already familiar with MERCI.
Anyone else have a suggestion for getting this resolved?
Comments
Could you have a staff hours checkbox?
Could you have a field, like a checkbox, that only staff would see when using MERCI but that was turned off by default? When staff made reservation for staff they would check that box off, but if they made it for members they would keep the box unchecked? The box would enable extended hours for equipment reservations. Is that any easier than your second solution - I don't know.
but you wouldn't be validating access.
in merci, a station's inventory would consist of several content type (these can be buckets or resources) and several nodes for each content type. in setting things up like this, drupal roles become equivalent to a station's certification, giving producers access to make reservations against certain buckets or resources. it's a clean approach for user based reservations but gets weird when you have staff generated reservations.
while a checkbox could easily enforce restrictions on what hours a reservation starts and end, it wouldn't address the more important validation need of 'do producer x have permission to reserve item y'.
pcm is using masquerade
daniel from pcm found this module and it seems to be doing the trick. in fact, there's one perk for using masquerade over devel user switch suggested above. when using the module, a menu item appears allowing users to switch back to their original user session. at the same time, you can set up the module in a way that doesn't allow non-admin users to 'masquerade' at all. so, an admin user can switch to a member user and back to the admin user easily but a member user has no ability to do the same.
merci is definitely designed to be user generated reservation system but masquerade seems to get us what we are looking for.
http://drupal.org/project/masquerade
Configuring the Masquerade Module
As there are no docs. Here is my experience thus far.
The setting at: http://sitename/admin/settings/masquerade Select the roles which only those with the permission of "masquerade as admin" can masquerade to.
Under permissions check the permission for "masquerade as user" for the role you want to allow to be able to switch users. Users with this permission can masquerade as anyone except if the user they are trying to switch to is in one of the roles you selected at http://sitename/admin/settings/masquerade.
For example at our center we have eight folks in the staff role. We also have a volunteer role (general unpaid nice folk jack who help us out). These roles include interns and others who we don't want in the Administrator role or management role. We'd like to allow them to help us by making reservations for others and editing and publishing all the site content. But we don't want them to be able to create or change views or some of the more archaic random maintenance of the site. So, under the masquerade settings we've checked the Administrator and Management roles and under permissions have set the "masquerade as admin" for those roles. Then for the Staff and Volunteer roles we checked only "masquerade as user". So members of Staff and Volunteer can switch to all users except us high falutin Management and Administrators and us high falutin Management and Administrators can switch to anyone.