[IMP] booking_engine: add availabilities#2018
Closed
fw-bot wants to merge 1 commit intoodoo:saas-19.2from
Closed
Conversation
Collaborator
|
|
Author
|
This PR targets saas-19.2 and is part of the forward-port chain. Further PRs will be created up to master. More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
Author
|
@trcazier @vava-odoo child PR #2019 has become a normal PR because head updated from b8838c4 to 35d712d. This PR (and any of its parents) will need to be merged independently as approvals won't cross. |
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: 7446467
trcazier
force-pushed
the
saas-19.2-19.0-hotel-occupancy-availability-trcaz-518097-fw
branch
from
10dd8eb to
0db2d8c
Compare
Author
|
@trcazier @vava-odoo this PR has become a normal PR because head updated from 10dd8eb to 0db2d8c. It must be merged to be forward-ported further. |
Collaborator
robodoo
pushed a commit
that referenced
this pull request
Apr 21, 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 #2018 X-original-commit: 7446467 Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
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: #2014
Forward-Port-Of: #1912