Hi All
EDIT: Will www.drupal.org/project/openresort not do already a lot from underneath functionality?
As the title suggests, please add your use cases to this page so that we can start formulating some ideas (it's a wiki page).
Oh, and feel free to add/edit anything already submitted to the page - I think we need to come up with as many scenarios as possible??
Here's some possibles:
Signing up to workshops
Example: A swim coach posts an event, a workshop and swimmers (customers) book a place in that workshop. Every swimmer has a profile with their background info that the coach uses to fit as much as possible to the customers needs. Event+ signup + ecommerce + developed signup_commerce module do a good job, but the last mentioned still needs some work. More details here: http://drupal.org/node/333232
Any suggestions much appreciated: http://groups.drupal.org/user/16902 Michael
Room Booking System
1 Room can have many bookings.
The dates of the bookings can't clash for the given room.
The room is probably only available at certain times of the day eg 9am - 5pm
The room may have a cost attached to it, although this could be either per room or per size of room (ie office space is charged per square foot/metre)
The room may have assets associated with it (ie projector, whiteboard, etc.)
Dorm Booking System
The hostel booking engines like Hostelworld have two types of "rooms" -- dorm beds and private rooms. You can create a dorm room with 6 beds and each bed can be booked separately by different guests. A private room can have any number of beds, but if the guest chooses to book a private room they have to pay for all the beds in the room. Contact me if you are going to add any hostel booking features and I can provide more information. If this isn't in the core program I may be able to pay for someone to add these features in the future.
Generalized asset booking system
The above could be generalized for any asset such as equipment, cars, or even secretarial services or staff availability.
(fronbow): to me this suggests the api should come with a clone-able(sp?) content type which can then be minimally extended, or even have profiles so you could (out of the box) have a basic setup for your needs?
shadowshifter: I don't think cloneable is a word :P Throwing in the plane ticket/seats idea as it's my current obsession, so would there also need to be a repeatability thing or would that come under the cloneability? In the case of booking flights say, they occur in certain dates at certain frequencies, and I'm not sure if this was covered in another section and I failed at understanding the expanaion :)
Timetabling system
This idea was suggested by Dominik Lukes to a colleague at Barcelona, so I'm not sure whether it would be for Lecturers/Teachers or for Teaching Rooms, or Lesson Plans.
This is Dominik: The idea of a school timetabling system is that it helps to calculate a timetable from given resources with certain parameters. So for instance, you have 20 teachers, 20 rooms, 20 classes and six hours a day. Help create a timetable. But I think most schools use specialized systems and the algorithms are quite complex so it may be too much for this project. There are even many open source projects: http://www.shambles.net/pages/staff/TTsoft. Open Course Timetabler has a nice PHP/MySQL interface for displaying the results (http://www.openctt.org/phpwebtt_example) so integrating that could be one idea.
David: The Openctt project is interesting, especially since the developer indicates that he is working on an automated timetabling feature. It wouldn't be perfect, but it would certainly save a lot of time. The nice thing about this project is that it can export to xml, which is easy to parse and include in Drupal. What's not so nice is the current GUI (it just needs to look prettier and be more obvious what to do), a need for documentation, and a clear API so that other developers can help him out (it seems to be a mostly 1 man show).
What would be interesting is if we could somehow split up the processing job of creating a schedule so that it could be run in parallel on many different computers. Then we would create a network of computers that people could access when it comes time to creating their schedule (and of course they would be required to add a computer to the network permanently to be able to join it). Then when it came time to actually click 'start', you might see your timetable creation take an hour or two rather than the 1-2 days it can conceivably take now. Presumably since most timetabling software is essentially doing 'educated guess and check' this might actually be possible to code.
(fronbow):If I/(we?) could come up with some sort of api, then I could quite see this being possible. I think the api/backend would need to know about attributes of different systems and whether they have relationships.
So (theoretically) you could have a teacher booking system, a classroom booking system, and a class booking system.
Classroom booking system (extends room booking system)
1 Room can have many bookings, but must have a teacher assigned to it.
The teacher can only be assigned to one room at a given time slot.
Rooms/teachers are booked in time slots optionally defined at 45mins or whatever (this would be defined in an admin page)
Service Booking
The service such as a cleaner to your home for a set amount of time such as 4 hours.
- Start time (when you want the cleaner to arrive)
- Location (where to clean)
- Cost (this would be a set amount, it could even be variable depending on the location)
- Cleaner (a cleaner could be assigned to each job, the cleaner could login and see his/her assigned jobs)
I would suggest we could reuse date, calender, location module(s), e-commerce and profile modules(s)
It might also be useful to look at the new workflow modules this could also users to be notified when the booking is 'assigned/paid for/canceled' etc.
wayout: API Feature Request - A way of assigning something that is booked -> to a node.
fronbow: Some notes on possible code reuse
date, calendar are probably definites; though I would maybe need to extend calendar to display years (I'm not sure whether it does this, but all booking systems I've seen have a yearly view)
e-commerce - it would be nice to provide hooks into most ecommerce modules (I'm thinking ubercart as well as e-commerce)
profile module - we should probably (thru' admin) provide some default profile field requirements (although I'm not sure if this is correct for here? but at the very least we'd need contact details (firstname, lastname, email, tel)
Holiday Flat/Apartment booking system
- There should be different content types allowed, which can be booked. The content types should be completely/freely designable with CCK.
- Currently I'm thinking of 2 content types: Apartment-House and Hotel. An Apartment-House can have several Apartments, which can be booked individually. A Hotel can have several Hotel-Rooms, which can be booked individual. For a Hotel you would not like to create a separate node for every room the hotel has, but a separate node (content type) for each room type (suite, business, standard, ...). For Apartment-Houses you probably want to create a separate node for each apartment, because in most cases apartments are very individually, so you can't create categories for them. As an example, think of an Apartment-House in the Alps with one big Apartment for 8 Persons, two apartments for 4 persons each (but they differ in the layout and size of the rooms, one has a kitchen, the other not, ...).
- To link a node "Hotel Room" with the corresponding node "Hotel", the CCK nodereference module can be used.
- There are different types of offers imaginable:
- Type 1: Fixed Offer: The offer applies for a fixed space of time and has a fixed price (e.g. Apartment 21.01.-28.01.2008 for 399€). Customers can only choose to book the offer as it is. If the offer is booked by somebody, it's no longer available (booked up) to other customers.
- Type 2: Fixed Offer per person: An offer can have a maximum occupancy value. Think of a backpackers' hostel which has a maximum occupancy of 30 beds/persons. You don't want to create a separate offer for every bed in the hostel and it's not likely, that a single customer completely books the complete hostel for 30 persons. Instead you want to create a single offer and setup a maximum occupancy. The booking form allows customers to supply the amount of persons, they want to book the offer for. As long as the offer is not completely booked up (booked number < maximum occupancy) the offer is available to further customers.
- Type 3: Advert-like: Those offers will never be booked up. They just present the apartment to customers and can be booked on request. To display seasonal price differences, there must be kind of a table/matrix that shows the prices. Example Apartment 1: March - October: 99€ per day; November - March: 139€ per day. In the booking form customers specify the arrival and departure day. It's more like a request, which is sent via email to the owner of the offer.
- Type 4: Dynamic Offers, backed up by an booking schedule. Customers can freely specify when they want to book an offer and check the availability for the desired time period. Only useful, if owners carefully maintain/manage their booking schedule.
- Type 5: Auction: Like Type 1 (Fixed Offer) but the price is not fixed. Ebay-like. Owners can setup a starting price for the offer and a time period how long biddings are accepted. The ecommerce-module already has an auction module.
- Strict separation between nodes that describe an object (apartment node, hotel room node) and offer nodes. This way, several offers can link/reference the same description node. Example: An owner wants to rent his apartment. The information to present and describe the apartment (Apartment node linked to Apartment-House node) needs only be entered once. Next he creates an offer of Type 1, which declares that the apartment can be booked in the week of 19.01.2008 - 26.01.2008 for 399€ and links this offer to the Apartment-node. He creates another offer of Type 3 (Advert-like) indicating that this apartment can be booked all the year on request and linking this offer to the same Apartment-node.
- Customers and Owners are Drupal users. Customer-Role, Owner-Role. Owners can create content and offers. Customers can only book offers.
- Notification emails are sent to customer and owner right after a booking
- Support for automatic (semi-automatic) creation of invoices for existing bookings.
- Printing / PDF generation of invoices
- Support for different states (using the workflow module!?) for a booking (new, confirmed, invoiced, paid, canceled, archived).
- Booking forms should be designable with CCK (or webform-module or something else).
- Batch-Processing for content types. If you have existing content types (e.g. for hotels, apartments, rooms, ...) and add new fields to a content type, it should be possible to easily update all existing nodes of that content type. But this is probably just a CCK feature.
- Customers can post a review (text + 5 star rate) the apartment after they've been there, to share their experiences with other users.