I have a single resource which is available from 10am to 9pm Mon-Sat and 11am to 6pm on Sunday. I set up availabilities for these hours, repeating every week on the appropriate days and marked them 'strictly available'. If I set the 'default availability' for the resource to 'unavailable' the system shows 'no conflicts' when I try to book a time outside the hours I set. If I set the default to "strictly unavailable" the system show "conflicts" even when the time slot is within the hours I set. What's the proper way to do this so a user cannot book a slot outside the availability hours?

System:
PHP 5.2.5
Drupal 6.14
Bookings API 6.x-1.0-alpha5
Public Bookings 6.x-1.0-alpha5
Date API 6.x-2.4
CCK 6.x-2.5
Views 6.x-2.6

Comments

Anonymous’s picture

Anonymous (not verified) commented

Thanks for the bugreport.
Could you try to set your resources to "available" and add an unavailability for 0-10am and 9-12pm (Mon-Sat), 0-11am (Sunday), 6pm-12pm (Sunday)?

If this is not working I'd have to port the new availability settings back from 3.x - but I'd hesitate to do so, because it would delay work on 3.x

mauryg’s picture

mauryg commented

I had tried setting "unavailable" for the off-hours, but I had set them e.g. from 9PM to 10AM (next day) with a repeating schedule. Perhaps this was the problem. I'll try what you suggested and let you know.

Anonymous’s picture

Anonymous (not verified) commented

Thanks :)

mauryg’s picture

mauryg commented

@tirsales

OK, here are the results of my testing:

1. Set resource to "Available" and added "Unavailability" as you suggested with days split at midnight. Attempts to schedule worked OK. Had to set granularity to 1 minute to avoid "overlaps on scheduling. e.g. set unavailability from 0 to 9:59 am and 9:01 to 11:59 pm so user could schedule 10am to 9pm. Noted that "View Schedules" page showed unavailable times which I think is confusing to the user. Should show AVAILABLE times. Attempted to created new view for page but encountered error when trying to set filter to show Booking Resource = available or strictly available. Views complained "Error: handler for bookings_resources > default_availability doesn't exist!"

2. Tried reverse approach. Set resource to "Unavailable" then added availabilities. Attempts to schedule showed ALL times were available with no conflicts. Set resource to "Strictly Unavailable". ALL times were unavailable (showed conflict), including times I had set to "Strictly Available".

Now what???

Anonymous’s picture

Anonymous (not verified) commented

You could add a filter to the scheduler to list only bookings with type "booking" - this way "unavailabilities" are not shown. Or you could filter for bookings and availabilities.

I'm sorry, but with 1.x there is no easy way to list a set of available times - 3.x adds a "free times"-cache to the database and listing would be possible, but there is no such way in 1.x. You *could* add an additional availability for the available times (meaningless, but would be printed in the views, see above).

mauryg’s picture

mauryg commented

@trisales

First of all, thank you very much for all of your hard work on this module. I haven't found anything that even comes close. I am looking forward to version 3.x and would be willing to help you test it if needed.

I think I need to get my head deeper into using Views2 to solve some of my problems.

Suggestion for v3.x: The overview page which shows current and upcoming bookings is fine. IMHO the View Schedules should be a simplified listing of when the resource is or will be available. And if possible there needs to be a way to combine repeat availabilities like Mon-Sat 10AM to 9PM into a single block statement for simplicity rather than showing each day separately. Best of all would be a daily or weekly calendar display with time segmentation determined by resource granularity setting. Perhaps a jquery calendar for the user to select the day or week of interest which would then drill down to a calendar showing bookings and availabilities where clicking on an available time period would take them to the add bookings form. I realize it might not be that easy to accomplish, but I can dream, can't I?

BTW, in the availibilities settings there doesn't seem to be a way to add MULTIPLE exception dates. I suspect that's a problem with the DATE module.

Maury

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Postponed

Postponed for 3.x

Thanks for your feedback :) I don't know yet whether all of your wishes can be accomplished, but I can at least assure that most things would be possible using custom modules atop of Bookings API.

Regarding the multiple exceptions I agree - will have to look into DATE repeat to see whether this is possible..

emdalton’s picture

emdalton commented

I had the same problem, and the workaround of manually creating "unavailable" times for early mornings, evenings, weekends etc. does work, but it's quite counterintuitive, especially when one has the option to set a resource default as "available" or "unavailable." What does it mean to set a resource to default to "unavailable" if not that it isn't available unless you schedule availability for it? Will this be different in version 3?

From a usability point of view, I'd suggest that displaying available times on the request form would be helpful, with an option to select the relevant time period for viewing. It's a bit frustrating to users to be told to pick a time, and only then be told that the time they picked isn't available. If you have a lightly-used resource, that's fine, but for serious scheduling needs it would be very aggravating.

Anonymous’s picture

Anonymous (not verified) commented
Status: Postponed » Active

Bookings API 3.x will have exactly two "default availabilities" - Available and unavailable - and they will behave exactly as requested. An unavailable resource cannot be booked unless there is a separate availability defined, an available resource can be booked unless a separate unavailability is defined. (If both, a separate availability and an unavailability, is defined, the unavailability wins in any case).
In addition default availabilities will not be shared among parent/child resources, but separate availabilities will, and it will be possible to disable resources from booking w/o affecting either parent or child resources.

Displaying available times is not easy - it requires to check (recursively over parent/child-resources) for availabilities, unavailabilities and bookings and build a list of available times. 3.x will have a sub-module "free cache" which does exactly this (caching the results and altering them if needed) and thus allowing to display only "available times".
Sorry - but I cannot port this one back .. it would, essentially, require to port everything I have changed for 3.x back to 1.x - and that is not feasible. If you have few bookings / resources or a short list of times needed (e.g. only halve hours over four weeks), you might be able to build a list of available / free time-slots using custom PHP or a view (Define an array of timeslots, remove any timeslot for which you find a booking with type 2/3 or with type 1 and status 2 (finalized). Just select from {bookings_schedules}, that way you dont have to bother looking up the rrules/repeat-settings).

Regarding your problem:
Could you try setting the resource to "strictly unavailable" with 1.x? Maybe this works .. I could port the 3.x-conflict checking back to 1.x, but it would be quite a lot of work, and so I hesitate to do so, because it would only delay work on 3.x. And as 3.x fixes quite a number of long-standing issues and adds quite a couple of nice features (even if its me saying this) I'd rather work on this release ;)

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Postponed (maintainer needs more info)

Regarding your problem:
Could you try setting the resource to "strictly unavailable" with 1.x? Maybe this works ..

emdalton’s picture

emdalton commented

The unavailable/available thing isn't a huge priority for me at this point. The list of available times is more important. Please see my other issue.