Ongoing status report regarding Bookings API rewrite

Conflict checking

I'm working on the conflict checking. At the moment its completely untested (and I mean untested, I haven't run it once). The new version might have a very negative impact on the performance of those checks (blown up from 90 to 270 lines) - but parent-resources are now recursive, child-resources are taken into consideration too and, at least for me, its easier to read.
I'm planning on adding some caching if the impact is too large - but this is at the end of my to do list (see Road-map above).

Changes

Bookings now throw a conflict if

1. the resource is unavailable and not the whole booking-time is covered with availabilities
2. the resource is available (default or with single availabilities) and any single unavailability is found in the timespan (Unavailabilities override availabilities)
3. Any conflicting booking is found

This is true for the resource, its parents and its childs. The reasoning behind this is that a parent of a resource is - effectively - a group of resources (e.g. a complete house is a parent of its rooms, a group of persons is parent of every single person, etc). It's not possible to book a parent if any of its childs are conflicting (e.g. its not possible to book the whole house if any of the rooms is taken). And it's not possible to book a child if the parent itself is taken (if the whole house is booked, there's no sense in booking a single room).

The changes where needed because I like the way parent/child resources are treated now more and because the existing conflict_check is simply wrong - e.g. it might ignore unavailabilities and its returns are not very well structured.

To Do

Test.. In addition I will need to add some hooks to the conflict checking. So far it e.g. wouldn't be possible to have resources "with multiple availabilities" (e.g. a single resource representing a couple of beamers) without having to define every single resource. I have no idea how to add hooks there, but I'll think about it.

Comments are, as usual, welcome.

Conflict checking continued

I've completely rewritten conflict checking again - including a major API change. Methods for reading lists of bookings have been added as well.
Should work now.

Cache free time-slots

To easy conflict-checking I added a table "bookings_free_cache" which holds a list of available time-slots for each resource. Today I wrote a method to recalculate this cache, methods for altering it (e.g. changes to adding or deleting a booking or a resource) will follow.
Public Bookings now provides a menu item to rebuild the cache

To Do

1. Rewrite resources, free cache and conflict checking such that *a resource can have a number of available resources* - alternatively add "grouped resources" (a list of resources editable as a single resource, but bookable as different resources)
   1. Parent-resources allow all necessary options, but a "mass add" would be nice. Later on ;)

Not right out of the box, no. It would be possible to e.g. let the employees add availabilities to the rooms - customers could then book those available rooms. Availabilities can have names, but additional fields (like e.g. the employee-name) would have to be added.

Viewing those availabilities would be relatively easy, adding the additional field would be easy with an additional module.

Hi 2primes,

Sorry for the delay - I've received your email and will respond tomorrow.

Roadmap

