Wednesday, August 20, 2025
22 changes · master
Enhancements to existing features
Users are now warned when enabling WhatsApp debug mode that media files will stop being received. This helps prevent accidental disruption to WhatsApp media handling by making the impact clear before the setting is used.
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
Signer labels in Sign templates now stay in sequence when people are added or removed. This avoids confusing gaps like “Signer 1, Signer 2, Signer 4” while preserving any custom names users have entered.
Original PR description
Currently, the sidebar of a sign template has an internal id which starts at 0 and is used as an id when you make an orm call to create a new sign.role.item record (a signer on the template). Until…
Currently, the sidebar of a sign template has an internal id which starts at 0 and is used as an id when you make an orm call to create a new sign.role.item record (a signer on the template). Until now, the id is also used to create the name of the signer, as "Signer {id}" but this is problematic if you eliminate signers and then create new ones because it leaves holes in the signer naming. The solution is to always use the length of the array containing the currently assigned signers as the number to insert into the name, since the new signer is always added at the end. Furthermore, when a signer is deleted, we should compute the names of the remaining signers to match their position in the array containing the assigned signers.
For example, if we create 4 signers, Signer {1,2,3,4} and then delete Signer 3, we would like Signer 4 to be renamed Signer 3, since the next added signer will be named Signer 4 according to the length of the array containing them. A small caveat is that we don't want to rename already renamed Signers, because we don't want to lose personalization.
This is the objective of this PR.
Task: 4985491Point of Sale and related country-specific POS modules now produce clearer diagnostic logs with added context such as where messages come from, variable details, and call traces. This helps support and development teams investigate POS issues faster without changing normal cashier workflows.
Original PR description
*: l10n_de_pos_cert, l10n_de_pos_res_cert, l10n_it_pos, pos_enterprise, pos_iot, pos_mobile Improve console logging in the Point of Sale and related modules. By using the `logPosMessage` utility…
*: l10n_de_pos_cert, l10n_de_pos_res_cert, l10n_it_pos, pos_enterprise, pos_iot, pos_mobile Improve console logging in the Point of Sale and related modules. By using the `logPosMessage` utility function more informations are now included in the console logs, such as the module name, function name, and a message. This makes it easier to track down issues and understand the flow of the application. Also when unfolding the console logs, some additional context is provided: - Variable values (if given to the console method) - Call stack trace (if available) ## Example of a log message: [IndexedDB]: put - Processing 40 items in store pos.order.line ### With its call stack: logPosMessage @ pretty_console_log.js:13 (anonymous) @ indexed_db.js:113 promises @ indexed_db.js:92 create @ indexed_db.js:193 synchronizeLocalDataInIndexedDB @ data_service.js:182 ..... ## Screenshots: <img width="779" height="764" alt="image" src="https://github.com/user-attachments/assets/6be024e4-e849-478b-9cdd-653300fc015a" /> https://github.com/user-attachments/assets/2342ca52-719c-4368-94e6-1e692faf12e0 Forward-Port-Of: odoo/enterprise#92544 Forward-Port-Of: odoo/enterprise#92021
This update streamlines how WhatsApp and live chat participant information is handled behind the scenes. It reduces unnecessary complexity, helping keep messaging features easier to maintain without changing the day-to-day user experience.
Original PR description
This commit reduces the usage of persona for the channel member model, unless we need to support guest and partner, the use of persona should be avoided. Follow up on task-4675777 PR community: https://github.com/odoo/odoo/pull/220063
The automated tests for rental and subscription combo product flows were updated to match the redesigned combo selection window. This helps keep checkout quality checks reliable after the interface change, reducing the risk of unnoticed issues in these sales flows.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/222337 task-4981539
The VoIP call list now shows the most recent calls at the top by default. This makes it easier for users to quickly review the latest activity without manually sorting the list.
The French VAT report submission wizard now includes an express mention option for reports sent through the Aspone service. This helps businesses correctly flag expedited submissions in the required report section.
Original PR description
This commit adds express mention in the wizard to send the tax report to aspone api. The express mention will be added in the zone BC of the tax report. Task-4933083
Resolved issues and error corrections
This update keeps the Belgian point of sale certification module compatible with the latest Odoo version by replacing an outdated internal component. It helps prevent errors in POS category handling after upgrading to version 19.0.
Original PR description
Starting from 19.0, odoo.osv is depreciated, so we need to use odoo.fields.Domain instead. [Runbot-230364](https://runbot.odoo.com/odoo/error/230364)
Code cleanup and technical improvements
This update improves how report template errors are captured and explained, making it easier to identify where a problem occurred. It is mainly an internal quality improvement that should help teams diagnose and resolve report issues faster.
The Journal Audit report no longer crashes when its underlying Journal Report has had all lines removed. Instead of showing an error, the system safely stops processing empty report data, improving reliability for accounting users.
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
The Sign button is now hidden once a document has been fully signed from the chatter. This avoids confusion for users by removing an action that is no longer needed after signing is complete.
Original PR description
Before this fix, even after a user signed a document from the chatter and The document was fully signed, and the Sign button was still visible. In this PR, the button is hidden once the document is fully signed. Forward-Port-Of: odoo/enterprise#92597
The Swiss payroll wage type view no longer shows the discussion panel after messaging support was removed from the related record. This prevents users from seeing a non-working or irrelevant communication area, keeping the screen clearer and avoiding confusion.
Original PR description
After mail thread was removed from the model, the chatter is still present in the view and should be removed Forward-Port-Of: odoo/enterprise#92316
This change adjusts an internal test so it stays aligned with a recent spreadsheet component update. It helps keep automated quality checks reliable without changing the user-facing document spreadsheet experience.
This update fixes an internal accounting test so it automatically uses the correct year when checking payment references. This helps keep the test suite stable over time and avoids avoidable build failures when dates change.
Original PR description
In `test_matching_rules_with_empty_aml_move_name`, the payment `move_id.name` was hard-coded to use the year "25" in the sequence prefix (e.g. MOVE25/00004). This caused ValidationErrors when the mocked posting date in the test environment belonged to a different year, as the sequence mixin enforces alignment between the move date and sequence year. The test now derives the year suffix dynamically from the actual `move_id.date` to ensure it always matches the posting date used in the test context. This makes the test stable regardless of the current (or mocked) date, removing the need for manual adjustments when fiscal years or test setup dates change. build_error-230659 Forward-Port-Of: odoo/enterprise#92080
The Planning app now validates shift template start and end hours before creating the display name. This prevents a system error when users enter an invalid hour, replacing it with a proper validation message so the form can be corrected safely.
Original PR description
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and…
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and enter an `invalid end hour (greater than or equal to 24)` > `save`. `ValueError: hour must be in 0..23` This error occurs after [this commit](https://github.com/odoo/enterprise/commit/a0bb61f5871fe02a0a32691f33dabfb06c9d2ce2), which added the _get_name method to generate the display name without validating the data.when a user enter invalid value in the end hour while creating or editing shift template. The compute method is then triggered, which attempts to generate the display name [1] based on the formatted time. During the formatting of the end time, the hour value is invalid for the time function,and raise the error [2]. This commit ensures that if the start hour or end hour is invalid, it raises a validation error, similar to [this commit](https://github.com/odoo/enterprise/pull/67580/commits/fa566f9de1b8f75510cbc01837fb3ff4764eccdf). [1]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L54 [2]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L74-L78 sentry-6792658060 Forward-Port-Of: odoo/enterprise#91779
The Knowledge and Helpdesk Knowledge test tours were adjusted to match updated media dialog behavior from a related accessibility improvement. This helps keep automated checks reliable and reduces the risk of regressions in article editing and file block workflows.
Original PR description
This commit is linked to the [MediaDialog accessibility improvement PR] in community. [MediaDialog accessibility improvement PR]: https://github.com/odoo/odoo/pull/220737 task-3680626
The Planning app now hides the auto-plan option when a shift has no start or end date. This prevents users from triggering an error while working with unscheduled shifts created from sales orders.
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#89383A small cleanup removes an unused internal parameter in the Belgian POS blackbox module. This reduces confusion in the code without changing how users work with the point of sale.
Original PR description
An unnecessary parameter has been added and mistakenly not removed. This commit removes it. Forward-Port-Of: odoo/enterprise#92554
Upsell orders for subscriptions now prevent changes to the commission plan when the original order has Freeze Plan enabled. This avoids misleading sales users into choosing a new plan that would not be used for the resulting commission purchase order.
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#92217 Forward-Port-Of: odoo/enterprise#92157
AI prompt field selection now avoids showing unnecessary separators when inserting properties. Boolean fields also correctly treat False as a valid value, preventing misleading warnings for users.
Original PR description
Bug === The `False` value is a valid value for boolean type, and the warning should not be displayed for that type. When inserting properties in an AI prompt, the property separator should not be visible. Task-4896271 Forward-Port-Of: odoo/enterprise#92699 Forward-Port-Of: odoo/enterprise#88483
Dutch VAT payment instructions now use the Omzetbelastingnummer when it is available, instead of always relying on the company VAT number. This ensures the payment communication shown to users matches Dutch tax reporting requirements and reduces the risk of incorrect tax payment references.
Original PR description
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an…
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - 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#92691 Forward-Port-Of: odoo/enterprise#92407
This fixes an internal test setup issue for Australian payroll accounting by giving the test user the access rights needed for accounting and HR records. It helps ensure automated checks run reliably without affecting day-to-day users.
Original PR description
[FIX] l10n_au_hr_payroll_account: missing groups The common test file is accessing models in account and hr modules but the user miss groups to have access to them. runbot-230965