Bookings API + implementation

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Project information

Project pages on drupal.org:

Current status: Blocked on Calendar views, but working on other things for now.

Description

Proposal on groups.drupal.org (currently not exactly the same as submitted proposal)
This project will create a bookings API to make it easier for developers to write modules that involve booking resources, such as rooms, projectors, or public computer terminals.

In addition, this project will also create a public room and resource booking system that uses this API. This booking system will allow unregistered users to submit booking requests, with immediate availability feedback. A booking admin would then be able to review and moderate requested bookings.

The scope of this project involves time-based bookings, suitable for the applications mentioned above. It's not immediately suitable for applications such as booking seats in a theatre, or reserving a seat at a lecture. It could be done, but not very efficiently.

Status updates

2008-08-05"

Done: AJAX-based availability checking is shaping up; a few style and informational touchups needed before committing. Views for both modules should be complete enough to make it useful.
Plan: Last minute dash to make the modules largely finished: still need to do emails and captcha, for instance. Calendar display of bookings and availabilities will be held off until Calendar supports non-node items.
Holdups: Views and Calendar.

2008-07-28

Done: Still working on Views stuff; but it's taking longer due to issues in real life.
Plan: Finish up Views in a day or two, and start on AJAX availability checking.
Holdups: Views and Calendar.

2008-07-22

Done: Not much. Added edit/delete links to Views like how nodes does it.
Plan: More Views integration. I'll be switching the hardcoded table pages to use Views in a day or so.
Holdups: Views and Calendar.

2008-07-15

Done: Minor fixes, and some very basic Views integration.
Plan: Calendar doesn't work with non-nodes at this time, which is a bummer. However, I'm working with KarenS to solve this.
Holdups: Views and Calendar. I'll work on other stuff in the meantime.

2008-07-08

Done: Alpha releases, although they're not working properly upon testing from a fresh install. Use the latest dev version.
Plan: To get the viewing of resource schedules working, using Calendar, if possible.
Holdups: Grasping Views + Calendar module, and how I could use it to display bookings and availabilities in these modules.

2008-07-01

Done: More bug reports and patches for Date API. Preliminary implementation of conflict detection. Basic custom form element for selecting resources. Now working on changes to the table schema which means a significant revision of some code.
Plan: Separating booking/availability records from instances of each, into a separate table.
Holdups: None.

2008-06-25

Oops, forgot about the report for this week until now.
Done: I submitted a bug report, then a patch for it, for Date Repeat API. My first bug report and first patch ever! Hopefully it wasn't misguided. I've also made my first commit for the Public Bookings module. I'm working on both modules concurrently.
Plan: After reading a book, I've decided against representing everything as nodes, so, everything is now self-sufficient in terms of accessing the tables and info. I'm not going to think about integration with CCK or anything like that until after everything is working, just to reduce the scope and give me less to think about. Now working on bookings and availability record CRUD and its tests, and how to present a menu of resources to book.
Holdups: I had to return Pro Drupal Development after having it loaned for 1 week, as someone else had a hold request on it.

2008-06-17

Exams are over; now resuming work.
Plan: I'm going to start developing the module that will be using this API, at the same time, even while the API is not complete. This is just so there's a better chance that I'd catch any hitches with using the API early on.
Holdups: Drupal books are scarce, outdated, or rare in all libraries and all cities near me. I got my hands on Pro Drupal Development 1ed this week, but it's due back next week because someone else has put a hold on it...

2008-06-10

Exam week; nothing to report.

2008-06-03

Done: I've just committed some of the stuff I've been doing on-and-off over the past week. I have an .install file with the database schema. One table holds both booking and resource availability records, because they share many common attributes, so I thought it'd make sense to fit them all into one table and have the API help differentiate between the two. I have the CRU functions for bookables (resources) done, while hook_delete() handles the D of all related rows. I wrote a SimpleTest for it, and it passes. I'm using the hooking function found at http://www.civicactions.com/blog/writing_extensible_drupal_modules_part_1 here.

Plan: I have 2 finals at the end of next week, so I don't plan to do much until those are over. Please look over my work and criticize, so I don't end up doing a lot of work along the same path and then discovering that there's some fundamental flaw or something.

Holdups: My exams and coursework. I'm also spending a lot of time thinking about how to make the API useful and flexible enough to reduce developers' need to write their own SQL to use the API's tables. It's mind-wracking.

2008-05-27

So far I have 3 types of nodes: booking, resource, and availability info. Bookings and availability records can obey iCal recurrence rules. Availability rules will be weighted, allowing for complex availability times and exceptions.

I'm currently in summer session at UBC, with final exams at the end of the second week of June, so I won't be as active as I'd like.

Comments

Great idea!

qbnflaco's picture

I have actually been looking for something to use for a theater ticket purchasing part of a website. Maybe integrating this with ubercart would be the way to go? I'm not much of a programmer but I'm willing to get my hands dirty. :-)

More support

jorditr's picture

