Opposite to products, where we may have a little stock to attend some situations, in rooms renting the hotel (mainly the small businesses) will always want to have full occupation and it probably won't save some rooms "for emergency".

Considering that, I suggest that Rooms module should tight the cart concurrency. This is one thing not made by Rooms or Commerce now. I tested that and if all the units are already in users' carts for one day, ready for pay but not paid yet, and a last person add any unit for that same day, it permits you to add it to your cart and pay. It won't give you a "sold out" or "all units are reserved" message. If all that units are payed later (and the system won't check for that and will let them been paid), that will be the chaos.

Comments

ronald_istos’s picture

ronald_istos commented

Interesting point but don't you think that we should not make rooms unavailable just because they are in a cart.

Consider this scenario:

Hotel has 5 units.

5 users come to site, think of booking, place something in the cart and then change their mind. They leave the site and may or may not return at a later date.

Currently, if user 6 comes along places something in their cart and pays they get the room.

If we didn't do this User 6 would see that no units are available. End result being that the hotel does not get even one booking.

So the stance we take is, unless you paid for it it is not yours. You need to complete the process and checkout.

Vuds’s picture

Vuds commented

I think that as a developer, you should give the option to your customer to choose.

I understand your argument, but in counterpart, beyond pre-book the room, you can also put a rule like: if the user that have put the room in the cart doesn't pay in, let's say, 1 hour (action by cron), then empty the cart and release the dates. The advice for this deadline can be offered in the cart, for example.

In the truth, it is very easy to do this with Rules and some code right now, but Rooms is lacking of a status (pre-book, pre-reserve, name it as you wish) specially for this.

I could do that with "Reserved" status, but from what I studied Rooms code, that could imply in unexpected events, and also can confuse the system administrator.

acrollet’s picture

acrollet commented
Version: 7.x-1.0-rc3 » 7.x-1.x-dev
Priority: Critical » Major
Issue summary: View changes
Status: Active » Postponed

Just commenting to mention that expanding the number of booking states (or ideally) making them more flexible is something we've been thinking about a bit and hope to get to at some point.