Edit Booking Issue: Could not update calendar because a locked event is blocking the update - you need to unlock any locked even

Same problem here: in file
rooms_availability.booking_event.inc

I see:

  public function unlock() {
    db_delete('rooms_booking_locks')
    ->condition('state', $this->id)
    ->execute();
  }

After a lot of debug I found that the value passed inside variable $this->id has a "-" char before the number(!!!). I watchdog I see that the value stored in $this->id is:
-90 instead of 90, or
-91 instead of 91, etc.

If I revert this value everything goes well:

  public function unlock() {
    $id = 0 - $this->id;
    
    db_delete('rooms_booking_locks')
    ->condition('state', $id)
    ->execute();
  }

I can't understand why! Any help?

Ok, I found the problem inside the file:

rooms_availability.module

in witch the function:

/**
 * Sets event ids
 *
 * @todo - Make this depend on a paramenter
 */
function rooms_availability_assign_id($id, $status = 0) {
  // Add eleven for now - this allows for 10 states that do not
  // refer to a specific booking
  $id = $id + 11;

  if ($status == '0') {
    return -($id);
  }
  else {
    return $id;
  }
}

inverts the booking_id value. Why?

Negative values of $id on rooms_bookings entities represent 'unpublished' (unconfirmed) bookings. From rooms_booking.install:

/**
 * Create booking_status field in rooms_booking table
 */
function rooms_booking_update_7001() {
  $booking_status = array(
    'description' => 'The booking status (1 published, 0 unpublished).',
    'type' => 'int',
    'not null' => TRUE,
    'default' => 0,
    'initial' => 1,
  );

  db_add_field('rooms_bookings', 'booking_status', $booking_status);

  return t('Add field booking_status in Rooms Booking table.');
}

Working on this

Any updates on this? I also have the locked booking problem.

Will try to get this in next release.

Hello

I'm trying to reproduce this bug again in our local development repo, so I think it could be closed.

However, postponing until rooms-7.x-1.3 will be ready to go waiting for feedback then.

Regards

Rooms 1.3 is out now.

Would it be possible for the original bug reporter to test with the latest version to see if this locking error is still present?

I have upgraded to 7-1.3 and still have a locking error. Also, rooms marked as 'unavailable' are bookable.

Dang!

If marked as 'On request' they act like 'unavailable'.

I'll try a fresh install...

This seems to have resurfaced in 7.x-1.4+16-dev

Just tested this in 7.x-1.4+16-dev - works for me without any problem.

Funny it seem to clear itself. I created an anonymous booking for that date and it appears again.

I'm getting this issue on 7.x-1.7. A booked event that spans the next day blocks.

This might be down to the UI and the fact that bookings span from half of arrival date and half of departure date. I know that a booking is overnight and therefore depart the next day.

If you select a single day and create a booking the subsequent day populates for departure (e.g 2nd Mar arrival, 3rd Mar departure). If you select a range (e.g 2-3rd Mar) the 3rd is the departure date. This seems inconsistent.

If an approach was adopted whereby a day is selected and the departure was always the next day I'm sure the issue of blocked events would go away. The logic would only have to act on the days selected as you would not be selecting the departure day - that's a given.

I'm getting this issue on 7.x-1.7. A booked event that spans the next day blocks.

This might be down to the UI and the fact that bookings span from half of arrival date and half of departure date. I know that a booking is overnight and therefore depart the next day.

If you select a single day and create a booking the subsequent day populates for departure (e.g 2nd Mar arrival, 3rd Mar departure). If you select a range (e.g 2-3rd Mar) the 3rd is the departure date. This seems inconsistent.

If an approach was adopted whereby a day is selected and the departure was always the next day I'm sure the issue of blocked events would go away. The logic would only have to act on the days selected as you would not be selecting the departure day - that's a given.

Always applying the extra date for departure:

// If we select one day from the calendar, postpone the departure date.
// UPDATE: Departure date should always be the day after selected date
//if ($start_date == $end_date) {
$book_end_date = $book_end_date->add(new DateInterval('P1D'));
//}