[16.0][FIX] pms: skip cancel-by-modification reservations on confirm_all_reservations#400
Merged
OCA-git-bot merged 1 commit intoMay 24, 2026
Conversation
…servations
pms.folio.action_confirm() called with confirm_all_reservations=True in
the context unconditionally re-confirms every reservation of the folio,
including those previously cancelled.
This is problematic for reservations cancelled because of a
modification chain (state='cancel', cancelled_reason='modified'):
re-confirming them re-occupies the room of a superseded version of the
same booking and triggers a ValidationError from _compute_avail_id
("There is no availability for the room type X on YYYY-MM-DD") even
though the booking itself is consistent.
Skip those historical artefacts. Other cancelled reservations
(cancelled_reason in late/intime/noshow, or empty) keep being
re-confirmed: those represent cases where an external system cancels
and later re-confirms the same booking, and the caller of
confirm_all_reservations=True expects them to come back to life.
Today this flag is set only by an external channel-manager connector
import path, so the blast radius of the change is contained.
Member
Author
|
/ocabot merge minor |
Contributor
|
This PR looks fantastic, let's merge it! |
Contributor
|
Congratulations, your PR was merged at 29545e9. Thanks a lot for contributing to OCA. ❤️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug
pms.folio.action_confirm()called withconfirm_all_reservations=Truein the context unconditionally re-confirms every reservation of the folio, including those previously cancelled.This breaks reservations cancelled because of a modification chain (
state='cancel',cancelled_reason='modified'):_compute_avail_idthen raisesValidationError: There is no availability for the room type <X> on <YYYY-MM-DD>from the still-occupying superseded line, even though the booking itself is consistent.The flag is set today by an external channel-manager connector when re-importing a folio whose external status has been reactivated after a cancellation — exactly the case where modification chains accumulate.
Fix
Skip reservations with
state='cancel'ANDcancelled_reason='modified'when iteratingreservation_idsto callaction_confirm(). They are leftovers from earlier versions of the same booking and must not be revived.Other cancelled reservations (
cancelled_reasoninlate/intime/noshow/ empty) keep being re-confirmed: those represent cases where an external system cancels and later re-confirms the same booking, and the caller ofconfirm_all_reservations=Trueexpects them to come back to life.Scope
confirm_all_reservations=Trueis set by exactly one caller in known downstream connectors: the channel-manager folio importer reactivating a previously cancelled folio. The blast radius is contained to that import path.Test plan
cancel/modifiedon the same property and dates — folio should re-confirm withoutValidationError.cancel/noshow(or similar) reservation should still be reactivated.