I'm trying to figure out how to use this module.

I have a Content Type where users send in requests for meeting rooms. I am trying to find a way to have these submissions checked for availability before the node will be posted. Is the Booking API the right tool for the job and how do I go about implementing it?

Basically I have a Room CCK field and a Date/Time field and I need to be able to check availability of the room at that time.

Comments

Anonymous’s picture

Anonymous (not verified) commented

Appologies for the delay - I was away for two weeks and in contradiction to my plans had no internet-access available... I will get back to you tomorrow.

Anonymous’s picture

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

Actually Booking API would be able to do the job. Add a resource for each room, add a new content type and own submission of new entrys (or change) check whether the resource can be booked and (if possible) book it. If not - display a warning to the user and reject the booking.

But then - why not just use Public Bookings?

Anonymous’s picture

Anonymous (not verified) commented
Component: Bookings API Trigger » Code
Assigned: Unassigned »
Status: Postponed (maintainer needs more info) » Fixed

Setting to fixed. Feel free to reopen, if additional information is needed.

jgoodwill01’s picture

jgoodwill01 commented
Status: Fixed » Active

I'm sorry can you explain in a little more detail. I'm looking at the components included with the Booking API and Public Bookings.

Bookings API 6.x-1.0-alpha5 An API for managing the booking and scheduling of resources. Does nothing on its own.
Depends on: Date API (enabled), Date Repeat API (enabled)
Required by: Bookings API Rules (disabled), Bookings API Trigger (disabled), Public Bookings (disabled)

Bookings API Rules 6.x-1.0-alpha5 Adds Rules-integration for Bookings API.
Depends on: Bookings API (disabled), Rules (enabled), Date API (enabled), Date Repeat API (enabled)

Bookings API Trigger 6.x-1.0-alpha5 Adds several triggers for Bookings API.
Depends on: Bookings API (disabled), Trigger (enabled), Date API (enabled), Date Repeat API (enabled)

Public Bookings 6.x-1.0-alpha5 Allows public booking of rooms and resources, with administrator approval.
Depends on: Bookings API (disabled), Views (enabled), Date API (enabled), Date Repeat API (enabled)

Let me get this straight in my head.

I'll need to create a new content type ofr the rooms with a node for each room would this be the resource? I assume this will need a date field.

I'm not sure what you mean by "own submission of new entrys (or change)" do you mean set permissions for new entries?

How do I go about "check whether the resource can be booked"?

Are you referring to setting triggers and rules if so can you give an example?

I believe more documentation with these modules would really make them useful to a lot of people if you can give me a nice explanation of setting up a booking environment then maybe more people will understand how this works.

Thanks!

Anonymous’s picture

Anonymous (not verified) commented
Project: Bookings API » Public Bookings
Component: Code » Documentation

At the moment Bookings API (6.x-1.0) is using an own, custom resource-type. Using nodes is not possible at the moment (I am writing on a new version which will use a node-based resource-type (6.x-3.0) but so far it is NOT usable). Thus it's not needed to add a custom node-type.
In the future Bookings API will add its own node-type for resources. In an even farer future, I will allow using your own custom node-type - but let me first get the easy stuff set up ;)

Steps to use Public Bookings:

  1. Install Bookings API and Public Bookings
  2. Go to admin/content/publicbookings/settings and activate the Booking form. Perhaps you like to check some other settings too? You can e.g. set the granulation of bookings, whether a confirmation of email-addresses is needed or whether an administrator needs to finalize (check) each booking.
  3. Add Resources on admin/content/publicbookings/resource - there you can set whether a resource can be booked, if its available, etc
  4. Use it ;) - Public Bookings has a public interface (/publicbookings) and an administrative interface ( /admin/content/publicbookings/ ). Have a look at both of them (resources can be added in a sub-menu of the administrative interface)

When somebody tries to book a resource (/publicbookings) , availability is checked prior to allowing this bookings.

You wont need Trigger or Rules - unless you want to combine Bookings API with one of those (e.g. send a mail to the admin upon recieving a new booking).

Yes, I will need to add some documentation and I'll redesign the interface (e.g. menu structure) - but I hesitate to do so with the current version. It's lifetime is really running low and it would only delay work on the more advanced version..

jgoodwill01’s picture

jgoodwill01 commented

That you so much. That makes everything a lot more understandable. What advanced version are you working on?

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Fixed

You're welcome :-)

For users:
I'm working on a version of Bookings API and Public Bookings that uses Nodes to store its data. In a first step it will use a pre-defined node-type for resources (thus allowing easy integration with CCK, Views, custom permissions,..), a second step will save bookings as nodes (thus allowing e.g. easy integration with a calendar).

For developers:
I'm rewriting the hooks inside of Bookings API (thus allowing more advanced features for additional modules) and on an addition that will allow table/seat bookings (that is: advanced grouping of resources, handling of sets of resources and resources with special features like combinable size (2 three-person tables make for 1 six-person table), etc

In short:
I'm working on a near complete rewrite of Bookings API - and yes, I will provide an update path :-)

jgoodwill01’s picture

jgoodwill01 commented

Great to hear it. That sounds like a large task. Good luck.

Status: Fixed » Closed (fixed)

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