Our original plan was to include MNN's checkout in the Open Media Project. After evaluating their code and seeing where they were at with deploying it at MNN (still trying), we concluded that it was going to be too much work to update the code from 4.7 to 6, make the UI's easy enough for individual members to use (MNN is a staff run system), and convert dependencies on CiviCRM and a User Point budgeting based workflow into options. We felt if it takes months for a station with the resources of MNN to deploy their system, what hope do smaller locations have?
We needed something much simpler to start from. The Open Resource Scheduler (ORS) has done the bare minimum DOM needed for reservation and checkout, but simply updating ORS to use MySQL instead of several comma separated files for a db and use Drupal users and roles instead of requiring members to remember a second username and password would have given us a very dated, hacked-up code base to try to build new features on. In addition to ORS, I had developed phpLabMan, a stand alone checkout system used at a few universities that had a few feature I really liked (accessory tracking, role based checkout rules, fines for late returns, etc), but like the ORS, wouldn't be a very clean starting point.
Then we started looking at the Bookings API that c.lam wrote for a Google Summer of Code project. We though that if we could rewrite the Bookings API to work with CCK, that would give us the starting point we needed to build additional features on. Each location could define their content types and generally or granularly as they wanted and then they'd indicate that the content type was "bookable" with a UI that is similar to what FeedAPI, Organic Groups, Location, and Scheduler are using. After several hours of conversations on IRC and in person, Brian, Chad Phillips, and I came to the conclusion that in order to get a structure that would allow the features everyone wants to see in the checkout, we needed a different approach.
This is the diagram of that approach...
In order to support reserving items from "buckets" (one of the features the MNN system has), we needed an additional layer of metadata. Rules for the who can reserve equipment, for how longs, and if there is an option/costs to check it out longer, or fines if the item is returned late have to be stored somewhere in a way that applies to all nodes in that content type/bucket. Rules also need to be applied to individual items that are bookable, but not in a bucket. A studio or room are items locations want to be able to book, but they are interchangeable. This is the "metadata content type". Nodes in that content type are programatically created when a content type is marked as "Bookable" or "Bookable as Bucket".
| Attachment | Size |
|---|---|
| DOM_scheduler.jpg | 77.74 KB |
Comments
reduce, reuse, recycle
It would be great if we could leverage a modular flexible reservations solution. It seems like this has not yet become a reality (?) in Drupal. See what looks close at http://groups.drupal.org/node/16604
Joe Golden :: www.triangul.us :: People, Ideas, Connections
Joe Golden :: www.triangul.us :: People, Ideas, Connections
Hopefully this chart helps
Hopefully this chart helps you visualize the advantage of the bucket approach. The first grid is what happens without them when users are allowed to book their own items. The second shows how much more time we free up if we schedule the resources from buckets.
Thanx for Diagram
This is cool. It helps show how buckets will maximize availability of resources for the end user.
As regards modularity and resue, should the bucket feature get added to the booking module? I know that this may be easier said than done ;-)
Joe Golden :: <a http://www.triangul.us">/_\ :: People, Ideas, Connections
Joe Golden :: www.triangul.us :: People, Ideas, Connections
MERCI - Manage Equipment Reservations, Checkout, and Inventory
We started this project hoping we were going to just update Bookings API, but ended up building something much bigger to support the variety of configurations different locations use to manage their checkout. The new module is called MERCI. Since there have been so many attempts at reservation and checkout, every logical name we came up with was taken. We ended up with an acronym for Manage Equipment Reservations, Checkout, and Inventory.
MERCI can extend any content type into a list of unique reservable items (like studios) or bucket of interchangeable items (like DV cameras). We followed the approach used by Organic Groups, Feed API, and Scheduler and added MERCI's configuration to the Edit tab of that content types.
The first version of MERCI on uses the default settings. Eventually, we'll add a role to rule relation that will allow different rates or max durations for users in different roles. An obvious use for that would be charging users in the member role a lower rate. A less obvious would be to have a role called "Active Projects" that is populated in the background similar to how User Karma works. Users who are listed as contributing members of a project that has added new video in the last 3 weeks (or whatever duration is appropriate at your location) are kept in the Active Project role. If the project isn't contributing video back to the station, the user would either have to pay the commercial rate or convince a staff member to temporarily add them back to the Active Project role to get the lower rate.
The goal of the first release of MERCI isn't to be a feature for feature replacement for other, more mature reservation systems, but to lay a solid foundation to build new features on. In some ways MERCI will be a step backwards for DOM, but moving to a single set of users and roles as well as being able to write reports that show the relation between making equipment available and the videos produced with that equipment is pretty amazing. If someone donates a camera to your location, you will literally be able to run a report showing which projects used that camera.
love the name
nice sense of humor guys. starting with a strong base will help all of us build it out to suit our needs. thanks.
Using Taxonomy to Track Accessories
If checkouts were houses, DOM currently lives in a shanty. MNN tried to build the Taj Mahal of checkouts, but after 3 years of planning and construction they have yet to move in (any updates on that?). Our goal with MERCI is to get DOM out of the shanty, but we need to take an approach that keeps everyone's head from exploding trying to build a structure that can do everything.
In phpLabMan's checkout, we used a very simple approach to deal with accessories we wanted to count for inventory, but weren't interested in keeping track of who had a specific battery, firewire cable or tripod. We had a table for kits, a table for accessories, and a table that linked the two. The form showed a checkbox for every accessory a user might get with the kit they were checking out. The list of accessories was stored in the checkout record as a comma separated list. When the user brought the equipment back, the checkout staff would see the list of accessories the that should be returned along with the camera. The interface and table structure looked like this....
When I was creating this image, I realized that we already have tables to support this structure in Drupal's Taxonomy. We do need an additional bucket node type to add the Vocabulary to, but by simply selecting several accessories from the vocabulary for each bookable content type we can add those accessories as checkboxes or a select list to the form and store the accessories as an comma separated list of tids with the checkout record. And that's what we've done in MERCI...
This gives the locations using the system a lot of flexibility, but allows us to move forward without exploding heads. Reports can still be written that count the number of batteries, fire cables, tripods, etc that are currently checked out and compare that the total inventory.
update on MNN
The MNN system has been in development for a long time, that is true. Forgive me if I'm too sensitive about this, but the way you talk about it makes it seem as if no movement has happened. I feel that an unnecessary level of competition between the MNN and DOM systems is being fostered by the tone of some of the posts.
Doing intensive user-centric development with a developer-centric tool on a limited budget takes a lot of time, effort, collaboration, meetings, review, changes, testing, etc..
Working with a large group like MNN is difficult -- we need to get the input of dozens of people that are already overworked. We could have pushed through to release faster, but we felt it was more important to make sure that the end-users of the system were active participants in the development of the tool. That slows down the process but leads to a better tool in the end (and the end is coming soon!).
The MNN system is in the final testing and review stage now. It will be launched in the next couple of weeks and after a final period of testing and dual-use along side the current system it will be put into full-time use in January. (reservations of equipment and facilities; scheduling/managing of training classes; playout to probell and synergy; quarterly show scheduling and day-to-day programming needs; tape library management; etc). At that point, the primary task will be to upgrade the tools to a more recent version of drupal so it will be of more use to other access centers, and the open media project as a whole.
I'm happy to see that you found parts of our architecture worth replication. The fact that you are using our bucket analogy will make it a bit easier to see the MNN system and the DOM systems come together over the next 2 years.
I think that when you get to see the latest code for how we handle creation and maintenance of Buckets and inventory, you will be happy and will be able to take some of the code to address your needs.
I wish that MNN still had someone, like Jacob, that could make participating in these discussions part of his job. Openflows is far too overloaded with projects to take on the level of communication that we would like to see happening, my apology for that.
Very different approach
I really don't see this as competition. More that DOM is taking a completely different approach than MNN. I think it's important to differentiate those approaches. Even more so when Forest was telling people at ACM West in October that MNN's system would be ready for other stations in a few weeks. Having already gone through this code, I knew that this system is so MNN specific and monolithic in approach that no other station was going to be able to use it in "a few weeks". Telling people that only reinforces a negative impression of Drupal held by many of our potential development partners. After years of hearing that MNN's Drupal solution would be ready to share with other location's soon, many people in the PEG community immediately associate Drupal solutions with vaporware.
I've been told that MNN was going to be finishing testing the new Drupal driven system in a few weeks since I started working for DOM... in July! I understand that there are many reasons why this project has been delayed and I'm not really interested in revisiting that discussion. What I don't understand is who benefits by failing to acknowledge that approach didn't work well?
The differences between MNN's approach to Drupal development and DOM's was topic of conversation through most of ACM West. I spent a lot of time reassuring people that we've learned from what happened at MNN and we would be doing things very different. These are some of the specific ways:
In many ways this is the old cathedral vs. bazaar discussion. We are taking the bazaar approach and are hoping that once the core framework is laid that the most exciting improvements happen outside of DOM.
I really hope to see Open Flows as well as several other Drupal shops and internal groups who have developed related solutions hired to improve the Open Media modules for specific locations. If there is a feature in Station a location wants to see added to the Timeslot Scheduler, Andrew Morton would be the logical person to hire to do that. If there are features in MNN's system that locations want, Open Flows would be the logical group to hire to add that. As long as these improvements are added in a way that works for other locations, the patch will be rolled into the next release.
accessories in MNN system
We use a bucket-to-bucket node relativity relationship to connect primary items with their dependencies/accessories. we found this is more stable and easier to maintain over time than the taxonomy solution you are suggesting (which we did look into in one of our rounds of dev work).
Avoiding the exploding head
Really interested in this project and want to play with it on our film dept. website for student check out. Is there documentation? I can't seem to find any. The best I've managed so far is to create a camera bucket type - I have no idea how to proceed further with it. Any help would be super because my paper based booking/sign out system is unravelling my brain...
We are working on some
We are working on some screencasts for MERCI and the other Open Media related modules now, but like MERCI's module page says... we can't really provide help with these modules beyond the partners we're working with until after July. If you can afford the trip to Denver in April, there will be at least one MERCI related session at the Open Media Camp we are hosting.
MERCI does include a import option to get a basic set of equipment configured. To use MERCI's basic import, first copy the merci_import.php found in the Import directory to the root level of your Drupal install. Then open http://YOUR-SITE/merci_import.php in a browser. Copy the content_types.csv, and items.csv to your local computer. When asked, use the browser based upload to upload those files.
That's about all the help I can be right now. Good luck!
Screencasts would be very helpful
My head is currently exploding. I'm not sure why I can't get this to work, but I can't seem to get any MERCI-able content to work. When I used the merci_import.php script and then go to make a reservation, nothing shows up in the pull-down menu for items. I know support is currently limited, but I am starting a project that this module would be perfect for.
It looks very promising, but so far I am having no luck.
Ross-Hunter.com
I created a screencast for
I created a screencast for MERCI that has some audio problems, but I think it will answer your questions about the configuration...
http://www.denveropenmedia.org/project/open-media-project/show/merci-scr...
Next up
Getting this error when trying to create a new content type:
user warning: Unknown column 'min_cancel_hours' in 'field list' query: UPDATE merci_node_type SET type_setting = 'resource', max_hours_per_reservation = 0, allow_overnight = 1, allow_weekends = 1, late_fee_per_hour = 0, rate_per_hour = 0, fee_free_hours = 0, status = 1, spare_items = 0, min_cancel_hours = 0 WHERE type = 'merci_hvx_200' in /Volumes/Data/film/modules/merci/merci.module on line 1304.
Deleted all reference to min_cancel_hours in merci.module and now MERCI seems to be functioning.
screencast
Did you know the audio goes into an extremely loud static at 9:29 and continues for the balance of the video. Is it possible to get the video re uploaded? It was extremely helpful, and I've been watching it with the sound off to try and glean more information, but with the resolution so small, it's difficult to make out what's going on.
Thanks for the help. Merci is really starting to come together for us!
We uploaded this again to
We uploaded this again to http://openmediaproject.org/content/merci
Thanks!
Thanks, just waiting for my auth so I can log into that site. :)
That was an issue because I
That was an issue because I forgot to include an update in the .install to add that column, but that has been resolved. See http://drupal.org/node/449216
I think you just need to run http://YOUR-URL/update.php to solve that problem.
nice !
This module looks very interesting..
Did anyone figure out how to display the availability calendar? I just found this: http://drupal.org/node/363983
Also, is there an easy way to set a minimum hours number?
Hotel booking
I have been searching for module for weeks now that can handle booking of a hotel. I guess is that there could be some out there since it must be a quite common request.
Will this module be able to be used for hotel bookings. That is:
-booking days (not just hours and minutes)
-booking weeks
-have an overview of the booking in a calender
etc...
Else, do you now of any other module that would do the trick?
Thank you and good luck with MERCI that in all seems to be very flexible and useful.
I'd think MERCI would be the
I'd think MERCI would be the best option for hotel type reservations because of the bucket approach. We borrowed buckets from an unreleased Drupal checkout system developed by OpenFlows for MNN, but the concept is what I'm assuming most hotels already use. Customers are reserving a type of room, not a specific room. The general reservation (placeholder for a type of room) is converted to a detail reservation (customer is getting the key to a specific room) when the user shows up.
We evaluated every checkout option we could find before opting to write MERCI from scratch so I'm fairly confident you won't find this functionality in any other Drupal booking/reservation solution.
We broke MERCI's reservation down to 15 minute increments because that was the smallest size useful for equipment checkouts and helped keep the size of the arrays reasonable. MERCI currently has problems running with as much as 32MB of memory allocated to PHP. When a user checks the availability of a bucket with 10 items over the a week MERCI is looking at 10 (items) x 4 (15 minute segments in an hour) x 24 (hours in a day) x 7 (days in a week). So if you have 10 basic rooms, MERCI is checking 6720 15 minute segments to ensure there is always at least 1 (or more if you configure it to leave more spares) available.
MERCI could be modified to reserve entire days which would certainly improve the memory use, but that's not one of the features we're working on.
So if the main use would be
So if the main use would be to book weeks and sometimes days, then MERCI would consume to much resources in it's current state?
I've built a booking application in PHP some years ago that lets school administrators book students for practice at companies. Right now the shortest period is a week and that will be the most common use in the future, but we'll be adding the opportunity to book single days if needed.
I'm in the processes of redoing this in Drupal in some way or the other (trying to do this "the Drupal Way" or a very custom module). From what I've read MERCI is not suited for our need right now.
"consume to much resources"
"consume to much resources" is relative. We run MERCI on server with several gigs of RAM so this is not an issue. If you're running Drupal on a shared host, that would be an issue.
MERCI is much less resource intensive when using Resources instead of buckets. I think this might work really well for you if you use Fago's node profile module so that users can "be" a MERCI Resource.
I think you and mschvili should get together and either write or hire someone to write this patch. I'm guessing this would take 4-6 hours to write and test.
Ok, maybe I'll take a closer
Ok, maybe I'll take a closer look at MERCI. But I'm on a tight schedule and I think the easiest way right now is a custom module where I can re-use some of my embarrassingly hackish code :)
Anyway, this is basically how the booking system works right now that needs to be created in MERCI in case I would use it (bear in mind that the terms may be odd, I'm trying to translate from Swedish):
- A company can create one or many practice locations connected to the company (like "front desk" or "assembly line").
- Every practice location can have one or many practice periods defined (like "week 10, 11 and 12" - we use week numbers a lot i Sweden).
- A school administrator selects which time periods to work with (like week 30 to 34) and which class to work with (within the current school).
- The school administrator is presented with a list of practice places that offer practice periods based on the selection.
- If the practice period is already booked then the name of the student is shown (and what class he/she belongs to).
- If the practice period is available there is a link which opens a popup window with at list of all students in the selected class.
- Non booked students can be clicked and that closes the popup and books the student at the current practice period.
- There is also a list view of all bookings that are made and function to print report cards that the students bring to the company.
The improvements I want to do is:
- Add the option to book days and not weeks (without making the booking of weeks more difficult).
- Present the booking as a grid of some sort, instead of a list, maybe with checkboxes.
- Use AJAX where it possible to save clicks and reloads.
- Any other improvement that would make to booking process easier.
- Use Drupal components where I can, especially use Drupal users as students.
- Not make it bloated with unnecessary features we don't need. (Since it's custom build today we have exactly and only the features we need. I'm afraid a general booking tool would give me features I don't need or require a lot of time to customize.)
(I'm considering to hire someone more Drupal skilled than me (preferably someone in Sweden) to aid me with this to save time.)
(Btw, there won't be a node profile module for 6.x, instead Fago is recommending the content_profile module.)
content_profile would work
content_profile would work just as well since MERCI can extend any content type.
Do you know Daniel Westergren? He's in Växjö. He spent a week in Denver while we were getting started on the modules that make up the Open Media Project. He might be able to help you track down a developer.
I really think you can tweak MERCI to do what you want by booking Students as Bucket Items. A Company with "practice" space would even be able to book a specific number of students.
1) Company A defines the start time and end time and the number of students the are reserving to a Reservation node titled Week 10 - Front Desk.
2) School administrator converts buckets to actual students. MERCI's validation won't allow students to be booked into the same place.
3) Students can see were they've been booked.
First of all I just wanna
First of all I just wanna say thanks for taking the time to make these valuable replies!
I don't know Daniel, but maybe I will contact him, thanks for the tip.
How to change the interval from 15min to a day?
Thank you for your answer.
Can you give me a hint for an approx for how we could create an additional module that change interval from 15min to a day?
We do actually want to book specific rooms. Would this also be possible to change using the module above?
This would need to be a
This would need to be a patch to MERCI that added a field or select list to configure reservation period and then going into each validation function and changing the logic for 15 minute increments to use that variable. Not rocket science, but not a novice level patch either.
MERCI allows you to add reservation functionality to any content type as a Bucket or a Resource. We use Resources for items like Studios and Computer Labs that are not interchangeable.
Can it be used for membership based rental
Hi, i have been searching for last 2 weeks to find the right module, solution wtih no luck, any help here will be appreaciate.
This is my question and how i landed up here posting:
http://drupal.org/node/633448#comment-2268206
Can you please suggest me if i can use MERCI and tweak it in some way to make it work for my business.
I don't think you are going
I don't think you are going to find a single module that does exactly what you want. MERCI comes close and would handle the reservation and check out of DVD, but currently doesn't limit users to X number of rentals based on membership level nor does it actually process the payment. Limiting users to X items feature could be added as a sub_module with less than 10 hours of work. Ubercart integration would be a little more difficult, but possible. It would probably make the most sense to tie that to Reservation confirmation emails. At that point the Reservation node would have the merci_commercial_total and merci_member_total fields populated. MERCI could send an email to the member asking them to confirm their Reservation by paying for it.
If you are interested in funding a bounty for those features, we'd love to work with you to find a developer interested and capable of doing the work.
agreservations
@mschvili-gdo
There exists a community module i wrote which depends on merci and calendar and ubercart being installed. (All 3 very cool modules)
Tieing those together to a solution for hotels. Name is agreservations
Its exactly designed for the use in hotels. Its still in developmentstate
but i will make a stable release available in April.You should have a look
Cheers Andreas
I took a look at
I took a look at agreservations. Nice. So you are ignoring MERCI's member/commercial costs completely and only using it for booking full 24 hours periods.
I'm not seeing a check on availability in the calendar. Am I missing it? It seems like what would make this truly useful is a programmatic availability check. Something like merci_node_type_save_validate(), but that can pass a single item/bucket, start, end, and an optional role. The merci_check_availability function would return a true if the item is available and false it it isn't.
Hi kreynen, First let me tell
Hi kreynen,
First let me tell you i really like merci and for me it was easier to use merci as a resourceconflict and reservation engine
than the bookings api which not uses nodes (well they are working on that for the next version)
At the moment i ignore the MERCIs member and commercial cost, only using ubercart for cost and pricing.
the plan is to use the best of the 3: merci, calendar, ubercart.
Ubercart also allows for integration with an professional accounting software...
I use merci, for the 24 hour bookings (but i will use it for hourly reservations too like tablereservations...) and i use the merci reservationform. That decision already saved alot of time.
There is a reason why i don´t use bucket items for hotelreservations, because in the end you have unique rooms to reserve +
merci is faster with resources.
But agreservations also implements unittypes to fit the need of an availability counting down 2 zero in the future when
integrating with OTA (Open Travel Alliance protocol) There will be availablility calendars in future for each unittype.
i think merci fits best + it has enough supporters and developers behind it(i see merci in drupal7 sooner than other resourceconflictmodules which have not enough steam) and it already saved me alot of time.
the check on availability is at the moment made by just looking at the bookingcalendar by the receptionist.
the anonymous sitevisitor shouldnt see the bookingcalendar, he is supposed to use the searchwidget and the
multistep reservationform to check availability. in the future an integration of the Availability Calendars module
will be made.
or do you mean in the code?
programatically the availabilitycheckin in the code is made with this function:
// from the mercimodule merci_get_reservable_items function -> adjusted to return nodes instead of optionstrings:
function agreservations_get_reservable_items($merci_type, $content_type, $start, $end, $reservation_nid = NULL) {
.
so basically i just copied your availablilitycheckfunction for resources and adjusted it to give me back nodes.
i hope you are ok with my approach on using merci to serve the needs for generating a solution for hotelbooking.
If you have suggestions what can be done better or features that are already in merci that i was not aware of please tell me ;-)
Greetings
Andreas
Just so you know, I've
Just so you know, I've talking to tirsales about converting MERCI into just a UI that runs on Bookings API.
And the main-critics on
And the main-critics on Bookings API (not using nodes) will then be gone - I'm currently working on a rewrite regarding this issue.
when bookingsapi uses nodes
it then will depend on what is fitting better at that time for me: directly using the bookings api or merci or whatever else. But as i mentioned at the moment merci is in my opinion the best solution for this kind of problem(checkin checkout resources and conflictchecking) for drupal at this time. of course the idea for writing an api to handle all the bookings stuff is a good 1 and i am looking forward to see the bookings api finished. agreservations will be continuously developed - there are lots of features which need to be implemented yet. but it also is already usable i think.
greetings Andreas