Hi, I'm also interested on something related with booking for a courses reservation part of a site. In any case a booking system is something "complex" and having one for drupal would be simply wonderful, it can be used on so many different situations... The only thing I can't see from the above descriptions is if this one is going to be independent or related to an ecommerce suite. Now there are two for drupal, and I also bet for ubercart :-D

resource_conflict

dugh's picture

Yeah I'd also like this. There is a module called resource_conflict that works with the event module, but nothing for the new calendar/date modules.
I don't suppose a drupal 5.7 version is going to happen though.

Why non-nodes?

kopo88's picture

Calendar doesn't work with non-nodes at this time

Why take nodes out of the equation? Leverage CCK to set up a base "Resource" node type that has schedule fields (multiple Date ranges, both for booking and availability). Resources will then be bookable, and admins will be able to extend the fields of the Resource type as needed. This would probably greatly simplify working with Calendar and everything else in Drupal.

Efficiency

c.lam's picture

I realize that using nodes would simplify many tasks, and that it would especially make sense not to make resources as non-nodes. I might go back and make it a node in the future.

However, for bookings and (un)availability records, I don't think nodes are suitable. As I've built it right now, bookings and availabilities are stored in the same tables, with both types supporting iCal RRULEs. This gives a lot of flexibility with regards to irregular or complex availabilities, as availabilities and records are both treated similarly. Each occurrence/recurrence of a given record is stored in a small, separate table that contains occurrence's start and end time, such that looking for conflicts or activity within a given timeframe can be done easily with an SQL 'BETWEEN', without needing to look for applicable RRULEs and recalculating their recurrences each time. This table can easily reach thousands of rows, with none of the node hooks applicable to it.

I've been in touch with KarenS, and she says she'll be adding some hooks and whatnot to accommodate the display of non-nodes using Calendar. I'm working on Views integration to make the switch from tables (being used to present bookings and availabilities right now, crudely) to Calendars quick and easy (theoretically).

dugh's picture

Yeah I already made an initial resource scheduling solution in drupal 5 with views, cck, date, calendar (dev versions).

Create a content type called resource. This can describe a room, a piece of equipment, etc.
I created views to list all resources.

Then create a content type called reservation. Have a cck node reference field to reference a resource, and a date field to specify when the resource is being reserved. Plus I have other fields like 'submitted by', 'email', etc., since students who don't have drupal accounts will be submitting reservation requests. I also use mollom to protect the add reservation form from spammers.

I created a calendar view to show all reservations, with a filter drop down list to filter the calendar by resource (show only reservations for one room, for example).

Of course the tricky part is making sure you don't reserve a resource during a time when it is already reserved by someone else.
Right now I am exploring the actions and workflow_ng modules. You can have an email sent out to someone (an administrator) when a reservation request is made, for example. You can also run custom php code, which is where I am looking into running a custom sql query to check if the resource(s) requested are already reserved for those times.
I may have to add an extra field to the reservation content type that marks it as being in conflict with another reservation perhaps.

Here's a basic sql query that checks for a conflict, but it has to repeated for every resource requested (you can reserve multiple resources at once, like multiple pieces of equipment), and for repeated dates (like a class that meets twice a week in a room). Luckily repeated dates are not tricky, since the date module stores them as separate rows in the database. If the query has 1 or more rows in the result, it means there is a conflict.

select content_type_reservation.nid from content_type_reservation
left join content_field_reservationdatetime on
content_type_reservation.nid=content_field_reservationdatetime.nid
left join content_field_reservationresource on
content_type_reservation.nid=content_field_reservationresource.nid
where
content_field_reservationresource.field_reservationresource_nid = $resourceid
and (
($start>=content_field_reservationdatetime.field_reservationdatetime_value
and
$start<content_field_reservationdatetime.field_reservationdatetime_value2
)
or
($end>content_field_reservationdatetime.field_reservationdatetime_value
and
$end<=content_field_reservationdatetime.field_reservationdatetime_value2
)
or
($start<=content_field_reservationdatetime.field_reservationdatetime_value
and
$end>=content_field_reservationdatetime.field_reservationdatetime_value2
)
);

Feedback

bruse.jam's picture

thanks for sharing with us its really informative

Business Dissertations

Source code

fjmintes's picture

Where can I download the whole source code?
home essay

Use booking.com infrastructure

suffering drupal's picture

Hi guys/girls

"Be bold" it says at the beginning.
Whatabout simply using booking.com infrastructure?

I know it seems less of a challenge, but I can tell from experience it hardly makes no sense anymore to develop an own hotel-reservation system (other sectors maybe yes). Of course you get less commission, but you can expand much faster. And you have NO responsibility of anything at all. It's a hassle to deal with clients on two sides (the hotels and the guests) if something goes wrong. And charge a lot of small bills to many different customers instead of one big bill to one customer you know is gonna pay on time! And trying to convince a hotel to sign up for yet another reservation-center grows more and more difficult.

So I am looking for an easy to use (I'm still a newbie after almost 3 years) drupal implementation for the booking.com reservation system. Does anyone know of something that already exists or has any experience with it?
I can tell it's through XML.

Thanks and warm greetings from Seville, Spain.