• Rewriting the AJAX-part to use the default (or some module-extended) Drupal AJAX libraries.
• Documentation
• Rewriting of Public Bookings to allow for some more advanced settings (e.g. default/maximal length of a booking, more advanced permission handling)
• Release of the first ALPHA version of 3.x. (should be this year). Bookings API should then be able to handle sets of resources and provide a unified AJAX-interface.
• Rewriting bookings/records (to nodes)
• Rewriting the bookings/records related hooks
• Second ALPHA
• Rewriting the module such that any content-type can be used (ATM its a special content-type. I will change this to allow more flexibility, but it's really not in the top-10 ;) )
• Rewriting the trigger/action submodule to allow more complex automatic responding to bookings or changes of resources (e.g. informing all customers of a changed resource about the change)
• Extended performance and scalability testing of the module and extended testing with various versions of PHP to increase stability
• Complete rewrite of the testing-subset (at the moment its totally unmaintained, there simply are no automated tests of this module)
• Rewrite / Extension of the documentation and setup of a demonstration page
• First Beta
• Beta-tests and fixes
• First stable
• Beginning work on a Drupal 7 release (this is planned for sometimes next year, but might happen in between if I need to switch to Drupal 7 myself)

Sometimes in between

• Calender-integration (bi-directional)
• Adding "Multiple Parents" to allow more complex relationships between resources. This will

Current Project: AJAX-integration

At the moment I am writing on an AJAX-integration. It will allow complete control over resources, bookings, etc via AJAX. In the future it will provide at least JSON and XML format (server->client) and traditional POST and XML (maybe JSON) (client->server).

Why? Because I can think of quite a lot of applications that would be inconvenient to use with normal HTTP (e.g. prefiltering available dates based on the selected resource) and because integration with other services or applications is much easier with XML-based communication then it is with traditional HTTP/HTML.

In short: Also I'm calling this step AJAX-integration, its more about providing additional ways for client<->server-communication and less about AJAXifying the Bookings forms ;)

Hi Daves,

3.x is coming along relatively well, but I have underestimated the amount of work needed for a cache of free resources :/ (which is why I haven't committed in the last month, I wrote and rewrote a couple of thousand lines of code and threw most of it away again..) This will delay the first ALPHA (somewhere in January I believe) and I'm really really sorry for it ..

The next dev-release is committed (DIRE WARNING: Free Cache is NOT working at the moment) and contains a new "feature" (adds a little link at the bottom of a resource-page to book this resource) and fixes some AJAX-functionality (conflict checking via AJAX should be working, resource-listing via AJAX is working) - but atm it continues as I said: It's not really usable at the moment .. Some documentation can be found at http://groups.drupal.org/node/34868 - though its admittedly not perfect and will be improved as I'm continuing my work on the API.
The free cache will allow you to make a list of available times (e.g. displaying "hour 3-4 on wednesday is available for ads" instead of letting the user test every possible time), the new conflict-checking-hooks allows for integration of additional conflict-settings - or a complete replacing of the existing ones (!), etc

Testing and/or code-reviews are always welcome - but you should be aware that this is really work in progress .. its only a developer-release and not (by any means) a user release. So: If you are a PHP-coder: Welcome! If not you're welcome too, but it's going to be a bit frustrating for you as some stuff simply wont work as expected.

The next step will be getting the free cache to work, then I'm back on the list published above.

regards - and merry christmas ;)

Tirsales

Hi Dave,

Thanks :)

And yes, the new release should be available tomorrow :) It's committed and should be available with the next roll-out.

regards,

Tirsales

