Wednesday, August 20, 2025
18 changes · saas-18.3
Enhancements to existing features
This update adds automated test coverage for key Restaurant Point of Sale workflows, including table management, order courses, bill splitting, floor views, and tips. This helps reduce regressions and improves confidence that core restaurant operations continue to work reliably after future changes.
Original PR description
This commit introduces HOOT test coverage for the POS Restaurant module: - Added tests for primary models: restaurant.table, restaurant.order.course, and patched pos.order - Added tests for patched pos_store.js. - Added component tests for SplitBillScreen, FloorScreen and TipScreen. task-4945629
This update adds automated test coverage for loyalty features in Point of Sale, including gift cards, rewards, order handling, and related screens. It helps reduce the risk of loyalty-related issues reaching customers by validating key workflows during development.
Original PR description
In this commit: ======================= - Added HOOT tests for the `pos_loyalty` module. - Included tests for main models like `loyalty.card` and patched models: `pos.order` and `pos.order.line`. - Added tests for popups and screens related to loyalty features. task - 4945628
Users now see a warning when turning on WhatsApp debug mode, explaining that media files will stop being received. This helps administrators understand the operational impact before enabling the setting and reduces accidental disruption.
Original PR description
#### Step to reproduce: - go to WhatsApp > Configuration > WhatsApp Buisness Account - enable debug mode #### Previous behavior: - active debug mode #### Expected behavior: - active debug mode - warn user that WhatsApp debug mode will stop medias from being received Other solutions would include the use of: - warning. They are triggered only on `onchange` methods. However, debug_logging is updated through buttons which do not trigger `onchange`. Therefore, to update it through a field it requires some changes in the XML which aren't appropriate for stable. - confirm using a wizard. It would require a new view which is not stable either. opw-4678542 Forward-Port-Of: odoo/enterprise#89995
Resolved issues and error corrections
This fixes the Australian localization so the GST-only import tax is treated as fully included for customs purposes again. It restores the expected tax setup that had been unintentionally removed, helping businesses calculate Australian import GST correctly.
Original PR description
It was price_include before and got removed with the changes from https://github.com/odoo/odoo/commit/be308e106ce9699f99efe133976c40519d6128f9 Re-add them 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 Forward-Port-Of: odoo/odoo#223260
Point of Sale payments marked as Force Done now follow the auto-validation setting as expected. This ensures cashiers are automatically taken to the receipt screen when terminal payment auto-validation is enabled, reducing checkout friction.
Original PR description
When doing a force done on a terminal payment, if the auto validation was turned on, it would not be triggered after clicking on the force done button. Steps to reproduce: ------------------- * Turn on the auto validation for terminal payments * Create a new order and add a product * Select a terminal payment method (You can fake the force done state as I did in the tour) * Click on the "Force Done" button > Observation: You are not redirected to the receipt screen. opw-4954406 Forward-Port-Of: odoo/odoo#223282 Forward-Port-Of: odoo/odoo#222867
The accounting dashboard now displays amounts awaiting review with the correct currency handling for journals using a foreign currency. This prevents users from seeing a misleading currency symbol next to a company-currency amount, improving trust in dashboard figures.
Original PR description
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: Chkl: <strike>Misc and Sales/Purchase Journals should display all amounts in company currency</strike> Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the one from the journals. We therefore use the same logic as for the bill/invoices opw-4349684 Forward-Port-Of: odoo/odoo#215512 Forward-Port-Of: odoo/odoo#203475
This fix prevents a hidden search sorting field from being accidentally removed while editing website pages. It helps avoid save-time errors and keeps website search forms working reliably after content edits.
Original PR description
Problem: In Website, the `order_by` hidden input stores the selected sort order for search. This input can currently be deleted via `oDeleteBackward`, which may break the form behavior. Solution: Make `order_by` input unremovable to ensure form integrity. Steps to reproduce: - Add a "Title" text block - Insert a search element before the text - Delete all the text - Use backspace to delete the header block - Save - > A traceback occurs because the `order_by` input was deleted opw-4863089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220107
Fixes a display issue where collaborator avatars could overlap the form status buttons while scrolling long records. The status area now spans the full form width and only shows its shadow while scrolling, improving readability without adding unwanted horizontal scrolling.
Original PR description
User avatars displayed in collaborative mode overlap with buttons when scrolling. This commit extends the statusbar to take the full width, independently of the sheet's one. Also, to avoid an ugly shadow when not scrolling, it only adds it when the scroll is actually performed. Steps to reproduce: - open a task with two users - write in the description in collaborative mode -> user avatars should be displayed - make sure the description is long enough for the sheet to scroll - scroll for one of the avatars to reach the sticky statusbar => overlap between the avatar and the statusbar task-4907797
Purchase orders now recalculate the Company Total when the order currency is changed. This prevents outdated totals from being shown and helps users see accurate company-currency values after exchange rate changes.
Original PR description
**Steps to reproduce:** 1. Create a Purchase Order (PO) with a non-company currency (e.g., EUR if the main currency is USD). 2. Add at least one order line so the "Amount Total" is greater than zero. 3. Change the currency of the PO to a different one and save the record. **Expected behavior:** The `Company Total` field is recomputed using the new currency's exchange rate. **Actual behavior:** The `Company Total` remains unchanged, still showing the value in the original currency. **Fix:** Add `currency_id` to the `@api.depends` decorator of the `_amount_all` compute method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220501
Customer invoices can now be sorted by the Status and Sent columns in the invoice list. This makes it easier for accounting users to organize invoices and quickly find records by payment or sending state.
Original PR description
**Issue** Users were unable to sort invoices by the "Status" and "Sent" columns in the customer invoices list view. **Steps to Reproduce** 1. Go to Accounting > Customers > Invoices 2. Try sorting by the "Status" or "Sent" columns 3. Observe that sorting is not functional for these fields **Root Cause** Both `status_in_payment` and `move_sent_values` are computed (non-stored) fields. Odoo cannot sort by non-stored fields unless a SQL representation is provided using the `_field_to_sql` method. Opw-4976838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222357
This fix prevents an error that could occur when a user removed a product from the parts list on a repair order and then changed the customer. Repair orders can now be edited and saved normally in this scenario, improving reliability for repair workflows.
Original PR description
When User removes the product from parts in repair order and tries to change the partner, A traceback will appear. Steps to reproduce the error: - Install ``repair`` module - Create new repair order > Add a line > Add a product in parts > Save - Remove product from parts > change customer > Save Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/122dece7eeedbf670254aebd2a2d69642b381547/addons/repair/models/repair.py#L319 When user removes the product from parts, ``precision_rounding`` becomes 0.0 Which results in the above traceback. sentry-6650889934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223224 Forward-Port-Of: odoo/odoo#212577
The point of sale preparation display no longer crashes when a restaurant uses only one preparation stage and marks it as Reset or Done. This keeps kitchen workflows running smoothly for simpler setups and avoids an interruption previously reported through Sentry.
Original PR description
This error occurs when we try to mark a single stage as `Reset` or `Done` in the preparation display. Steps to reproduce: --- - Install the `pos_restaurant` module - Create a New `Preparation Display` with one stage - Open `Preparation Screen` - Now `Reset` or `Done` the stage in the other tab Traceback: --- `IndexError: tuple index out of range` At [1], an error occurs because it tries to access a `position` that doesn't exist in the tuple. This happens because at [2], the code attempts to retrieve the second-to-last (-2) stage position, but only one stage is being used. [1]- https://github.com/odoo/enterprise/blob/285cca92a52f7b79de1d020558aa9b116cd7e44a/pos_enterprise/models/pos_prep_stage.py#L21-L22 [2]- https://github.com/odoo/enterprise/blob/285cca92a52f7b79de1d020558aa9b116cd7e44a/pos_enterprise/models/pos_prep_state.py#L72 sentry-6681171781
The accounting reports export now handles account codes or values that look like infinity without crashing. This ensures users can download Trial Balance spreadsheets even when account codes contain very large scientific-notation-like text.
Original PR description
_set_xlsx_cell_sizes tries to convert each cell into a float if it's possible. If the cell contains "inf", "1e1000" (or any value such that float(value) = float("inf")), then there is an OverflowError which is not catch by the try/except.
To reproduce, set an account code as "1E1000", make this account appearing in the trial balance (by creating a move) and export it as XLSX.
opw-4981385
Forward-Port-Of: odoo/enterprise#91686Dutch tax payment wizards now use the Omzetbelastingnummer when it is available, instead of always relying on the company VAT number. This ensures the payment communication is generated correctly, reducing the risk of payment matching issues with tax authorities.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_nl - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous…
**Steps to reproduce:** - Install Accounting and l10n_nl - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous month - Confirm the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Return" - Select previous month - Create "Closing Entry" and post it - On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link - A wizard will appear fot the VAT payment **Issue:** The value of the "Communication" field is incorrect. **Cause:** The "Communication" field is always computed from the VAT of the company. However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT. **Solution:** Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set. This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module. opw-4836615 Forward-Port-Of: odoo/enterprise#92563 Forward-Port-Of: odoo/enterprise#92407
Odoo Studio now handles cases where a button refers to a server action that has been deleted. Instead of showing an error and blocking users from editing the form, the missing action is ignored so users can continue working normally.
Original PR description
The error is triggered when a user configures a button to execute a serveraction, deletes the associated server action, and then attempts to edit the button. This causes a failure at the line `self.env.ref(str_action)` due to the missing external ID. **Steps to reproduce:** * Install `crm` and `web_studio` * crm > Form View> Studio > `Add a button`> Run a server Action > Enrich * Settings > Technical > Actions > Server Actions > `Enrich` > Delete it * crm > Form View > Studio `ValueError: External ID not found in the system: crm_iap_enrich.action_enrich_mail` **Solution:** * Return `False` when the referenced server action cannot be found or has been removed. **Sentry-6608495874** Forward-Port-Of: odoo/enterprise#89218
The Planning app no longer shows the auto-plan option for shifts that do not yet have a start or end date. This prevents an error when users work with unscheduled shifts from sales orders, keeping the planning workflow stable.
Original PR description
**Step to reproduce:** 1. Install sale_planning module 2. Create a product (Sales -> Products): - Set Product Type to Service - Enable Plan Services - Assign both a Planning Role and resources. 3.…
**Step to reproduce:**
1. Install sale_planning module
2. Create a product (Sales -> Products):
- Set Product Type to Service
- Enable Plan Services
- Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.
**Issue:**
A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.
`AttributeError: 'bool' object has no attribute 'astimezone'`
**Cause:**
The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime.
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.
https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077
**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate
opw-4812509
co-authored by: Ajit Singh (aksi@odoo.com)
Forward-Port-Of: odoo/enterprise#89383Upsell orders for subscriptions now prevent users from changing the commission plan when the original order has Freeze Plan enabled. This avoids misleading changes that would not affect the actual commission purchase order, keeping expectations aligned with billing behavior.
Original PR description
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the…
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the Subscriptions and partner_commission modules. 2) Create a subscription SO with a referrer_id and set a recurrence. 3) Enable the Freeze Plan option and create a commission plan from the view 4) Add a rate of 50 and product category as service in the commission rules. 5) In SOL add a subscription product contains recurrence with unit price of 100 6) Confirm the SO → Create Invoice → Confirm → Pay. 7) Go back to the SO and create an upsell for it. 8) Change the commission plan rate to 30 by creating a new plan. 9)Repeat step 4. **Issue:** When you navigate to the referrer record from the SO and open the Purchase Order via the smart button, you will see two Purchase Order lines both showing a value of 50, even though the upsell order had a new commission plan with a rate of 30. **Cause:** When the invoice is marked as paid, a Purchase Order with POL is created using values from the commission plan. For subscription orders, the system intentionally uses the subscription’s original commission plan instead of the updated one. https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203 However, the problem is that the commission plan field remains editable in upsell SOs even when the parent SO has Freeze Plan enabled, misleading users into thinking the new commission plan will be applied. **Solution:** Make the commission plan field read-only for upsell SOs when the parent SO has Freeze Plan enabled. opw-4954307 Forward-Port-Of: odoo/enterprise#92157
The Journal Audit report no longer crashes if its underlying Journal Report has had all lines removed. Instead of showing an error, the system safely stops processing empty report data, helping accountants continue working without interruption.
Original PR description
Currently, error occurs when user try to open Journal Audit with no lines. Steps to replicate: - Install `accountant`. - Navigate to `Accountant > Configuration > Accounting reports`, search for `Journal Report` and open it. - Under the Lines tab, delete all the records and save. - Open the `Journal Audit` report, and the error will appear. Error: `IndexError: list index out of range` Cause: - An error occurred because the user deleted all the lines from the report, and the code tried to access the first element [1] of those lines (`lines[0]`) which caused the error. Solution: - Added a check if lines are present, if not then returned from the function. [1]: https://github.com/odoo/enterprise/blob/5670a73ef63d313f6c3df2b1ceeec7f7d6cd6a1b/account_reports/models/account_journal_report.py#L167 sentry-6795898305 Forward-Port-Of: odoo/enterprise#91979