Cannot Add Booking
| Project: | Public Bookings |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | tirsales |
| Status: | closed |
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
#1
I to have the same problem.
#2
Try to add the supplied patch (please also see the patches in #317829: Error: when trying to confirm booking)
#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
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
I apologize - forgot to correct the status.
#6
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.
#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
Committed to both - Bookings API and Public Booking.
#10
Apologies for setting to "closed" instead of "fixed".
#11
Automatically closed -- issue fixed for 2 weeks with no activity.