Project:Public Bookings
Version:6.x-1.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:tirsales
Status:closed (fixed)

Issue Summary

I'm using the Dev version of both BookingsAPI and Public Bookings.

I have defined only one resource, and when I try to Add a Booking and Check Availability for the first time, I get this message:

********************************************************
Conflicts found

The following conflicts with your requested booking:
Type Name Start End
Finalized

You must pick an alternate time slot that doesn't conflict with the above.
********************************************************

This seems to happen no matter what frequency/repeat settings I use.

Also, when I return to the Overview tab, I see this error:

* user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY start asc' at line 1 query: SELECT UNIX_TIMESTAMP(start) as startts, UNIX_TIMESTAMP(end) as endts FROM bookings_schedules WHERE resource_id=1 AND type IN (4,5) AND () ORDER BY start asc in /nfs/aesop02/hw21/d81/chid/test/modules/bookingsapi/bookingsapi.module on line 294.
* warning: Illegal offset type in /nfs/aesop02/hw21/d81/chid/test/modules/publicbookings/publicbookings.module on line 308.

Thanks

Comments

#1

I to have the same problem.

#2

Status:active» needs review

Try to add the supplied patch (please also see the patches in #317829: Error: when trying to confirm booking)

AttachmentSize
bookingsapi.confirm.patch 1.07 KB

#3

I added the two patches and tried to add a booking to a ressource. The second mentioned error still occures in case, that for ressource "Default availability" is set to "Strictly Unavailable":

* warning: Illegal offset type in /nfs/aesop02/hw21/d81/chid/test/modules/publicbookings/publicbookings.module on line 308.

I checked the relevant source code:
foreach ($conflicts as $record) {
...........
308:.....$row = "

{$status_name}{$typenames[$record_type]} {$record['name']} {$record['start']} {$record['end']}

";
..........
}

Furthermore I tracked the variable $conflicts as data input for a given formular setting:

Array
(
.....[0] => Array
..........(
............[0] => 2009-02-14 21:20:00
............[1] => 2009-02-15 21:20:00
..........)
)

result:
- both dates I added as start and end date into formular.
- the array looks the same, independent of any other frequency setting.
- the addressed keys in module public bookings (eg $record['name']) do not exist in the array.

So there seem to be some deeper problems, which might result from bookings api module, which generates $conflicts-array. After a first short look, the problem comes from the fact, that despite there are no normal "conflicts", an array is returned, which holds both dates. This comes from the fact, that the dates are not available for any booking and therefore are not deleted from $intervals-array in function publicbookings_conflict_check().

#4

Assigned to:Anonymous» tirsales

Did I understand it correctly, that you tried to add a booking to a ressource that is "strictly unavailable" (just want to understand the problem)? And you are trying to add a booking via the administrative menu, not as a normal "user booking"?

#5

Component:Miscellaneous» Code
Status:needs review» needs work

I apologize - forgot to correct the status.

#6

Status:needs work» needs review

Additional patch attached - it is a somehow dirty bugfix that should fix this problem, but will not really change the reason for it. Please be aware, that this patch does NOT incorporate any of the other patches in the issue queue. I promise to construct a complete patch as soon as someone tests the patches.

Explanation: If a resource is unavailable, it will not return a correct result-array (no name, no booking status, etc). This patch should fix the construction of the html-output, but will not fix the underlying problem. This is not meant as a solution or a permanent fix, just a temporary solution.

AttachmentSize
publicbookings.unavailable.patch 1.5 KB

#7

... yes, I tried to add a booking to a ressource that is "strictly unavailable"
... yes, I tries to add a booking via the administrative menu, not as a normal "user booking"

.....things you do by chance, if you want to explore a module quity quickly whithout the deeper study of any documentation ;-). But the problem did appear as well, if you book it as a normal "user booking" for a "strictly unavailable" ressource.

... I will try your patch ASAP...

#8

... patch works. The meantioned error message disappeared.

#9

Status:needs review» closed (fixed)

Committed to both - Bookings API and Public Booking.

#10

Status:closed (fixed)» fixed

Apologies for setting to "closed" instead of "fixed".

#11

Status:fixed» closed (fixed)

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

nobody click here