Tuesday, August 19, 2025
23 changes · saas-18.2
Enhancements to existing features
This update improves internal documentation for tax helper functions used in accounting and point of sale code. It helps developers better understand which helpers are available in JavaScript versus Python, reducing confusion when maintaining or extending tax-related features.
Original PR description
Since some of them are copy pasted javascript side, adding such docstring is helping to distinguish what is available directly js-side from point_of_sale from what is only accessible python-side. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223258
Users now receive a warning when enabling WhatsApp debug mode, explaining that media files will stop being received while it is active. This helps prevent accidental disruption to WhatsApp media handling and makes the impact of the setting clearer before use.
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
Resolved issues and error corrections
This fixes an internal database configuration check so it correctly handles the current format used in this Odoo version. It helps prevent database connection or startup issues caused by the system reading the database name setting incorrectly.
Original PR description
A fix was introduced in https://github.com/odoo/odoo/pull/222805 to check config['db_name'], but this was replaced by a list in 18.2 and it was missed by the forwardport
Documentation and clarification updates
This update adds new members to the Adhoc Corporate Contributor License Agreement record. It keeps Odoo's contribution permissions and legal documentation current, with no product or user-facing impact.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223312
Miscellaneous changes
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
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#210835 Forward-Port-Of: odoo/odoo#203475
A test setup issue in the HR module has been corrected so employee JSON-related checks work in databases without demo data. This helps keep automated validation reliable across more deployment and build configurations.
Original PR description
Before this commit the test `test_webjson_employees` was failing in no demo builds as the json route only works in demo databases or when explicitly set. See https://github.com/odoo/odoo/pull/182196 This commit enables the system parameter, so that the test can be run as intended in no demo databases. Runbot Error: https://runbot.odoo.com/odoo/error/162907 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205580
This update stops an unnecessary warning from appearing in stock accounting by replacing use of a deprecated internal method. It helps keep system logs cleaner without changing day-to-day business workflows.
Original PR description
Before this commit a deprecated method is used and create a useless warning. 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#222148
The point of sale test setup now archives existing products instead of deleting them. This avoids failures caused by protected products such as gift cards, making automated checks more stable without changing customer-facing behavior.
Original PR description
### Before this commit: - The `test_load_pos_demo_data` test case was deleting all products, including special ones like `Gift card`, `default_booking_product`, leading to errors due to constraints on deleting such records. ### After this commit: - The test case now archives existing products instead of deleting them, avoiding these errors. Runbot Errors: 229904 & 229903 Task: 4974081
Attendance records created by absence detection now update their status when a manager corrects the check-in or check-out times. This prevents corrected attendances from staying highlighted as absences, making attendance lists clearer and more accurate.
Original PR description
### Steps to reproduce: - Run Absence detection cron - Navigate to the attendances got created in list view - Notice all of them are in red color - Modify the check in and check out dates to correct them as normal attendance - Notice the color didn't change in the view and it is still shows as red ### Cause: This is happening because color of the record is dependant on the check out mode, so if it is technical it means it is absence so we give it red color. https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/hr_attendance/models/hr_attendance.py#L84-L89 Also, the check out mode cannot be changed in any way. ### Fix: When updating the check out and check in time we check if the mode is technical we change it to manual. opw-4865524 Forward-Port-Of: odoo/odoo#218177
When sending an SMS from a chosen phone field, Odoo now keeps that selection even if the number is invalid instead of silently using the contact's partner phone number. This makes errors clearer for users and helps them correct the intended field directly, reducing the risk of messages going to an unexpected number.
Original PR description
If a user picks a specific field to open the composer with and that field is invalid we currently attempt to pick the number from the partner of the record as a fall back. Instead if the user picked a specific field and it happens to be invalid for some reason, they will want to correct it in-situ rather than have it be something completely different. Some similar tests are regrouped. task-4900210
The point of sale loyalty tests were adjusted so the intended customer consistently appears first in the customer list. This reduces random test failures and helps keep loyalty program behavior stable across updates.
Original PR description
This commit make sure that the partner is always at the top of the list opw-230704 Forward-Port-Of: odoo/odoo#223230
A renamed electronic invoicing field now updates correctly when related invoice data changes. This has little day-to-day impact because the field is not normally shown, but it prevents issues for businesses that expose it through customization tools like Studio.
Original PR description
In previous PR [1], we renamed field `ubl_xml_id` to `ubl_cii_xml_id`, but failed the compute dependencies. It has next to no impact since this field it not in views, but could lead to problems if people add it through Studio. [1]: https://github.com/odoo/odoo/pull/115627/files#diff-5f7f5f6e9c54527b31f7579db7ef63b5b910794e462cd3346e32387900c13efdR12 task-none Forward-Port-Of: odoo/odoo#223259
Fixes an error that could occur when a user removed a product from the parts list on a repair order and then changed the customer. This prevents an unexpected crash and keeps repair order updates working smoothly.
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#212577
A test now checks that the demo payment module is installed before using the demo payment provider. This prevents false test failures when only related website sales functionality is installed, improving reliability of quality checks without changing customer-facing behavior.
Original PR description
Add module installation check before using "demo" as payment provider to generate payment token for payment register test case. Steps to reproduce: 1. Install single module (website_sale). 2. Run test case `TestAccountPaymentRegister.test_register_payment_doesnt_send_email`. You will get ValueError: Invalid field 'demo_simulated_state' on model 'payment.token' build_error-230731 Forward-Port-Of: odoo/odoo#222330
Fixed an issue where running a WhatsApp marketing automation test more than once could trigger an error and interrupt the workflow. The automation now handles each related tracking record individually, making repeated test runs reliable for users setting up campaigns.
Original PR description
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration *…
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration * Marketing Automation > New > Start From Scratch > Add a new activity * Select Activity Type as Whatsapp Message and a Whatsapp Template * Launch a Test > Pick a contact > Launch > Run (Do this step twice) **Error:** `ValueError: Expected singleton: marketing.trace(6, 4, 3, 2, 1)` **Cause:** This error occurs because the variable `trace` contains multiple records, but the `process_event` method is being called on the entire recordset. Since `process_event` uses `self.ensure_one()`, it expects exactly one record, and therefore raises an error at [1] when multiple records are passed. **Solution:** * Handle trace records one by one using a loop. [1]: https://github.com/odoo/enterprise/blob/624b18bdb5dff0df4756c4e1d37a696631e57a05/marketing_automation_whatsapp/models/marketing_trace.py#L20 **Sentry-6772553612** Forward-Port-Of: odoo/enterprise#91207
WhatsApp template previews no longer mistake underscores inside URLs or link tokens for italic formatting. This keeps generated message previews accurate when links include values such as access tokens, reducing confusion before messages are sent.
Original PR description
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current…
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current regex, we will apply italic to any underscore we find which is not ideal, mostly when we work with URLs that can contain underscores like "acces_token" which we will try to apply italic to it too. Solution: Following the most common logic for italic formatting, we will only apply italic formatting when the underscore is surrounded by whitespace. This is the same way it already behaves in Whatsapp. If we write it like_this_for example, it will not apply italic formatting, but if we write it like this _this_ it will apply italic formatting. So this for example: **"If we write it like_this_for example"** Will be like - before the fix: **"If we write it like<i>this</i>for example"** Will be like - after the fix: **"If we write it like_this_for example"** opw-4720017 Forward-Port-Of: odoo/enterprise#91217
Odoo now avoids showing an incorrect message that a payment was removed from a batch when validating certain batch payments. This keeps the payment history clearer and prevents users from being misled about whether a payment stayed in its batch.
Original PR description
When validating a batch that includes payments in process (e.g., without journal entries), Odoo incorrectly logs that the payment was removed from the batch, even though it remains. This commit fixes the chatter message by not possessing the write method of the account_payment if batch_payment_id not in vals. task-5011672 Forward-Port-Of: odoo/enterprise#92197
Dutch VAT payment wizards now use the Omzetbelastingnummer when it is available, instead of always using the company VAT number. This ensures the payment communication/reference is generated correctly for Dutch tax payments, reducing manual corrections and payment processing errors.
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 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. opw-4836615 Forward-Port-Of: odoo/enterprise#92407
This update fixes how the India GST report determines the month and year for a return period. It helps ensure GST reporting periods are shown accurately, reducing the risk of confusion or incorrect filing preparation.
Original PR description
Backport of commit: https://github.com/odoo/enterprise/commit/eda621c07393ad8e897503c852a9b00480affc52 Forward-Port-Of: odoo/enterprise#92555 Forward-Port-Of: odoo/enterprise#92499
The Kenya e-invoicing product search now correctly supports searching by KRA item code. This prevents errors when users search products by this field and makes the existing search option usable.
Original PR description
This commit odoo/enterprise@c17ebfc7cdf2b218945280e6e3bd09f2b9ee8adc added a [searchview](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu/views/product_views.xml#L74-L84) for `l10n_ke_item_code` but it never worked. as `l10n_ke_item_code` in `product.template` is non-stored field, we generally get error in console about it. fast forward to newer version e.g. saas-18.3, searching on non-stored fields raises traceback on frontend. Step to reproduce: - install L10N_ke and sale_management - switch to kenya company - go to product in sales app - type something in search bar and select 'kra item code' from autocomplete Observation: - nothing happens on frontend - on backend we receive a error `ERROR odoo.osv.expression: Non-stored field product.template.l10n_ke_item_code cannot be searched.` Fix: - we introduce a search method for l10n_ke_item_code field opw-4985176 Forward-Port-Of: odoo/enterprise#91526
Adding a column to a customized report table now uses a layout element that does not add unwanted spacing. This prevents table alignment issues and helps reports keep a cleaner, more consistent appearance.
Original PR description
Before this commit when adding a column into a modified qweb table (q-table node) we inserte a `p` as the cell's first child. This was problematic as a margin was always present, messing with the whole table alignment. After this commit, we put a simple DIV. task-5005441 Forward-Port-Of: odoo/enterprise#92085
Upsell orders for subscriptions now prevent changing the commission plan when the original order has Freeze Plan enabled. This avoids confusing users with edits that would not affect the final commission purchase order, keeping the displayed options aligned with actual 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
When an applicant is hired through the salary configurator, their listed skills are now transferred to the new employee record. This prevents HR teams from losing useful candidate information during onboarding and keeps employee profiles more complete.
Original PR description
Originally, an applicant, who became an employee through the salary configurator flow, loses his skill info. So, the migration of applicant information, through the salary configurator flow, to employee view has been adjusted. Forward-Port-Of: odoo/enterprise#87076