Optional admin approval

Thanks for the kind words :)
I'll upload a patch tomorrow.

While we are talking about the admin process for the requests, I did some more testing and made the following observations:

1. If I do elect to moderate or approve the requests, I see no reason why I need to receive copies of emails until AFTER the user has verified the booking. i.e until after he has received the email with the link and responded. I only need to know that there is a request in the queue to be approved.

Speaking of verifying the booking I noted a curious result. If an authorized user submits a request and then logs out and then clicks on the link in the confirmation email, he is taken back to the site with an "Access Denied" message page. That's fine. If the user logs in at that point, the booking is confirmed. What I noted was that it didn't matter what user name and password was used to log in as long as that person had permission to access the booking page, the confirmation worked. Just a curiosity. I don't see it causing any practical problem.
On the other hand without the tie-in to the profile of the logged in user, any authorized user can enter a booking for anyone they wish, even if that second person is not approved to use the resource. i.e. they have not been assigned a role of resource user. I think we need more granularity in the permissions, similar to that in simple_reservation.

When I went to approve a request, I noted that:
2. The "Created" date was all zeros. i.e. 0000-00-00 00:00
3. The phone number was misentered by me as "xxx-xxx-xxxx" and shown as "xxx-xxx-xx". I know the form says "10 digits" but not everyone (like me) will notice that. Is it possible to format check the entry.
4. When I clicked on the "check availability" button it said "processing" and just looped there without a result. This button worked fine on the original booking form.

I tried the update process:
5. The same problem with the Check Availability button happened when the user tried to update a request that had not been finalized and tried to check for a conflict.
6. When the user tried to do an update which caused a conflict with a prior booking, it was properly flagged when the "Update" button was used.

Hope this helps.

Maury

Hi,

You can define what emails your recieve by using Actions/Triggers - Bookings API provides a nice set of Events to react on :) If you need more (or more granularity) with those - feel free to ask for it.

ATM a booking is not tied to a user - if a confirmation page can only be viewed by a logged-in user, it does not matter WHO views this pages, as long as he is logged in. This will change as soon as (in the meaning of: as soon as and not earlier then) a version of Bookings API / Public Bookings is released that uses Nodes for both (resources and bookings). I'm working on it, but cannot state more then "its done, when its done" - sorry.

2) Created date - thats a bug and I'll look into it
3) Phone-number - thats a bug and I'll look into it.
4) The AJAX-part is not really working ATM. I'd love to leave it in this state until I finished the rewrite ... Is this okay?

Thanks for the bug reports and feedback :)

Please test the attached patch - it should add a new setting to the administration menu (advanced section):
"Whether confirmed bookings are set to finalized (approved) without an administrator rechecking them - NOT Recommended."

With this checked any new booking is set to finalized after the confirmation link has been visited. Client-changes to the booking will reset it to finalized (if it was finalized), instead of "pending".

I'll open new issues for the bugs you found.

Regarding the bugs (2,3,4) please see
#573612: Date of creation wrong
#573614: Phonenumber cut too shortly and without error-message
#419550: Checking availability of repeating bookings via AJAX defective with (at least) Date 2

It's easier to handle one problem per issue :)

Committed to ease patching

@tirsales

Let me start by saying that I am amazed at the speed of your response. Far better than I would have expected from any commercial organization. That's what I love about the open source community, especially Drupallers.

I will look at the actions/triggers module but I suspect the patch you supplied will suffice.

As I said I wasn't really concerned about the login curiosity, except that the confirmation was NOT complete until someone was logged in after clicking on the link in the email.

I'm much more concerned about the permission question since the user is not allowed to book use of the resource until he has completed the required training on its use and is then assigned the role of resource user. If he can then book the resource for someone who has not been trained, that defeats the whole purpose of the system. That's why I feel it is necessary to tie the logged in user to the reservation and expand the permissions settings. Also you could then automatically populate the identifier fields in the reservation form (name, email, etc).

regards,

Maury

@tirsales

Switched to the DEV versions of PublicBookings and BookingAPI in my local WAMP server for testing.

Noted added features including optional Admin approval of booking.

1. The WAMP server has NO email capability so it could not send the confirmation email.
2. I looked at the booking in Admin > Content > Public Bookings it shows as "Unconfirmed" as expected.
3. I went to Public Bookings > View Schedules as a user and it shows in the schedule table as a "Booking" which could confuse the user. How long will "unconfirmed" bookings remain on the View Schedules listing?
4. I tried to add a new booking which overlapped the time of the unconfirmed booking and it showed "No Conflicts" as expected.
This raises the question of what would happen if user A enters an booking but doesn't confirm it immediately and then user B enters a conflicting booking and confirms immediately. Does this then block user A? I won't be able to test that until I install the DEV version on my live site.

I have set my resource as available "every day" starting today from 10AM to 9PM. In the advanced settings I set it to be available every Monday, Tuesday, Wednesday, Thursday, Friday and Saturday. There is a separate booking schedule for Sundays.

I noted in the DEV version I am now REQUIRED to set an ending date and that in the View Schedules it now shows the listing for EVERY day from now to the ending date. This wasn't the case in the alpha4 version. But the View Schedules listing only shows the first week and, if you reverse the sorting order, the last week. There doesn't seem to be any way to see the dates in between. I tried editing the default view by adding the "More" link, but that did nothing. I was quite happy with the alpha4 display of a single schedule listing if it showed the beginning date and time and the ending date and time.

Finally, I thought I would have to submit a feature request to add the same granularity, basic and advanced, to the EXCEPTIONS schedule that you have in the regular resource schedule so that I could, e.g. have a recurring block of time on certain days when the resource was unavailable. But I realized that all I have to do is preschedule a recurring booking for those times and that would block out any other bookings.

regards,

Maury

Please start a new issue for each question - I really appreciate the feedback :), but separate issues make my life so much easier (e.g. the status-listing cannot be used (in a sensible way) with multiple problems in one issue, and the CVS-tracker links to the corresponding issue).

1) You can disable the need to send confirmation emails on the settings page
3) I'll look into this - normally only confirmed bookings should show up (and it will be configurable whether ANY bookings are displayed)
4) Existing bookings should not conflict with each other - this will be a moment for the administrator to decide ;)

The dev-Version has a number of bug-fixes, including some regarding the availability schemes - in ALPHA4 repeat-settings were not saved. I did not change the way those shedules are displayed, so this looks like a bug. I'll look into it.

Thanks, tirsales,

I'll make it a point to initiate separate issues for each point. I start testing and wind up with a whole list of ideas which somehow seem related so they go in together. And many of them are just observations which I don't necessarily consider issues.

I really appreciate your hard work.

Maury

Automatically closed -- issue fixed for 2 weeks with no activity.