[IMP] booking_engine: add availabilities#2014
Closed
fw-bot wants to merge 1 commit intoodoo:saas-19.1from
Closed
Conversation
Collaborator
|
|
Author
|
@trcazier @vava-odoo cherrypicking of pull request #1912 failed. stdout: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?).
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
you can use 
trcazier
force-pushed
the
saas-19.1-19.0-hotel-occupancy-availability-trcaz-512453-fw
branch
from
77c08a5 to
1bb02be
Compare
Adds a new feature for the booking engine: availability & occupancy, which allow the user to monitor the occupancy of their planning resources for each day using pills in a Gantt chart. This is done with automations on create & update of several models tied to the computation of an availability, namely resource.calendar.leaves, planning.slot, product.template & resource.resource. A CRON is also scheduled at night to create the availability records for the next 500 days in prospect of the channex integration. In more detail, a single update server action is used across all the automations' server actions to recompute all the availabilities flagged with a `x_to_recompute` boolean to minimize faulty states due to race conditions. This way, each automation only has to flag the current (and new availabilites in the case of on create or edit) availabilities tied to records being updated or unlinked with that boolean, then trigger the recomputation in a separate CRON that will fetch all the availabilities that have to be recomputed instead of each automation recomputing it separately with its own state. A CRON is used instead of just a server action for two purposes: 1. Schedule a recomputation every day at night to account for the possible race conditions happening to correct the faulty state 2. Reuse the same server action everywhere, even in the unlink. In the unlink, calling the server action directly does not have the desired behavior since the server action is triggered before the records are actually deleted. Therefore, the records to be deleted are still taken into account for the recomputation. Using a cron fixes this because the computation happens after the records are deleted. Also adds more demo data for each of the industries using booking_engine. X-original-commit: 5387034
trcazier
force-pushed
the
saas-19.1-19.0-hotel-occupancy-availability-trcaz-512453-fw
branch
from
1bb02be to
27a874a
Compare
Collaborator
|
@robodoo override=ci/industry |
Contributor
|
@robodoo r+ |
robodoo
pushed a commit
that referenced
this pull request
Apr 20, 2026
Adds a new feature for the booking engine: availability & occupancy, which allow the user to monitor the occupancy of their planning resources for each day using pills in a Gantt chart. This is done with automations on create & update of several models tied to the computation of an availability, namely resource.calendar.leaves, planning.slot, product.template & resource.resource. A CRON is also scheduled at night to create the availability records for the next 500 days in prospect of the channex integration. In more detail, a single update server action is used across all the automations' server actions to recompute all the availabilities flagged with a `x_to_recompute` boolean to minimize faulty states due to race conditions. This way, each automation only has to flag the current (and new availabilites in the case of on create or edit) availabilities tied to records being updated or unlinked with that boolean, then trigger the recomputation in a separate CRON that will fetch all the availabilities that have to be recomputed instead of each automation recomputing it separately with its own state. A CRON is used instead of just a server action for two purposes: 1. Schedule a recomputation every day at night to account for the possible race conditions happening to correct the faulty state 2. Reuse the same server action everywhere, even in the unlink. In the unlink, calling the server action directly does not have the desired behavior since the server action is triggered before the records are actually deleted. Therefore, the records to be deleted are still taken into account for the recomputation. Using a cron fixes this because the computation happens after the records are deleted. Also adds more demo data for each of the industries using booking_engine. closes #2014 X-original-commit: 5387034 Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com> Signed-off-by: Tristan Cazier (trcaz) <trcaz@odoo.com>
This was referenced Apr 20, 2026
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
4 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.
Adds a new feature for the booking engine: availability & occupancy, which allow the user to monitor the occupancy of their planning resources for each day using pills in a color-coded Gantt chart heatmap.
This is done with automations on create & update of several models tied to the computation of an availability, namely resource.calendar.leaves, planning.slot, product.template & resource.resource. A CRON is also scheduled at night to create the availability records for the next 500 days in prospect of the channex integration.
In more detail, a single update server action is used across all the automations' server actions to recompute all the availabilities flagged with a
x_to_recomputeboolean to minimize faulty states due to race conditions. This way, each automation only has to flag the current (and new availabilites in the case of on create or edit) availabilities tied to records being updated or unlinked with that boolean, then trigger the recomputation in a separate server action that will fetch all the availabilities that have to be recomputed instead of each automation recomputing it separately with its own state.A CRON is used for the unlinks instead of just a server action because calling the server action directly does not have the desired behavior since the server action is triggered before the records are actually deleted. Therefore, the records to be deleted are still taken into account for the recomputation. Using a CRON fixes this because the computation happens after the records are removed from the DB. Unlinks of these 4 models are rare cases, and therefore less likely to cause a problem than running the CRON for every little change, hence why we still use the server action for those, in addition to it working properly unlike the unlink.
Also adds more demo data for each of the industries using booking_engine.
task-5913061
Forward-Port-Of: #1912