Monday, August 18, 2025
26 changes · saas-18.4
Enhancements to existing features
Event staff can now see clearer scan history for attendees at multi-day events. When a ticket is scanned or an attendee is marked as attended, the system logs the action and warns if the ticket was already scanned on a different day, helping teams manage daily attendance more accurately.
Original PR description
**Purpose:** If there is a multi-day event, there's no way manage attendance for each day. **Specifications:** - When ticket is scanned show log in chatter. - In the Registration Desk, when scanning or manually selecting an attendee, if the attendee is already marked as `done` but today's date is different from the current `date_closed`, update the warning message to 'Ticket was last scanned on `<DATE>`' Task-4864066 Forward-Port-Of: odoo/odoo#214194
Opening the customer list in Point of Sale is now much faster when many customers and cart items are present. The system avoids repeating the same order total calculation while the list is open, reducing delays for cashiers in busy sales environments.
Original PR description
Before this commit, opening the customer list in PoS could be slow when many customers were loaded (common in active PoS environments) and the current order had numerous orderlines. This performance hit was due to repeated recalculations of `get_total_with_tax`. This commit resolves the issue by storing the `get_total_with_tax` value of the current order when the customer list is opened. This value remains constant while the customer list is active, eliminating unnecessary recalculations. Performance Impact: With 500 customers loaded and 20 orderlines in the cart, opening the customer list improved from 5 seconds to 200 ms. opw-4921262 Forward-Port-Of: odoo/enterprise#92354 Forward-Port-Of: odoo/enterprise#89526
Resolved issues and error corrections
The website builder now includes a toggle to highlight animated text elements, restoring an option that was lost during the builder redesign. This makes it easier for users editing pages to find and manage animated text, while also correcting a related automated test so the behavior is properly checked.
This change restores the previous sales behavior to prevent crashes when creating rental orders from planning resources. It unblocks rental demonstrations and workflows where currency information may be missing or inconsistent.
Original PR description
"line.currency_id" might be empty or contain more than 1 value, resulting in a crash of the method. This reverts commit ced1335c38834d5ac31f27705a2f7a0047ca8cc2. Traceback discovered when creating a rental order from a resource (planning flow). <img width="1607" height="907" alt="image" src="https://github.com/user-attachments/assets/0980b89b-fc2a-4bfe-a4c7-a290c92bb0e4" /> Quick revert needed to unblock the flow and allow a demo of hotel industry rentals. Forward-Port-Of: odoo/odoo#222826
This fix ensures the website builder prepares uploaded images and other pending changes before saving a reusable snippet. It prevents snippets from storing raw image data, helping saved website blocks work reliably and remain properly optimized.
Point of Sale loyalty rewards now correctly add the free product when the qualifying item has multiple variants. This prevents missed rewards at checkout and helps ensure customers receive the promotion they earned.
Original PR description
Before this commit, when using a free product reward on multi products that have several variants, adding the desired product to the order would not always trigger the automatic addition of the free product as expected. opw-4841759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222979 Forward-Port-Of: odoo/odoo#215576
This fixes tax calculations for down payments and global discounts when invoices use multiple currencies or manually adjusted tax amounts. Businesses should see more consistent totals between foreign and company currencies, reducing rounding discrepancies on sales, purchases, accounting, and point-of-sale documents.
Original PR description
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts…
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts become a way to ensure some results in '_round_base_lines_tax_details'. So after this commit, the manual_tax_amounts won't be manage in '_get_tax_details' anymore. That way, we could also use the manual_tax_amounts for amounts in company's currency. For down payment/global discount, let's handle both currencies instead of only the foreign one. Also, the percentage is applied for each line to keep the whole thing as most accurate and close to the input percentage. If we don't do that, we could end up with a base of 99.99 and a tax amount of 15.01 for a tax of 15%. Since the percentage is applied in a more "global" way, this commits also partially revert https://github.com/odoo/odoo/commit/3a269864534f234127c87ff1567f796904a27d5b This approach is more complex and doesn't give always better results when using round_per_line either. Let's keep it simple and come back to a global approach. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222881
This update brings the spreadsheet component to the latest version and fixes several issues affecting pivot data, formulas, side panels, and clickable cells. Users should see more reliable spreadsheet calculations and a cleaner interface when working with spreadsheet panels.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9c7c14319 [REL] 18.4.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9c7c14319 [REL] 18.4.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/59701a014 [FIX] Pivot: sanitize measure id [Task: 4876828](https://www.odoo.com/odoo/2328/tasks/4876828) https://github.com/odoo/o-spreadsheet/commit/dce5aae09 [FIX] Functions: OFFSET dependencies are not correctly added [Task: 5001405](https://www.odoo.com/odoo/2328/tasks/5001405) https://github.com/odoo/o-spreadsheet/commit/313928857 [FIX] side_panel: replace side panel instead of stacking it [Task: 4911603](https://www.odoo.com/odoo/2328/tasks/4911603) https://github.com/odoo/o-spreadsheet/commit/83019c0ae [FIX] ClickableCells: cache empty positions as well [Task: 5007745](https://www.odoo.com/odoo/2328/tasks/5007745) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Purchase catalog prices now convert vendor prices into the purchase order currency. This prevents mismatched unit prices when buyers add products from vendors using a different currency, improving quote accuracy.
Original PR description
Before this commit, the unit price in the catalog for purchase order wasn't converted from other currencies to the order one It was just set to the price regardless of the vendor currency This fix will automatically convert the catalog prices from seller's currency to purchase.order's currency Steps to reproduce: - Create a product to Purchase - Add a vendor in the Purchase Tab - Set quantity to 1, price to 100 and currency to EUR - Create a RFQ - Select the Vendor from the product created - Check to currency to be USD - Add the product and take note of the Unit Price - Remove the product line - Go to Catalog - Compare the Price with the Unit Price (They doesn't match before the fix) opw-4909789 Forward-Port-Of: odoo/odoo#217285
Fixes an issue where choosing and applying a due date in the website builder's Countdown block appeared to work but was not actually saved. This ensures selected dates persist after repainting or saving and restores expected undo behavior.
Original PR description
In [1] the builder date picker was adapted in order to have the text version of the date updated upon date selection preview (without apply). In [2] that was changed to use the state to reflect the…
In [1] the builder date picker was adapted in order to have the text version of the date updated upon date selection preview (without apply). In [2] that was changed to use the state to reflect the value. But by doing that, on apply, the datetime picker service considered that the applied date was already known and did not call `onApply` anymore, thus not triggering the actual action. This commit fixes the issue by adding a state that contains the value to be displayed in the input. So we have two states: one that contains the DOM value (not in preview mode) and the new state that contains the value to be displayed in preview mode. The datetipicker no longer thinks that the value displayed in the input is the one already applied. So it calls onApply. Steps to reproduce: - Drop a "Countdown" snippet - Open "Due Date" - Select a date - Click on Apply => No undo was available, value was lost on repaint or save. [1]: https://github.com/odoo/odoo/commit/2d1a39f7224495ea04aa8765ae5ac11145a84398 [2]: https://github.com/odoo/odoo/commit/97a49dcec8f2ef7f6b6ec3113fd1b11eb121c610 task-4367641 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The JSON-2 API now returns clearer and more structured error information, making it easier for customers and integrators to understand what went wrong. This improves troubleshooting for common issues such as missing database selection, expired sessions, or incorrect request formats.
Original PR description
This work incorporates several improvements for the error handling in JSON-2. The goal was to be able to "discover" how the JSON-2 API works with the help of every error message, starting with a…
This work incorporates several improvements for the error handling in JSON-2. The goal was to be able to "discover" how the JSON-2 API works with the help of every error message, starting with a simple `GET /json/2`. 1. The response body now holds the result of `http.serialize_exception`: an object with name, message, arguments, context, debug (traceback); instead of only `str(message)`. 2. The order in the `serialize_exception` object nows have the traceback last, this improve the readability of the json response on the wire. 3. Make the 404 - Not Found message more explicit when the database is missing. Make regular users go to /web/login (which is going to redirect to /web/database/selector) and programmers use the X-Odoo-Database header. The latter is for `auth='bearer'` controllers, as it doesn't use the session. 4. Make the 415 - Unsupported Media Type message more explicit. The HTTP stack sends this error when the `Content-Type` of a request is not compatible with the `@route(type=...)` of a controller. For JSON-2 any request that is not `Content-Type: application/json` will receive this message. The message now explicitely states that it is the request `Content-Type` that is likely at fault. 5. There was a complicated conditional in the JSON-2 `_handle_error` to attempt to jsonify the werkzeug's html, or to keep the existing response under some condition. Error handling is not the place to have anything complicated. The code was simplified to: have a response attached already? use it (even if it is not JSON); otherwise, use `serialize_exception` with status code and description. 6. `odoo.http.SessionExpiredException` now has a `http_status` like the other Odoo exceptions. It is 403 - Forbidden, the generic status for anything related to access errors. This simplifies the error handling in JSON-2 a bit. The other dispatchers have dedicated conditions and routines to handle this exception, and are not impacted by this change. We could (and maybe should) had split this single commit in six, one for every case above... but we were lazy.
Product forecasts now correctly account for chained stock movements created by multi-step delivery routes. This helps sales and warehouse teams see expected outgoing quantities accurately, preventing stock availability from appearing higher than it really is.
Original PR description
### Steps to reproduce: - In the settings enable Multi-Steps routes - Put your warehouse in delivery in 2 steps - Create and confirm a sale order for 1 units of a storable product #### > While the…
### Steps to reproduce: - In the settings enable Multi-Steps routes - Put your warehouse in delivery in 2 steps - Create and confirm a sale order for 1 units of a storable product #### > While the pick move was created and confirmed the forecast is still at 0 even tho it should be at -1 and the outgoing pick move should be matched with the SO line in the forecast report. ### Cause of the issue: The issue has been introduced by commit 5b40fb086a0e5677678c312b42dc1f2c8991dc9e The issue being that since the `location_final_id` should not have been considered for the past forecast based on done move chains (because each done move of the chain will refer to the same external `final_dest_id`). The proposed fix was therefore to change the dest_loc_domain as such: https://github.com/odoo/odoo/commit/5b40fb086a0e5677678c312b42dc1f2c8991dc9e#diff-1f24ce9f94c5795040749acca5924384d7d17c0ac39b1993cef3b484e4bd30afR324-R326 However, the new domain: https://github.com/odoo/odoo/blob/995a7072cb3315fc03544b281b1ed5ca4e81e901/addons/stock/models/product.py#L322-L326 ignores completely the part of the condition refering to `final_dest_id` for outgoing moves since the condition is negated here: https://github.com/odoo/odoo/blob/995a7072cb3315fc03544b281b1ed5ca4e81e901/addons/stock/models/product.py#L328-L333 The logical `OR` (`|`) becoming an `AND` (`&`) for the `domain_move_out_loc`. opw-4997982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222241
Payments made to settle a customer's Point of Sale account are now automatically matched with the related customer account charge. This prevents settled POS amounts from incorrectly appearing as available credit for other invoices, reducing accounting confusion for users.
Original PR description
### Problem: When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create…
### Problem:
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.
### How to reproduce:
* Open a PoS session.
* Create an order and pay using customer account.
* Settle this customer's account (inside PoS).
* Create a Sale Order and invoice it (or just an invoice).
* The amount settled can be used as outstanding amount and can be used to pay the created invoice.
enterprise PR: https://github.com/odoo/enterprise/pull/86114
opw-4794793
Forward-Port-Of: odoo/odoo#222980
Forward-Port-Of: odoo/odoo#210619Employees with overlapping contract versions and different work schedules can now request time off when the requested dates fit within the relevant schedule period. This prevents valid leave requests from being incorrectly blocked, reducing HR administration friction.
Original PR description
When an employee has multiple versions with the same contract start and end dates but different working schedules, the system incorrectly blocks time off requests, even if the time off period lies entirely within a single schedule or even a single version. This fix adjusts the significant constraint logic to filter the versions with overlapping contracts to those only overlapping with the leave period. Task-4981318
This fix ensures the employee archiving process uses the employee the user actually selected. It prevents the departure workflow from targeting the wrong or invalid employee, reducing the risk of accidental record changes.
Original PR description
Description of the issue/feature this PR addresses: This pr addresses the issue of the `HrDepartureWizard` attempting to archive an employee that was not initially selected. Current behavior before PR: The `HrDepartureWizard`'s `employee_ids` field is filled with a different employee id than the selected employee, also sometimes may be assigned a non existing id. Desired behavior after PR is merged: The mentioned field is filled with the id of the selected employee. Solved by: Setting the `active_ids` context field within action `action_archive` of `HrEmployeeDeleteWizard`. The related subtask: https://www.odoo.com/odoo/project/1251/tasks/4844003 Forward-Port-Of: odoo/odoo#212734
Manufacturing users can now stop work order operations linked to billable projects even when the operation runs longer than expected. The fix prevents an accounting-related access error from interrupting production tracking while preserving the intended analytic cost recording.
Original PR description
To reproduce:
=============
- create a BOM with an operation having an expected duration
- make sure the product of BOM has MTO and Manufacturing routes
- create a Billable project with visibility=portal
- create an SO with the product of BOM and set the project for analytic distribution
- confirm the SO -> a MO is created
- with a user having:
- hr.group_hr_user
- mrp.group_mrp_manager
- project.group_project_user
- hr_timesheet.group_hr_timesheet_approver
- go to the MO and start the first operation and wait to exceed the expected duration
- stop the operation -> access error on the analytic account line
Problem:
========
when the user tries to stop the operation, at first moment AAL will be created, as we exceed the expected duration, we will try to update the AAL which leads to an access error as the user does not have accounting rights.
Solution:
=========
deal with AAL records as sudo
opw-4897142
Forward-Port-Of: odoo/enterprise#92422When Excel files shared by portal users are converted into Odoo spreadsheets, portal users are now kept at view-only access. This prevents conversion errors and preserves the rule that external portal users cannot edit spreadsheets.
Original PR description
Let's say a Document Folder is shared with a portal user with 'edit' access. The portal user shares a .xlsx file to the folder, and an internal user later try to convert the file to odoo spreadsheet. During the conversion, the portal user has 'edit' role on the folder, which is copied to the documents.access records of the converted sheet. Since Odoo prevents Spreadsheets from being shared in edit mode to portal users, _check_spreadsheet() raises a Validation Error. <img width="544" height="188" alt="image" src="https://github.com/user-attachments/assets/48426ff8-0cd9-4fb0-8e52-31099e586064" /> To resolve this issue, we force portal users to have `view` role on Spreadsheets during the XLSX to Spreadsheet conversion. opw-4753670 Forward-Port-Of: odoo/enterprise#92427 Forward-Port-Of: odoo/enterprise#92134
This fix ensures manually stored external tax amounts also keep the related taxable base amounts. It helps tax calculations and reporting stay accurate when using external tax providers such as AvaTax, including localized integrations.
Original PR description
…unts
Opening a spreadsheet filter editor now replaces the existing side panel instead of stacking another panel on top. This prevents broken Cancel and Remove actions, making filter editing more reliable for users.
Original PR description
Steps to reproduce: - Open the global filter side panel (list of all filters) - Pin the panel - Click on a specific filter to view/edit it Before this commit: - A second side panel was opened instead of replacing the current one - Clicking 'Cancel' on the new panel had no effect - Clicking 'Remove' caused a traceback After this commit: - The new side panel replaces the current one (main or secondary) - The previous panel is restored correctly on 'Cancel' or 'Remove' - If the new panel is already open, we simply close the current one Task: 4911603
This fixes an issue where expanding or collapsing grouped account report lines could leave child lines visible and trigger an error. Users can now fold and unfold nested grouped report lines reliably, improving report usability and avoiding interruptions.
Original PR description
Steps to reproduce: - Create an Account Group - Create a new Account Report as follows: * Name: any * Lines: 1. [test line] * Group By: partner_id,account_id * Expressions: 1. [test expression] *…
Steps to reproduce:
- Create an Account Group
- Create a new Account Report as follows:
* Name: any
* Lines:
1. [test line]
* Group By: partner_id,account_id
* Expressions:
1. [test expression]
* Computation Engine: Odoo Domain
* Formula: [('account_id.account_type', '=', 'asset_receivable')]
* Subformula: sum
- Actions > Create Menu Item
- Open the new report
- Try to unfold/fold a partner line
Issue:
Folding will not fold the first child (representing the created account group). Also, error will raise
```
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
Occured on odoo.nas.cpolar.cn on 2025-04-26 04:58:53 GMT
OwlError: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
Error: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:138:49) (/web/static/lib/owl/owl.js:5752)
at App.callTemplate (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:11363:50) (/web/static/lib/owl/owl.js:3372)
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:9:12) (/web/static/lib/owl/owl.js:5752)
at RootFiber._render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9774:38) (/web/static/lib/owl/owl.js:1783)
at RootFiber.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9766:18) (/web/static/lib/owl/owl.js:1775)
at ComponentNode.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:10493:23) (/web/static/lib/owl/owl.js:2502)
```
Analysis:
Folding issues occurs because of a mismatch in the grouping markup quote escape. If we don't have the very same string the controller cannot properly recognize the parent line and then is unable to fold/unfold properly.
This eventually led to the mentioned error at unfold as the backend will try to generate the apparently missing lines to unfold, only to create duplicate lines
opw-4754241
Forward-Port-Of: odoo/enterprise#89726Tickets created from Timesheets now default to the Helpdesk Team linked to the selected project. This helps prevent tickets from being assigned to the wrong team and keeps timesheet-related support work routed correctly.
Original PR description
Steps to Reproduce: - 1. Go to Timesheets > My Timesheets, start the timer, and select the project linked to the helpdesk team. 2. In the timer header, quick-create a new ticket via the "Ticket" field dropdown 3. Observe that the default helpdesk team on the new ticket is incorrect. Issue: - - When creating a ticket from the Timesheets module (e.g., via timer header or views), the system selects an incorrect default helpdesk team, leading to misassigned tickets. Cause: - - The core default logic for team_id prioritizes user membership or the first team without considering the selected project's linked helpdesk team. Fix: - - Override `_default_team_id` to set the correct Helpdesk Team based on the selected project. - A domain has been added to the team selection field within the timesheet views to only show teams that have the timesheet feature enabled. task-4885679 Forward-Port-Of: odoo/enterprise#92112 Forward-Port-Of: odoo/enterprise#89503
Payroll teams can now correct validated work entries as long as they have not yet been used in a payslip. This helps fix attendance or payroll input mistakes earlier without undoing unrelated payroll work, while preserving protection for entries already tied to payslips.
Original PR description
Originally, the validated work entries cannot be modified, either they have been included in payslips or not. This logic has been adjusted to allow for modifying the work entries marked as "validated" if they are not linked to a payslip. Task #4921300
Fixed an issue where the General Ledger could crash when users enabled the Account Types filter and expanded an account. This ensures accounting users can review payable and receivable activity without interruption.
Original PR description
Steps to reproduce:
- Open general ledger configuration
- Under Options tab, set filter Account Types as "Payable and receivable"
- Open General Ledger report
- Unfold an account
Traceback will raise
```
File "[...]/odoo/tools/query.py", line 101, in add_join
assert self._joins[alias] == (sql_kind, table, condition)
AssertionError
```
Because of the account types filter we already add a "LEFT JOIN" between account_move_line and account_account
Then, trying to add a "JOIN" between the same tables, the system find a different type of JOIN and fails the assert
opw-4742411
Forward-Port-Of: odoo/enterprise#87431Odoo now automatically matches Point of Sale customer account charges with their related settlement payments. This prevents settled POS balances from incorrectly appearing as available credit for other invoices, reducing customer account confusion.
Original PR description
### Problem: When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create…
### Problem:
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.
### How to reproduce:
* Open a PoS session.
* Create an order and pay using customer account.
* Settle this customer's account (inside PoS).
* Create a Sale Order and invoice it (or just an invoice).
* The amount settled can be used as outstanding amount and can be used to pay the created invoice.
commmunity PR: https://github.com/odoo/odoo/pull/210619#pullrequestreview-2853451890
opw-4794793
Forward-Port-Of: odoo/enterprise#92374
Forward-Port-Of: odoo/enterprise#86114DHL rate checks during ecommerce checkout now use a planned date in the future, matching DHL's requirements. This prevents customers from seeing an error when shipping rates are requested with the default current date and time.
Original PR description
Before this commit: During checkout on Ecommerce website the default date of the order is current date and time. There is no option to change the date when getting rate. Which results in an error that the date must be in the future. After this commit: `Planned_date` for getting rate is set in furture to avoid the error. Docs reference: https://developer.dhl.com/api-reference/dhl-express-mydhl-api#reference-docs-section under rating endpoints. opw-4849754 Forward-Port-Of: odoo/enterprise#91705
The restaurant floor plan now only shows appointments scheduled for the current day. Late appointment labels are also highlighted correctly, helping staff focus on relevant reservations and spot delayed customers faster.
Original PR description
Steps to reproduce: =================== 1. Install `pos_restaurant_appointment`. 2. From the Appointments menu, schedule an appointment for tomorrow for a table. 3. Open the restaurant floor plan. Issue 1: ======== - Appointments scheduled for tomorrow are incorrectly shown on the floor plan. Issue 2: ======== - When a customer is late, the appointment label is not displayed in red. Common Cause: ============= - The appointment's `start` field is already a `DateTime` object, but it is being deserialized again, which leads to incorrect time-based comparisons. Fix: ==== - Avoid deserializing the `start` field if it is already a `DateTime` object. Task: 4845006 Forward-Port-Of: odoo/enterprise#86997