Please regard that some changes will occur in Public Bookings ( http://drupal.org/project/publicbookings ). For example most of the AJAX-stuff is in Public Bookings (though some of it may be moved to Bookings API).

For developers: I'm trying to keep up with the PHPDoc-Documentation ( http://www.phpdoc.org/ ). You might want to extract it from the sources (e.g. using the AJAX methods is documented in publicbookings.ajax.inc ). If you run phpdoc with its standard settings it will not include the .module-files, you will have to add them manually. The following is my bookingsapi.ini for phpdoc (with [docdir] and [basedir] replaced of course, [basedir] is the parent-directory ob bookingsapi and publicbookings, [docdir] the output directory).

[Parse Data]
target = [docdir]
filename = [basedir]/bookingsapi/bookingsapi.module,[basedir]/bookingsapi/bookingsapi_free_cache/bookingsapi_free_cache.module,[basedir]/publicbookings/publicbookings.module
directory = [basedir]/bookingsapi,[basedir]/publicbookings


title = Bookings API
parseprivate = on
javadocdesc = off
defaultpackagename = BookingsAPI
defaultcategoryname = bookingsapi
undocumentedelements = on
ignore = templates_c/,*HTML/default/*,spec/,*DocBlock/*,*scripts/*,*AllTests*,*CVS*
output=HTML:Smarty:HandS
sourcecode = on

Apologies for not reporting back for so long and for the delay (its mainly due to unrelated work I had to do, apologies).

I've committed the state of work for now. Free Cache is still in non-working state - I need to implement a "date diff"-method. If anybody wants to help: Here is your chance ;)

What is needed? A method that takes two dates (INCLUDING rrule for repeats) and calculates the differences (not in length, but the exact list of differences). (See #682460: Calculate differences (diff, not length) between two date-repeats). With this method free_cache could be extended such that it can easily calculate whether a booking is conflicting or not..

Then I'll have to integrate the free_cache with Views - which is NOT trivial because it creates a *lot* of entries in its own table.. Example: A set of 50 marbles. Each marble has two availabilities (say morning round and evening round) .. That makes for 730 Availabilities per Year - per marble. Each availability makes for own entry in the database.

And this is also why I will NOT move free cache to a node-based format .. its simply not feasible.

Oh and what was done?
Quite a lot of ajax-integration stuff, a whole lot of bugfixes, "Publicbookings Free Cache" has been added, etc

Okay, I've just committed a couple of bug-fixes (e.g. conflict checking was horribly broken because I committed the wrong release when switch to a separate free cache). I apologies for this (the bug, not the fix).

In the near future I'm going to make some changes to the resource-contenttype. For example I realized that its not really sensible to use "status" as a variable defining whether a resource can be booked or not, as its totally possible for a resource to be presentable (e.g. customers might want to view pictures of the bag of marbles) but not bookable (you may book single marbles, but not the whole bag.). This is sad because looking at only one table (nodes) is easier then looking at multiple, but okay.

If anybody out there is relying on the API for his/her own module: Please tell me. Otherwise your module will be broken someday. (And yes, I'm telling as soon as its API-stable).

Oh and .. for a private testing projectI could demonstrate, that it IS possible to extend Bookings API quite easily with several additional features. What this means is simple: Once Bookings API 3.x is stable its flexible enough to fulfill all your booking desires (and yes, thanks to Drupals hook-concept this includes adopting Public Bookings forms to ones needs).

So, the free cache *could* be working now .. rebuilding it at least should be okay, conflict checking too. Adding/Removing/Changing bookings *should* be working but is fairly untested.

What is the cache doing?

It adds a database table providing a list of available times. And yes, the recursive dependencies between resources are taken into account, as are bookings. This should provide for a) a very fast conflict checking (simply check whether a free slot is available) and b) the possibility to provide a list of available time-slots.

For a variety of reasons (e.g. you can expect a couple of hundred k entries) the cache is only valid for a certain time-length AND it is NOT based on nodes. Integration with CCK and calender is on my todo-list.

Known restrictions

• Only new bookings (or at least bookings that have not been conflicting previously) can be checked using the cache. ATM it is more efficient to check booking-modifications using the normal "Bookings API conflict checking" then adopting the "Free Cache" - but as the conflict checking is integrated via hooks this shouldn't provide any problems.
• Rebuilding the cache is time-consuming, but shouldn't be a big problem (can be done via CRON and should only be needed once).

Life's not really fair - and I had to spend quite some time with other projects .. but the good news: I'm (partly) back and dived head first into testing .. A couple of issues have already been registered (don't bother looking, I'm going retro and have written them on a sheet of paper instead of filing them here) and will be fixed in the (hopefully near) future.

Just to let you know that I haven't forgotten about this :)

Help is always welcome :)

Well, seems like I made a couple of mistakes that eluded my (really not perfect) testing .. ATM I'm only searching for bugs and fixing them .. Apologies for that!

The resource is a normal node-type - you can add custom fields if you like (either using the administration tool or an additional module). The only restriction Bookings API has is that the resource type has its own name and a couple of required fields (change one line in the code and you can use another contenttype-name, changing the required fields would be more work) :)

I'd be interested to see your solution/code so far - perhaps we can merge :)

Yip, watching this with keen interest. The Checkfront module looks like the only alternative, but would be nice to do this 'inside' Drupal and with views integration. :)

"Availability calendar" is (in a way) possible with the free cache .. so far I didnt get to writing a views or calender integration, but it's definitely possible to show all available resources (proof-of-concept is residing on my desk, but so far not publishable).

My appologies for the long delays - but there's so much to do at the moment :/ It will get better :)

Not directly, but an integration with one of the existing shop/pricing-modules would be possible (and should provide more flexibility in the long run) :)

Good luck :)

I'd appreciate if we could work together to provide the best overall solution for every need :)

My contact form should be working – just drop me a mail and we can exchange contact information :)

Just a minor note to let you know that I am still alive - and that I am going to continue work on Bookings API and Public Bookings :) For a couple of private and business reasons I didn't have much time to spend on this in the last weeks - but this will change at the end of this month.

For the time being I've committed some bug-fixes - "bookingsapi_booking_save" is now returning a status-array instead of just a single value in order to allow for a more 'detailed' view on the result. In addition the bookingsapi_free_cache *should* be working now, though the testing-stage was quite short ;)

This depends what exactly you need. AFAIK Ubercart allows to e.g. restrict access to specific sites / permissions with regard to previous buying – this would be one option. And Bookings API provides quite a comprehensive set of hooks (e.g. while checking for booking conflicts or adding new bookings) that would allow to integrate additional "bought something"-checks.

I've added a minor new feature: The administrator can now enable "Resources are shown as hierarchical tree in the select-field" on the settings page. Resources will then be shown as a tree on the "place request"-page:

ParentResource 1
|- Child Resource 1
|-|-GrandChild Resource 1
|- Child Resource 2
Resource 2

If this is disabled, nothing changes (actually two variable_get and IF are added, but this should be okay ;) )

Sorry - but I am away from mid August till mid September .... I will reply to issues afterwards ..

At the moment I am doing quite a number of "minor corrections" ... e.g. I've fixed a number of bugs in the "Free Cache", re-integrated the date-fields of records in the argument list of views (so you can add e.g. 'start-time of the booking' as an argument to a view), etc

Am tossing up whether to learn and use Public bookings or Event bookings.

Can either work with a webform or do both need a custom content type?

What do you mean with "webform"? In theory Bookings API could work with any resource as long as it provides the needed fields and its name is in the code ;)

Would you need to use your own resource type? If yes: Why? Perhaps it would be sufficient to adopt the normal Bookings API resource type or change one or two lines of code.

As in webform.module.

The use case is booking one of two holiday flats.

I had a webform set up, as a means of contacting the site owner, where a user could select flat 1 or flat 2 along with the dates. I was thinking that I would have to figure out how to do all this with Rules, Date and Calendar, when I stumbled upon Booking API, Public bookings and the later Event bookings.

I have not used any of the booking modules before so I am trying to get my head around how to do what I need to, in the simplest way!!!

Well … the best way would be to start a new support request ;)

Use Bookings API and Public Bookings, then add one resource for each flat, allow "access to public pages" to anonymous client, on the Public Bookings Settings Page enable mails to the administrator and the module itself. A rules-integration should be working – so it would be able to e.g. add new "information methods".

Whenever a client reserves a flat (adds a booking) the administrator gets a mail and afterwards can finalize or cancel the request - the client will be informed accordingly. The system will check whether the flat is available (existing bookings at the same time) before it will allow new bookings. So in a nutshell it should do what you need :)

I've added 3.x ALPHA 1

Due to a couple of stupid mistakes on my side I totally screwed my own installation - loosing a couple of days worth of work.

I've fixed my installation and will continue working - sorry for the delays.

My appologies ... I simply forgot to update the status here.

* Most important: Bookings API has a new co-maintainer: developer-x. Thanks :)
* A couple of bug-fixes and new half-features (like e.g. a bit extended AJAX-integration). See http://drupal.org/node/256857/commits

At the moment I am working on some fixes to the "Bookings API Free Cache" submodule. It is far to inefficient as it is. I am rewriting it to incorporate a tree-based rebuilding of the cache.