Download & Extend

Manually editing booking to overlap on same room leads to inconsistencies

Project:Rooms
Version:7.x-1.x-dev
Component:Rooms Availability
Category:bug report
Priority:critical
Assigned:ronald_istos
Status:closed (fixed)

Issue Summary

Here I report a very dangerous bug

Starting from a clean db
1. Create a first booking, for example: from 1/3/2013 to 15/3/2013 and select a room X
2. Create a second booking, for example: from 16/3/2013 to 30/3/2016, and select the same room X
This is a real scenario, where two different customers book the same room, in different periods.

Then edit first booking and change end date to 20/3/2013 (don't change room). Submit.
The booking form report the error: "Room Availability could not be updated"

Bug:
1. First booking registers the wrong "end date", overlapping the second booking. Moreover the event "after updating an existing booking" is yet fired.
2. Looking at room availiability, sometimes is correctly not updated, sometimes availability of first booking is lost

So this leads the DB in an inconsistent dangerous state.

Please, Help

Thanks

Comments

#1

Title:Overlapping bookings lead to a very dangerous inconsisntent availability» Manually editing booking to overlap on same room leads to inconsistencies
Assigned to:Anonymous» ronald_istos

Edited title for clarity - thanks Grazio this looks like something to look into before production release

#2

Status:active» needs review

This has been fixed in latest dev. The solution will avoid inconsistent states while we work on a better UX experience for this. If you could test this would be great.

#3

Hello

Here my tests
------------------------------------------------------------------------------------------------------------------
Platform: clean installation of Commerce kickstart 7.x-2.2 + Rooms 7.x-1.x-dev
------------------------------------------------------------------------------------------------------------------
Booking1: 10 --> 13; Unit 1
Booking2: 14 --> 17; Unit 1

Test 1: modify Booking1 to overlap booking2 (booking1 = 10 --> 15)
Expected: modification should be denied
Result: OK
Message: Could not update calendar because a locked event is blocking the update - you need to unlock any locked events in that period)

Test 2: modify Booking2 to overlap booking1 (booking2 = 11 --> 17)
Expected: modification should be denied
Result: OK
Message: Could not update calendar because a locked event is blocking the update - you need to unlock any locked events in that period)

Test 3: modify Booking1 to override booking2 (booking1 = 10 --> 18)
Expected: modification should be denied
Result: OK
Message: Could not update calendar because a locked event is blocking the update - you need to unlock any locked events in that period)

Test 4: modify Booking1 to override booking2 (booking1 = 10 --> 18) AND assign Unit 2
Expected: modification permitted
Result: KO
Message: Could not update calendar because a locked event is blocking the update - you need to unlock any locked events in that period)

Thanks,
Grazio

#4

i did some more testing on the failed test from gpanico...

it seems that the only time this scenario happens is when there is a reservation directly after the one we try to modify.

my test(s):
Booking1: 10 --> 13; Unit 1
Booking2: 14 --> 17; Unit 1
Booking3: 18 --> 20; Unit 1

Test 1: modify Booking1 to move it to Unit2 but keep the dates the same
Expected: modification permitted
Result: KO
Message: Could not update calendar because a locked event is blocking the update - you need to unlock any locked events in that period

Test 2: modify Booking2 to move it to Unit2 but keep the dates the same
Expected: modification permitted
Result: KO
Message: Could not update calendar because a locked event is blocking the update - you need to unlock any locked events in that period

Test 3: modify Booking3 to move it to Unit2 but keep the dates the same
Expected: modification permitted
Result: OK
Message: Room Availability Updated

(after that also moving Booking2 works, and after that also moving Booking1 -> so i'm guessing it has something to do with the locking on the end date of the previous booking)

also this scenario fails:
Booking1: 10 --> 13; Unit 1
Booking2: 14 --> 17; Unit 1

Test 4: modify booking 1 to start one day earlier
Expected: modification permitted
Result: KO
Message: Could not update calendar because a locked event is blocking the update - you need to unlock any locked events in that period

hope that will help to find the problem any faster, will do some more testing soon and post my findings here.

Best wishes!

#5

Awesome gpanico and flynorc - this will help us test. Should have a more complete fix by next week.

#6

another thing that could maybe help locating the problem is this scenario:
Booking1: 10 --> 13; Unit 1
Booking2: 14 --> 17; Unit 1

test 4 from my previous post shows that we're unable to make Booking1 longer (by moving the beginning date one day back), so i thought about trying this:

Test 5: modify Booking1 to end one day earlier (10 --> 12)
Expected: modification permitted
Result: KO -> the availability is not updated, allthou the booking is
Message: Room Availability Updated

that lead me to try to make Booking1 shorter AND moving it to another room... (before the test i recreated the original case so that te bookings are like they were before Booking1: 10 --> 13; Unit 1 and Booking2: 14 --> 17; Unit 1 )

Test 6: modify Booking1 to end one day earlier (10 --> 12) AND Assign Unit2
Expected: modification permitted
Result: KO -> the availability from original booking is not updated (still shows in the availability management), but the new booking is correctly "added"
Message: Room Availability Updated

so the problem for this case (i guess) is in not removing the original booking which causes the lock.

#7

Hey,
i just tried out the new dev version (from 9th feb) and seems like the problem has been partialy solved...
when 2 bookings are one after another, asigning another unit to any of the bookings works, BUT the original lock is still there -> the booking is now blocking 2 units.
i think the only thing missing is the removal of the original.

will do more testing tomorrow and post my findings here.

#8

Hello
I have just tryed each failure case and all tests have been successfull.

It seems that the problem has been solved

Thanks

Grazio

#9

did you try it with the dev version or the rc2?

EDIT: and if by any chance you have the time, could you try this scenario if you manage to replicate the problem i was experiencing:
http://drupal.org/node/1932168
post #3 describes how i got to it.
It's a bit offtopic, but since i found the mentioned problem while trying to move bookings to check weather this problem has been solved it could be relavant.

thnx.

#10

I used a fresh rc2 with kickstart

Sure, I'll try your case also, asap

Grazio

#11

Status:needs review» closed (fixed)
nobody click here