Daily updates from Odoo
Thursday, September 25, 2025
145 changes
23 changes
Resolved issues and error corrections
When an Indian purchase bill is reset to draft, its GSTR-2B reconciliation is now returned to a pending state, disconnected from the GST return period, and cleared of prior exceptions. This helps finance teams reprocess changed bills cleanly and avoid stale reconciliation information.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95251 Forward-Port-Of: odoo/enterprise#95026
Opening a Knowledge activity now shows only the articles linked to that activity instead of the full article list. This helps users quickly find the relevant Knowledge article that needs their attention.
Original PR description
Currently, when the user tries to open any activity of the knowledge article, it opens all articles instead of the one which has an activity assigned to them. **Steps to reproduce this issue:** 1) Install the Knowledge module 2) Set up an activity for yourself on a Knowledge article 3) Open the activities from Activities (top left corner) **Issue:** You will end up in the all articles list, with no filters applied. **Cause:** When the user clicks on the activities, a default search filter is added in the context, which is then applied on the view. But in the knowledge article, we don't have any search filters for the activities. Therefore, it renders all knowledge article records. **Solution:** Add search filters for the knowledge articles. opw-4997201 Forward-Port-Of: odoo/enterprise#93609
General Ledger PDF footers now allow longer company names, so businesses with names over 24 characters will see their full name instead of a truncated version. The footer spacing was also increased to keep the report layout clean when longer names are printed.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972 Forward-Port-Of: odoo/enterprise#94535
Users can no longer try to send a WhatsApp message without choosing a template. This prevents an error and gives a clearer, safer sending flow for customer communications.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898
Odoo now accepts Taiwan business VAT numbers under the country’s revised validation rules. This prevents valid newly issued Taiwanese company numbers from being incorrectly rejected when entered on customer or vendor records.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228385 Forward-Port-Of: odoo/odoo#225468
This fix prevents validation errors when editing the address of a Czech company that was installed with demo data. It aligns demo invoice dates with the required tax supply dates so accounting references remain consistent and users can save company details normally.
Original PR description
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo…
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo data throws Validation Error #### Current behavior before PR: When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce: - Install l10n_cz with demo data - Open CZ Company in form view - Change address (e.g. change city Praha -> Brno) - Click Save #### Desired behavior after PR is merged: The address changes are saved without any error. #### Solution: This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin. Related to: #226152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228157 Forward-Port-Of: odoo/odoo#227847
The bank reconciliation search dialog no longer triggers a crash when users tap the reconcile button on mobile devices. The custom reconciliation behavior is now limited to desktop views, where it is properly supported, improving reliability for mobile users.
Original PR description
When clicking on the reconcile button in mobile, the js_class of the custom list view is never triggered because, in small screens (aka. "mobile"), by default, kanban views are used instead of list views (or at least take precedence). To avoid having a traceback, we will keep the custom behavior in desktop only no task id Forward-Port-Of: odoo/enterprise#95145
This fixes automated online shop tour tests so browser redirect warnings no longer interrupt or delay them. It helps keep test runs reliable by allowing page reloads to complete smoothly and updates a few test selectors for better accuracy.
Original PR description
During page redirection in tours, the browser was showing a warning about unsaved/incomplete data loss. This warning is not relevant in the context of tours. To address this, the expectUnloadPage attribute is added to the tour test. It prevents unnecessary pauses/timeouts caused by the browser’s warning and ensures smooth redirection handling. Additionally, few tour selectors have been corrected to improved. runbot-231587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users with approval rights can now view timesheets on private-project tasks they follow, matching their existing task access. This prevents missing timesheet information in task views and reports for authorized approvers.
Original PR description
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security…
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access. https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117 **Steps to reproduce:** 1. Create a private project (`privacy_visibility == 'followers'`) 2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access 3. Add Marc Demo as a follower of a task in that private project 4. Have another user log time on that task 5. Log in as Marc Demo Marc cannot see the other user's timesheets, neither on the task form nor in reporting. opw-5022877 Forward-Port-Of: odoo/odoo#224025
This fixes an internal Inventory configuration issue by restoring a missing database index on stock rules by company. It helps upgrades run with clearer logs and avoids misleading warnings, with no expected change to day-to-day user workflows.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226268
This fixes an issue where some users could see an empty employee list in manufacturing work orders because employee avatar access was blocked by HR permissions. The change hides that avatar field for users without the necessary HR access so the list can load normally.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group. Forward-Port-Of: odoo/enterprise#95424
Scheduled account report sends now skip partners that were deleted after the send was prepared. This prevents the automatic job from failing and helps ensure remaining reports continue to be processed reliably.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571 Forward-Port-Of: odoo/enterprise#95127
Fixes an issue where website forms configured to send an email could fail when submitted after selecting the outgoing mail option in Studio. This helps ensure visitors can submit contact or email forms without triggering backend errors.
Original PR description
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > Click on `Edit` > `Drag and drop` form. -…
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > Click on `Edit` > `Drag and drop` form. - click the form and in actions select the `more models`, and select `outgoing mails(mail.mail)` model and `save`. - Submit the form, and the error appears in the logs. `KeyError: 'website_form_signature'` This error occurs when submitting the "Send Email" form from the website. When the user chooses the model Outgoing Mails (mail.mail), the email_to hidden field is not added. This is because email_to is only added when the recipient email value is changed from the sidebar via apply [1]. As a result, the email_to hidden field is missing from the form. And the website_form_signature is added from [2], but due to the condition at [3], the code at [2] is not executed. When it is accessed at [4], KeyError is raised. This commit ensures that when the user selects the action model, if there is a hidden field email_to, it is added to the form with its default value. [1]: https://github.com/odoo/odoo/blob/3b16debc6d6557334082fdf841b20ef0e31fc9d2/addons/website/static/src/builder/plugins/form/form_option_plugin.js#L863 [2]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252 [3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236 [4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88 Related Community PR: https://github.com/odoo/odoo/pull/226598 sentry-6746753251
This fix ensures Turkish Nilvera e-invoice files are recognized with the correct file type during import. As a result, imported invoice records can be decoded properly instead of being left empty.
Original PR description
The imported records are not being decoded correctly due to _get_edi_decoder returning an empty value. This happens because the value of import_file_type for UBL.TR is incorrectly returned as TR by _get_import_file_type. As a result, the decoder cannot be found, and the records are left empty. task-4714467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The kiosk online payment page now shows its background only once. This removes a duplicated visual layer on the QR code payment screen, making the checkout experience cleaner for customers.
Original PR description
pos_online_* = pos_online_payment_self_order This commit ensures that only one background is displayed on the kiosk online payment page. The background is correctly displayed in 'pos_self_order.PaymentPage', and it should not be displayed again in the “Scan the QR code to pay” subcomponent. <img width="688" height="485" alt="Screenshot 2025-09-24 at 13 49 00" src="https://github.com/user-attachments/assets/e521ffce-82db-4900-828a-5d086fa9b4ac" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes editing website snippets with icons behave more predictably by preventing unwanted selections and toolbar actions. It reduces confusing highlights and error messages when users click social media, share, or rating icons in the website editor.
Original PR description
Backport of https://github.com/odoo/odoo/pull/227520.
This update prevents validation errors when users log timesheets on Helpdesk tickets linked to projects without a company set. It ensures the correct company information is preserved, helping multi-company users create timesheets reliably during normal use and migrations.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
This fix ensures timesheet reports correctly include helpdesk ticket information when it should be shown. It corrects a prior update that did not properly target the report field, helping users see complete ticket context in exported or printed timesheet reports.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Resetting a user's Odoo Calendar no longer fails because of permission checks on events they cannot edit. This prevents an unnecessary error during calendar cleanup and makes the Google Calendar reset process smoother for users.
Original PR description
Before this commit, when resetting the Odoo Calendar of an user, it would trigger a ValidationError for updating events that the current user wasn't able to update, even though it was not an updated per se, but just a deletion of it in Odoo. After this commit, we no longer trigger that ValidationError during resets of Odoo Calendars, fixing the error. task-5103918 Forward-Port-Of: odoo/odoo#228195 Forward-Port-Of: odoo/odoo#227991
Point of Sale now shows the optional product popup when a cashier scans a product barcode, matching the behavior already available when selecting a product on screen. This helps ensure add-on or related product offers are not missed during faster barcode-based checkout flows.
Original PR description
Before this commit, the optional product popup was only displayed when adding a product by clicking on it. When the product was added through barcode scanning, the popup did not appear. This commit ensures that the optional product popup is consistently shown both when clicking on a product and when scanning its barcode. opw-5089175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227656
Public holidays now create timesheet entries using each employee’s flexible working schedule instead of the company default. This prevents incorrect 8-hour time off entries when an employee’s configured average day is different, improving payroll and timesheet accuracy.
Original PR description
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible…
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule ## Cause: When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()` This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end) These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed: https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393 We want to use the calendar itself as the calendar resource to get the `work_hours_data` ## Steps to reproduce: - On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week - Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6) - In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values) - Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off opw-4881758 Forward-Port-Of: odoo/odoo#225876
This fixes an issue where customers could hit an access error when creating an invoice from a Point of Sale QR code in multi-company setups. Businesses using branch companies with shared sales journals can now complete self-service invoicing more reliably.
Original PR description
Before this commit, in a multi-company setup, an access error could occur when generating an invoice from a QR code. Steps to reproduce: 1. Create a parent company and a branch company. 2. Create a PoS in the branch company and assign a sales journal from the parent company. 3. Create a product assigned to the branch company. 4. Enable Self Service invoicing in the PoS settings. 5. Create an order in the PoS and then try to create an invoice with the QR code. Result: an access error was raised. opw-5050536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225483
This change speeds up installation and updates for the Danish Nemhandel module by preparing partner-related Nemhandel information during setup. It helps avoid long delays caused by recalculating these details later, improving reliability during module installation or upgrades.
Original PR description
To avoid lengthy update due to the compute of the records by the ORM, let's pre-compute the nemhandel fields on the install of the module. 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#228102
11 changes
Resolved issues and error corrections
Odoo now accepts Taiwan business VAT numbers under the country's revised validation rules. This prevents valid newly issued numbers from being incorrectly rejected when customers or companies enter their tax details.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228324 Forward-Port-Of: odoo/odoo#225468
Purchase bills that are moved back to Draft now have their GSTR-2B reconciliation details reset. This prevents old return-period links or exceptions from carrying over, helping teams reconcile GST data accurately when the bill is reviewed again.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95251 Forward-Port-Of: odoo/enterprise#95026
General Ledger PDF reports now show longer company names in the footer without cutting them off. The footer spacing was also adjusted so reports remain readable and professionally formatted when company names are longer.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972 Forward-Port-Of: odoo/enterprise#94535
The WhatsApp message flow now prevents users from sending a message unless a template is selected. This avoids an unexpected error and gives users a clearer, more reliable experience when contacting customers through WhatsApp.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898
Fixed an issue where some users could see an empty employee list in manufacturing work orders because an employee avatar field triggered HR access restrictions. The avatar is now limited for users without HR permissions, preventing the list from failing to load.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group. Forward-Port-Of: odoo/enterprise#95424
Scheduled account report emails now skip partners that were deleted after being selected for batch sending. This prevents the automatic report-sending job from failing and helps ensure remaining customer statements continue to be processed.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571 Forward-Port-Of: odoo/enterprise#95127
This fix restores a missing database setting for stock rules linked to companies. It prevents misleading upgrade messages and helps keep inventory-related upgrades cleaner and more reliable.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226268
The livechat widget now respects the configured delay before opening automatically. This prevents chats or chatbots from appearing immediately when a business has chosen to wait before engaging visitors.
Original PR description
### Issue: The livechat delay doesn't work as expected. #### To reproduce: 1- Create a livechat channel 2- In channel rules, set these rules: - Live Chat Button: Open automatically - Enable ChatBot: Always - Open automatically: 20 3- In widget tab, you can find channel URL, open it. 4- We expect it opens after 20s but it opens immediately ### Cause: This issue is caused during refactoring: https://github.com/odoo/odoo/commit/6d903ccd0ad48fc8f58094b45f01656b1d47acfe https://github.com/odoo/odoo/blob/6d903ccd0ad48fc8f58094b45f01656b1d47acfe/addons/im_livechat/static/src/embed/common/autopopup_service.js#L21-L27 Here storeService promise is not ready yet but we are trying to use `storeService.livechat_rule?.auto_popup_timer` which is `Nan`, as a result the timeout will be 0, opening it without delay. opw-4988003
This fix ensures timesheet reports correctly include helpdesk ticket information when relevant. It corrects a prior report update that did not apply properly, helping users see complete ticket-related timesheet details.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
This fixes a problem where users with employees in multiple companies could be blocked from adding timesheets on Helpdesk tickets when the linked project had no company set. The change preserves the correct company during timesheet creation, reducing validation errors during daily work and migrations.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
The online store now handles product option combinations that are not actually available when shoppers use pickup in store. This prevents error screens and stops the pickup location selector from opening when no valid product exists.
Original PR description
Steps to reproduce: 1. Configure 'pick up in store' delivery method 2. Open the page of the product with an impossible combination (e.g. Customizable desk) 3. Edit the url to have attribute values of the impossible combination (2,5) There is a traceback as there is no `inStoreStockData`. After fixing it, the widget was still clickable, but as there was no product, there was another traceback since the data was not present. After this commit, the location selector is prevented from being opened when the combitation is not possible.
5 changes
Resolved issues and error corrections
General Ledger PDF reports now display longer company names in the footer instead of cutting them off. This improves report presentation for businesses with company names longer than 24 characters, with added spacing to keep the footer readable.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972 Forward-Port-Of: odoo/enterprise#94535
Fixed an issue that could cause the Brazilian electronic invoicing flow to fail when users confirmed several invoices at the same time. This helps teams process invoice batches more reliably and avoid interruptions in daily billing operations.
Original PR description
opw-5107516
Users can no longer try to send a WhatsApp message after removing the required template. This avoids an unexpected error and gives a clearer validation path, improving reliability when sending WhatsApp messages from contacts.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898
The manufacturing work order employee list could appear empty for users without certain HR permissions because an employee avatar field triggered an access error. The update limits use of that avatar field for users who do not have HR user rights, helping affected staff see the expected list again.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group. Forward-Port-Of: odoo/enterprise#95424
Scheduled account report emails now skip customers that were deleted after being selected for batch sending. This prevents the automated send job from failing and helps ensure remaining customer statements are still processed smoothly.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571 Forward-Port-Of: odoo/enterprise#95127
19 changes
Resolved issues and error corrections
The bank reconciliation action now avoids using desktop-only behavior on mobile screens, where a different view is shown. This prevents users from seeing an error when tapping the reconcile button on phones or small screens.
Original PR description
When clicking on the reconcile button in mobile, the js_class of the custom list view is never triggered because, in small screens (aka. "mobile"), by default, kanban views are used instead of list views (or at least take precedence). To avoid having a traceback, we will keep the custom behavior in desktop only no task id Forward-Port-Of: odoo/enterprise#95145
Users without HR permissions could see an empty employee list because an employee photo field triggered an access error. The view now limits that photo field for those users, keeping the work order employee list usable until the underlying HR issue is resolved.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group. Forward-Port-Of: odoo/enterprise#95424
General Ledger PDF reports now show longer company names in the footer instead of cutting them off after a short limit. The footer spacing was also adjusted so the longer name fits cleanly on printed reports, improving document presentation for companies with longer legal names.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972 Forward-Port-Of: odoo/enterprise#94535
Czech VAT control statements now place invoices without a partner VAT number in section A5 regardless of amount. Special VAT regime entries for travel services and margin schemes are also consistently reported in A5, helping businesses avoid incorrect VAT classifications.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787 Forward-Port-Of: odoo/enterprise#92833
The audit balances view now shows cumulative balances, including amounts from previous periods and unaffected earnings. This gives finance teams a more accurate view of balances for audit and reporting work.
Original PR description
The audit balances view should accumulate the balances from previous periods. Before it only computed the balance for the current period. It also take into account the unaffected earnings. Forward-Port-Of: odoo/enterprise#94634
This fixes a situation where an IoT Box action could run twice if the first connection method timed out and a fallback connection retried the same request. Each action now carries a unique identifier so repeated fallback requests can be recognized and ignored, reducing risks like duplicate prints or registrations.
Original PR description
Community PR: odoo/odoo#225678 In the following case an IoT box action can be duplicated: 1. Request is sent over longpolling 2. Action takes longer than 6s to execute, longpolling times out on the client side 3. Websocket request is sent as a fallback 4. Both requests cause an action to be executed (double blackbox registration, double print, etc.) To solve this we will send an ID with every action, and if the ID has already been recently seen we will ignore the action and log a warning. This PR handles the client side code, which just involves adding the new `action_unique_id` key to all our actions that are using fallbacks. task-5067737 Forward-Port-Of: odoo/enterprise#94031 Forward-Port-Of: odoo/enterprise#93985
This fixes an issue where Sign templates created from records such as sales orders did not use the original document to choose which fields could be added. Users can now drag and drop the expected fields for that document, while templates are protected from combining incompatible fields from different document types.
Original PR description
Before this commit, when a new template was created from a mail thread record, the reference doc was not used to filter out the fields to display. it would prevent to drag and drop sale.order fields even if the template was created from the sale application. task-5085468 Forward-Port-Of: odoo/enterprise#94591
Scheduled account report emails no longer fail when a partner included in a pending batch has been deleted before processing. The system now keeps only existing partners in the batch, helping automatic statement delivery continue reliably.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571 Forward-Port-Of: odoo/enterprise#95127
The Indian GSTR-1 document summary now keeps existing generated data instead of recreating it each time the summary card is opened. This prevents accidental data loss, avoids unnecessary processing, and removes an incorrect “Missing” status when summary data is already available.
Original PR description
Issue: - Document summary was regenerated every time the user clicked on the document summary card. - This caused data loss for already existing summaries and unnecessary restart of the process. - 'Missing' tag appeared in document summary even when data was present. - Additionally, record_name was passed in _check_suite_in_gstr1_report, but as a computed field it never worked as intended. Fix: - Adjusted logic so the document summary is generated only when empty. - Subsequent clicks now reuse the existing summary instead of regenerating it. - No missing tag appears if document summary exists. - Replaced record_name with record_model to ensure correct record count and computed record name. Forward-Port-Of: odoo/enterprise#94447
This fixes an issue where users working across multiple companies could be blocked from creating Helpdesk timesheets when the linked project had no company set. The change preserves the correct company during timesheet creation, helping avoid validation errors in daily support and migration workflows.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
This fix restores one-time payment options in Swiss payroll and hides salary attachment items that should not be available. It helps payroll users access the correct payment actions while reducing confusion from unsupported or unwanted menu entries.
Original PR description
- Reintroduce one time payments - Blacklist salary attachments Forward-Port-Of: odoo/enterprise#95438
This fix ensures helpdesk tickets appear correctly in timesheet reports when they should. It corrects a previous report update that did not target the existing report field properly, helping users see complete ticket-related time information.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Customers buying subscriptions through the e-commerce checkout are now informed that their payment details will be saved for automatic renewals. This aligns the online shop experience with the portal flow and improves transparency around recurring payments.
Original PR description
Before this commit, when the customers paid a subscription on the portal, they would get the following information: Your payment details will be saved for automatic renewals. When they would pay on the e-commerce, the token would be saved but they would not be notified. task 4808806
The mobile Point of Sale payment screen now correctly keeps the Validate button disabled when no payment method is selected. This helps prevent incomplete payments from being confirmed by mistake and improves consistency between mobile and desktop checkout flows.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. community PR: https://github.com/odoo/odoo/pull/225917 task-id: 5072759 Forward-Port-Of: odoo/enterprise#95357 Forward-Port-Of: odoo/enterprise#94100
Point of Sale receipts are now sent to the receipt printer selected in the POS setup, even when other printers are also connected. This prevents customer receipts from accidentally printing on kitchen or preparation printers, reducing confusion during checkout.
Original PR description
Steps to reproduce: 1. Configure a POS with a receipt printer and a preparation printer. 2. Ensure that the preparation printer has a higher ID than the receipt printer (you can force this by deleting it and letting the IoT redetect it.) 3. Try to print a receipt. EXPECTED: The receipt is printed on the configured receipt printer. ACTUAL: The receipt is printed on the prepation printer. This was caused by the hardware proxy code assuming that there will only be 1 printer `iot.device` model loaded, and that it will correspond to the receipt printer. The fix is to ensure the hardware proxy only chooses the printer that is configured as the receipt printer. Forward-Port-Of: odoo/enterprise#93225
This fix ensures that using the left and right arrow keys inside a dropdown does not accidentally trigger actions elsewhere in the interface. It makes keyboard navigation more predictable and prevents unexpected UI changes while users are selecting dropdown options.
Original PR description
This commit prevents arrowleft and arrowright hotkeys to trigger on other parts of the UI when navigating a dropdown. Community: https://github.com/odoo/odoo/pull/226604 Task: [5048895](https://www.odoo.com/odoo/project.task/5048895) Forward-Port-Of: odoo/enterprise#94478
Quality checks now use the unit of measure entered on the receipt line when it differs from the product default. This helps teams review inspections with the correct operational quantity and avoids confusion during receiving.
Original PR description
Steps to reproduce: - Create a storable product “P1” with UoM = Unit - Create a quality point: - Control per: Quantity - Operation type: Receipt - Product: P1 - Create a receipt of 1 unit of P1 - Mark as "To Do" - Open the detailed operations (SML) and update the UoM to Dozen - Go to the quality check Issue: The UoM of the quality check is still "Unit" instead of "Dozen", because the field was related to `product_id.uom_id`. Fix: Compute the UoM from the stock move line if available, otherwise fall back to the product's default UoM. opw-5080657
Purchase bills that are reset to Draft now return to their initial GSTR-2B reconciliation state. This prevents old GST return links or exception flags from carrying over, helping teams reconcile corrected bills accurately.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95471 Forward-Port-Of: odoo/enterprise#95026
Users can no longer try to send a WhatsApp message without selecting a template. This prevents an application error and guides users to complete the required message setup before sending.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898
28 changes
Resolved issues and error corrections
General Ledger PDF footers now allow longer company names, preventing them from being cut off when reports are printed. The footer spacing was also increased so longer names display cleanly without crowding the page.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972 Forward-Port-Of: odoo/enterprise#94535
This update prevents an employee list from appearing empty for users who do not have HR permissions. It avoids loading an employee avatar field that can trigger an access error, helping manufacturing users keep working without disruption.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group. Forward-Port-Of: odoo/enterprise#95424
Users can no longer try to send a WhatsApp message without selecting a template, preventing an error that interrupted the sending process. This makes the WhatsApp messaging flow clearer and more reliable for users.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898
Odoo now validates Taiwanese business VAT numbers using the latest official checksum rule. This prevents valid newer Taiwan UBNs from being incorrectly rejected as the available number range expands.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228385 Forward-Port-Of: odoo/odoo#225468
Point of Sale now applies fiscal position tax rules consistently with accounting. This prevents customers and staff from seeing one tax amount at checkout while the finalized backend order records a different tax treatment.
Original PR description
If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on…
If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on the order line and the price unit and price with taxes are different (although no tax recorder on the line). Steps to reproduce: ------------------- * Create a fiscal position and assign no tax to it * On the pos config, add this fiscal position and the domestic one to the available fiscal positions * Open pos session * Select a product that has a 15% tax * Change the fiscal position to the one just created > Observation: We still see that the tax is computed based on the 15% * Pay the order * Go see the order in backend > Observation: price unit: 100, no tax, price with taxes 115 Why the fix: ------------ A recent refactoring happened on the accounting side related to fiscal positions: https://github.com/odoo/odoo/commit/9a97157920c845120861dda49d81d3150e015974 https://github.com/odoo/odoo/blob/e284dfd80bde632e6446fc0b8d3276689da35200/addons/account/models/partner.py#L155-L163 The behavior after this refactoring is the following: When changing fiscal position: - If the original tax is available for the fiscal position, we use it - If the original tax is not available but the fiscal position has an available tax that is set to be replacement for the original one, we use the replacement tax - If the original tax is not available but the fiscal position has an available tax which is NOT a replacement for the original one, we keep the original one - If the fiscal position has no tax available, we remove the tax In this fix we apply the same logic inside the pos. Without the fix we would keep the original tax in the frontend but when passed in the backend the tax with fiscal position was recomputed with the logic from accounting. This explained the difference we observed. opw-4978056 Forward-Port-Of: odoo/odoo#223164
Czech localization demo accounting entries now use dates that stay consistent when company details are updated. This prevents validation errors so users can save changes to a Czech company's address when demo data is installed.
Original PR description
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo…
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo data throws Validation Error #### Current behavior before PR: When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce: - Install l10n_cz with demo data - Open CZ Company in form view - Change address (e.g. change city Praha -> Brno) - Click Save #### Desired behavior after PR is merged: The address changes are saved without any error. #### Solution: This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin. Related to: #226152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228157 Forward-Port-Of: odoo/odoo#227847
This fixes issues that could leave the IoT Box homepage blank after an update and ensures the service starts only after the update process is complete. It also keeps the IoT Box reachable on the network and improves checkout reliability when switching to Odoo 19.0.
Original PR description
This PR is made of 3 small commits: - `[FIX] iot_drivers: fix blank homepage after checkout` Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can…
This PR is made of 3 small commits: - `[FIX] iot_drivers: fix blank homepage after checkout` Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can end up with the old Python code running but the updated JS code loading in the browser. This can lead to a blank screen as a traceback occurs trying to read the MAC address. We fix this in two ways: - A quick fix, which is just making the JS code robust to the missing value to avoid crashing. - A proper fix that will require a new image, as it modifies the `odoo.service` file to add `rc-local.service` as a dependency. This means Odoo will not start until `rc.local` has finished executing. - `[FIX] iot_box_image: set http_interface explicitly` From Odoo 19.0, a warning is logged when your `http_interface` config setting is not explicitly set. From Odoo 20.0, the default value will change from `0.0.0.0` to `127.0.0.1`, which would break the IoT box as it would only listen to localhost requests. To fix this we explicitly set the `http_interface` value to `0.0.0.0` in `odoo.conf` so that the IoT box will listen to all requests. - `[FIX] iot_drivers: use FETCH_HEAD when checking out` The current 25.07 IoT box image cannot checkout to 19.0 databases due to an issue where the `git reset origin/19.0 --hard` command fails. In the other places where we use `git reset` in the IoT box this was fixed by using `FETCH_HEAD` (an alias for the last branch that was fetched). In this commit we apply the same fix to the `upgrade.py` checkout. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228231
This fix prevents an error when users tap the reconcile button from a mobile screen. The desktop-specific reconciliation behavior is now kept to desktop views, improving reliability for mobile accounting workflows.
Original PR description
When clicking on the reconcile button in mobile, the js_class of the custom list view is never triggered because, in small screens (aka. "mobile"), by default, kanban views are used instead of list views (or at least take precedence). To avoid having a traceback, we will keep the custom behavior in desktop only no task id Forward-Port-Of: odoo/enterprise#95145
Brazilian service invoices with installments now send installment amounts without taxes, preventing mismatches during tax validation. This reduces invoice rejection errors and helps ensure smoother electronic invoicing with AvaTax.
Original PR description
Service invoices require us to send installments without taxes. If we include taxes we get an error: **Errors**: Rejection: Total Installments doesn’t match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 This **PR** clears taxes before tax calculation to ensure the installments we send are correct. **task**-4761630 Forward-Port-Of: odoo/enterprise#95331 Forward-Port-Of: odoo/enterprise#85108
Arrow keys used while navigating a dropdown now stay focused on that dropdown instead of triggering actions elsewhere on the page. This prevents unexpected navigation or behavior and makes the interface more predictable for users.
Original PR description
This commit prevents arrowleft and arrowright hotkeys to trigger on other parts of the UI when navigating a dropdown. Community: https://github.com/odoo/odoo/pull/226604 Task: [5048895](https://www.odoo.com/odoo/project.task/5048895)
This fix prevents left and right arrow keys used inside dropdowns from accidentally triggering navigation elsewhere in the interface. It also makes select menu group ordering consistent across browsers, reducing unexpected display differences for users on Firefox.
Original PR description
#### First fix because SelectMenu tests where not passing as I just switched to Firefox: The groups sorting function in the SelectMenu component (`groupsList.sort`) was not anti-symmetric, when…
#### First fix because SelectMenu tests where not passing as I just switched to Firefox: The groups sorting function in the SelectMenu component (`groupsList.sort`) was not anti-symmetric, when either group_1 or group_2 was falsy, both sortFn(group_1, group_2) and sortFn(group_2, group_1) would return 1 where it should return -1 in one of the cases. This issue only occured as Firefox seem to have a slightly different sorting algorithm, which would cause (group_2, group_1) to be called instead of (group_1, group_2), raking the group_2 before group_1. Thi commit fixes that by making the function more consistant at handling falsy values. This is probably better explained here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#description #### And the task related fix: This commit prevents arrowleft and arrowright hotkeys to trigger on other parts of the UI when navigating a dropdown. Enterprise: https://github.com/odoo/enterprise/pull/94478 Task: [5048895](https://www.odoo.com/odoo/project.task/5048895) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to change icons in the Share snippet when it is placed after another website building block. It ensures website editors can customize social sharing elements reliably, avoiding a frustrating editing issue.
Original PR description
Steps to reproduce: - Add an "Image-Text" snippet on the page. - Drop the "Share" snippet below the image. - Double click on an icon to change it. -> Problem: the icon can not be changed Note: in the above steps to reproduce, an important think is that the "Share" snippet is not the first snippet that is dropped. The problem is that the icons and the title of the snippet were added in the `extra_contenteditable_handlers` resource. The handler of this resource takes the elements of `force_editable_selector` that are inside the `root` (that is the column of the snippet if the "Share" snippet is the second dropped snippet) and checks for other elements. Because they are no elements remaining after checking for elements of the `force_editable_selector` resource, the system does not correctly add the `contenteditable` attribute on those elements. task-5107669
This fix restores a missing database index for stock rules linked to companies. It prevents misleading upgrade messages and helps keep stock-related upgrade checks aligned with expected system behavior.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226268
Scheduled customer statement sends now skip partners that were deleted before processing. This prevents the automatic account report job from failing and helps ensure remaining queued reports continue to be sent reliably.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571 Forward-Port-Of: odoo/enterprise#95127
This fixes misplaced pop-up elements when editing content inside centered iframe previews, such as the mobile preview in the mass mailing builder. Users should now see menus and overlays appear next to the intended item instead of incorrectly shifting to the side.
Original PR description
This commit fixes an issue with containers inside iframes that renders the position computation for the popper incorrect. The problematic situation arises when the popper needs to be positioned near…
This commit fixes an issue with containers inside iframes that renders the position computation for the popper incorrect.
The problematic situation arises when the popper needs to be positioned near an element inside an iframe and the base container used for the computation is inside the same iframe.
This case happens in the mass_mailing builder when in the mobile preview as the iframe is centered in the viewport and the element that enables the scrolling when overflowed is also inside the iframe.
When in this case, the min and max values for the variant and the direction are computed on a container that is really smaller than the viewport. Meaning that when this happens the popper is positioned on the left of the iframe, which is completely incorrect.
To fix this issue, when we detect that we are indeed in the problematic situation, we add the left and top values of the iframeBox to direction{Min/Max} and variant{Min/Max}. This way the variantOffset is computed based on the position of the container adjusted to the iframe.
before:
<img width="3021" height="1549" alt="image" src="https://github.com/user-attachments/assets/f6c6f3b7-cdd1-4699-97ab-732ef3ec5ff1" />
after:
<img width="3099" height="1502" alt="image" src="https://github.com/user-attachments/assets/00c06936-de4d-48a0-b4f7-19cab3fc821d" />
task-5109138
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update makes an internal website theme test wait for asset reloading to finish before completing. This reduces random test failures and helps keep development and release validation more stable, without changing the customer-facing website experience.
Original PR description
The goal of this commit is to fix an undetermined bug in the theme tab palette tests. Sometimes, ‘reload assets’ occurred before the end of the test. We will therefore wait to go through ‘reload assets’ before the end of the test in order to make it deterministic. Error: https://runbot.odoo.com/odoo/error/232650 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#228175
Purchase bills in the Indian GST reporting flow now return to a clean reconciliation state when reset to Draft. This prevents old GSTR-2B statuses, return-period links, or exceptions from carrying over and helps ensure the bill can be reconciled correctly again.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95251 Forward-Port-Of: odoo/enterprise#95026
This fix ensures timesheet reports correctly include helpdesk ticket information where intended. It corrects a previous report update that did not properly target the existing report field, helping users see complete ticket-related timesheet details.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
This fix prevents Helpdesk timesheet creation from failing when a linked project has no company set and the user works across multiple companies. It keeps the correct company information during timesheet creation, reducing validation errors for support teams and migrations.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
Fixed an issue where website event pages could identify the wrong event when the event title used non-Latin characters such as Chinese. This ensures users can reliably edit and manage events regardless of the language used in the event name.
Original PR description
Issue: The Website Event page uses a matching regex to get the event id from the url. URLs are formatted like: '/event/[event-title]-[event-id]/register' The event-id is recovered from the url by matching on the first number that is not followed by a word character. However, for non-latin event titles (e.g. Chinese), the characters are converted using '%' characters and numbers (e.g. '%E6%88%91%E'). The regex consistently fails to get the event id in this case, and returns incorrect IDs. Steps to reproduce: 1. Install `website_event` and go to the website view of any event. 2. Edit the event, to add a Chinese title 3. Save, and try to edit again the same title. Solution: The regex is modified to look for the first number that is followed by either a "/" or the end of a String. opw-5038334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224164
Resetting an Odoo Calendar connected to Google Calendar no longer fails because of permissions on events the user cannot edit. This prevents an unnecessary error during calendar resets and lets users complete the reset process smoothly.
Original PR description
Before this commit, when resetting the Odoo Calendar of an user, it would trigger a ValidationError for updating events that the current user wasn't able to update, even though it was not an updated per se, but just a deletion of it in Odoo. After this commit, we no longer trigger that ValidationError during resets of Odoo Calendars, fixing the error. task-5103918 Forward-Port-Of: odoo/odoo#228195 Forward-Port-Of: odoo/odoo#227991
This fixes an issue where non-admin website editors could see an error when changing the website menu bar. The system now avoids loading restricted view fields they are not allowed to access, so editing can continue normally without exposing protected data.
Original PR description
Scenario: - get a user with "Editor and Designer" and no admin rights - with this user, edit the website and change the menu bar Result: A traceback error is shown with this access error the logs: You do not have enough rights to access the field "visibility_password" on View (ir.ui.view). Please contact your system administrator. Operation: read Groups: allowed for groups 'Role / Administrator' Issue: In 9830f77d827c6efeb5f796caac604904350f5a80 the method ir.ui.view()._get_combined_archs was changed to prefetch more fields than before, but prefetching the "visibility_password" field was causing an access error when checking if we had access to it. Fix: prevent prefetching restricted fields. Note: the added test without the fix, fails because of the security warning error, and having the custom view still disabled. opw-4935489 Forward-Port-Of: odoo/odoo#219304
The shop price range filter now uses the corrected search term when Odoo suggests close matches, such as treating "dask" as "desk". This keeps filtering accurate and prevents shoppers from losing the ability to narrow results by price after a fuzzy search.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Navigate to the website shop page.
2. Search for a term that is close to an existing one, but not exact ("dask" instead of "desk" for example)
Issue
-----
The price range filter will stop functioning
Cause
-----
The domain used to get the minimum and maximum prices for the price range filter used the original search term regardless of whether the actual search results are from a fuzzy search term or not
Solution
--------
When there is a fuzzy search term use it to get the minimum and maximum prices for the price range filter instead of the original search term
opw-5020545
Forward-Port-Of: odoo/odoo#228203
Forward-Port-Of: odoo/odoo#226059A small fix ensures Swedish ISO 20022 payment journal processing passes all needed information when other Odoo modules extend it. This helps avoid errors or missing details in payment file generation for customized setups.
Original PR description
Pass all arguments to super-call of _get_company_PartyIdentification32-method in account_iso20022/models/account_journal_iso20022_se.py so they can be passed correctly in other modules inheriting the method. Forward-Port-Of: odoo/enterprise#93883
This fix ensures the cash movement popup in Point of Sale uses the translated text instead of the original untranslated variable. It improves the experience for users working in languages other than the default by showing localized wording consistently.
Original PR description
Makes changes for translation Description of the issue/feature this PR addresses: Error variable code for translation Current behavior before PR: The original variable is used Desired behavior after PR is merged: The translated variable is used --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now shows the optional product popup when a cashier scans a product barcode, matching the behavior already seen when selecting a product on screen. This helps ensure upsell or add-on suggestions are not missed during faster barcode-based sales flows.
Original PR description
Before this commit, the optional product popup was only displayed when adding a product by clicking on it. When the product was added through barcode scanning, the popup did not appear. This commit ensures that the optional product popup is consistently shown both when clicking on a product and when scanning its barcode. opw-5089175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227656
This fix prevents an access error when customers create an invoice from a QR code in Point of Sale configurations involving parent and branch companies. It helps ensure self-service invoicing works reliably when journals and products belong to related companies.
Original PR description
Before this commit, in a multi-company setup, an access error could occur when generating an invoice from a QR code. Steps to reproduce: 1. Create a parent company and a branch company. 2. Create a PoS in the branch company and assign a sales journal from the parent company. 3. Create a product assigned to the branch company. 4. Enable Self Service invoicing in the PoS settings. 5. Create an order in the PoS and then try to create an invoice with the QR code. Result: an access error was raised. opw-5050536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225483
This fix prevents accounting reports from trying to refresh after the report view has already been closed or replaced. Users are less likely to encounter an error when navigating away while a currency rate filter dropdown is open.
Original PR description
For the currency rate filter, applyFilters is called when the dropdown is closed. It might heppen that we have the dropdown open then we click on something that trigger the destruction of the report view but that still trigger applyFilters which try to apply filter on a destroyed component which is illegal. To prevent this we check if the component is destroyed before reloading the controller. Forward-Port-Of: odoo/enterprise#94313
7 changes
Resolved issues and error corrections
Users can no longer attempt to send a WhatsApp message after removing the required template. This prevents an unexpected error and gives a clearer validation path, improving reliability when messaging contacts.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898
This fixes a Sales module issue where automated product configurator checks could fail when sales order line columns were customized. The change makes the test flow more robust for businesses that adapt sales order screens to their needs.
Original PR description
To reproduce: 1. Manually modify the SO view `view_order_form` notebook SO lines list view to make visible any column before `product_id` For example:…
To reproduce:
1. Manually modify the SO view `view_order_form` notebook SO lines list view to make visible any column before `product_id` For example:
https://github.com/odoo/odoo/blob/18.0/addons/sale/views/sale_order_views.xml#L521 making the field `display_type` visible
2. Run the tests of `sale` module
=> `sale` module tests will fail on test `test_sale_combo_configurator_preconfigure_unconfigurable_ptals`
```
FAILED: [18/22] Tour sale_combo_configurator_preconfigure_unconfigurable_ptals → Step Verify that configurable ptals are now configured (trigger:
.sale-combo-configurator-dialog
.combo-item-grid
.product-card:has(.card-title:contains("Test product"))
:contains("Attribute B: B")).
Element (
.sale-combo-configurator-dialog
.combo-item-grid
.product-card:has(.card-title:contains("Test product"))
:contains("Attribute B: B")) has not been found.
TIMEOUT step failed to complete within 10000 ms.
```
see runbot build fail at:
https://runbot.odoo.com/runbot/build/89552334
The issue happen as - for some dark magic JS/XML reason - adding the field before product_id make fail the step to click the checkbox using the span.
Fix was suggested by PIPU to solve/workaround the issue
In practice, this issue was discovered accidentally with a customisation which was willing to add a custom field at the start of the list
opw-5068699The online shop now updates available quantities correctly when customers add either a kit product or one of its components to their cart. This prevents shoppers from seeing misleading stock information and helps avoid overselling when kit items share limited inventory with individual products.
Original PR description
### Steps to reproduce: - In the settings website > Shop: - Disable `Out-of-Stock: Continue Selling`. - Enable `Show Available Qty` if below 5 units. - Create 2 storable products published on the…
### Steps to reproduce:
- In the settings website > Shop:
- Disable `Out-of-Stock: Continue Selling`.
- Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
- COMP, put 1 unit in stock.
- KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product
### Cause of the issue:
The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.
opw-4889956
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222945Point of Sale now alerts other devices when an order has been cancelled, paid, or invoiced elsewhere. This prevents staff from continuing to edit an order that is already finalized, avoiding errors during restaurant and checkout workflows.
Original PR description
Before this commit when another device were finalizing an order (cancel, paid or invoiced) the current device was staying on its current screen which can be PaymentScreen, SplitScreen etc. But when the user was trying to edit the order a traceback was raised because the order is finalized. Now when another device is finalizing an order, the current device will be notified and can take appropriate action, such as showing a warning message or preventing further edits to the order. taskId: 4788430
This fixes a restaurant point of sale issue where added items could fail to sync before being sent to the kitchen printer or preparation display. It helps prevent outdated order errors and keeps table orders consistent between the register and server.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal timesheet view now shows billed timesheet entries even when a customer opens it from a website linked to another company. This prevents missing timesheet information for users who are allowed to access multiple companies, improving invoice and project transparency.
Original PR description
**Steps to reproduce:** 1. Install hr_timesheet, Sales, Website > add BE company > 2. Go to website, configuration > website > update the website1 company to BE 3. Sales > create new SO > add product Junior Architect (Invoice on Timesheets) 4. Confirm > click to tasks smart-button > add timesheet > back to sales order 5. Create invoice > confirm 6. Preview > View Timesheet **Issue:** View timesheet button shows no timesheet records when accessing from different company website **Cause:** Portal timesheet domain is restricted to current website's company context. When user switches from San Francisco website to Belgium website, timesheets created under San Francisco company become invisible even though user has access to all companies. **Solution:** Add allowed_company_ids context to account.analytic.line model to include all user's accessible companies, allowing cross-company timesheet visibility. **opw-4922212**
This fix replaces a technical crash with a clear user-facing message when an Argentine invoice document number has an invalid format. It helps users understand and correct the issue during invoice reversal or processing instead of seeing a system traceback.
Original PR description
Description of the issue/feature this PR addresses: This pull request improves error handling in the `_l10n_ar_get_document_number_parts` method in `account_move.py`. The main change is to provide a…
Description of the issue/feature this PR addresses:
This pull request improves error handling in the `_l10n_ar_get_document_number_parts` method in `account_move.py`. The main change is to provide a user-friendly error message when the document number does not match the expected Argentine format.
Error handling improvement:
* Added a `try/except` block to catch `ValueError` when splitting the `document_number`, raising a `UserError` with a localized message if the format is incorrect.
Current behavior before PR:
If the user tries to reverse a document that does not match the argentinean format, a traceback an error such as the following is generated:
`File "/home/odoo/src/enterprise/l10n_ar_edi/models/account_move.py", line 588, in _get_related_invoice_datawskey[afip_ws]['number']: self._l10n_ar_get_document_number_parts(File "/home/odoo/src/repositories/ingadhoc-odoo-argentina/l10n_ar_ux/models/account_move.py", line 101, in _l10n_ar_get_document_number_partsreturn super()._l10n_ar_get_document_number_parts(document_number, document_type_code)File "/home/odoo/src/odoo/addons/l10n_ar/models/account_move.py", line 21, in _l10n_ar_get_document_number_partspos, invoice_number = document_number.split('-')ValueError: not enough values to unpack (expected 2, got 1)as`
Desired behavior after PR is merged:
An `UserError` is raised.
<img width="1553" height="419" alt="image" src="https://github.com/user-attachments/assets/b47dc205-6997-4117-a768-d6241d33b158" />
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr7 changes
Resolved issues and error corrections
Fixed activity date filters so completed activities that are kept for history are included in search results. This helps users find records such as CRM opportunities when filtering by an activity's completion date, reducing missing results in day-to-day follow-up and reporting.
Original PR description
## Issue: ## When using a Custom Filter on Activities > Date Done on any record like in the CRM App, the inactive activities where not included in the search domain The keep_done option on the…
## Issue: ## When using a Custom Filter on Activities > Date Done on any record like in the CRM App, the inactive activities where not included in the search domain The keep_done option on the activity_type should be activate to keep old activities The same issue occured in Activities in the Settings App in Debug Mode, with the Custom Filter on Date Done ## Cause: ## The domain in the search doesn't include inactive activities There is a lot of active test in the query ## Fix: ## When there is `date_done` in the filtered domain in functions `search_fetch()` and `_search()` in `mail_activity_mixin`, we add `active_test=False` to self context We also do tha same in the `_search()` of `mail_activity` to handle the Settings case The `search_fetch()` override is needed for App like CRM to make the full query to be executed with the `active_text` context or some informations are lost If this method doesn't include the context, the lead appeared but the linked Activities aren't fetched completely ## Limitations: ## Fixing that way can cause to get too many elements, because it will remove all the (active=True) from the all query This can lead to display inactive or archived leads in CRM, or any archived and inactive data with done activities ## Steps to reproduce: ## - Open the CRM App - Go to Configuration > Activity Types - Select Call - Toggle Keep Done to enable - Go in the CRM Pipeline - Mark any Call activity as Done - Add a Custom Filter - Set to Activities > Done Date (keep the default value for today) - Apply the filter using the Add button - Before the fix, there is nothing in the filtered pipeline opw-4744974
This fix swaps two Mexican DIOT report columns so exempt imports and exempt amounts appear in the correct positions. The values were already calculated correctly, but the corrected ordering helps ensure exported reports match the expected official layout.
Original PR description
Description of the issue/feature this PR addresses: The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. Current behavior before PR: “exempt” is column 49 “exempt imports” is column 50 Desired behavior after PR is merged: “exempt” is column 50 “exempt imports” is column 49 Task-id: 5096808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican DIOT report export now places the “exempt imports” and “exempt” values in the correct columns. This fixes a formatting issue in the downloaded TXT file so businesses can submit reports with the expected column layout, while the underlying calculated values remain unchanged.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where users could see raw HTML text instead of a properly formatted help message when no bank transactions were found. This makes the bank journal experience clearer and more professional when fetching transactions or changing filters.
Original PR description
Before this commit: - The help message displayed raw HTML tags when no transactions were returned after clicking 'Fetch Transactions' in the Bank journal. - Also, removing a filter (without reloading) and applying another filter that resulted in no matches, the same issue occurred. After this commit: - The help message is now consistently rendered with proper markup task-4942234
Point of Sale self-order sessions now remove their temporary numbering data when a session is closed. This helps keep the database tidier over time and avoids buildup from repeated sessions, with no expected change to the checkout experience.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes a purchase stock test use the intended type of product regardless of other installed localization modules. It helps prevent false test failures and keeps quality checks reliable without changing day-to-day business workflows.
Original PR description
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase…
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase order. The test assumes the product is of type `consu`, which bypasses stock reservation. However, the following [XML default](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu_stock/data/ir_default.xml#L5) in l10n_ke forces the product type to `product` (stockable), triggering reservation logic. Since the ordered quantity is negative, no reservation occurs, and the `_sanity_check()` fails with: `You cannot validate a transfer if no quantities are reserved.` We fix this by explicitly setting a product with the type `consu` in the test. This ensures that reservation is skipped regardless of which modules are installed or what defaults they apply. runbot:[108147](https://runbot.odoo.com/odoo/error/108147) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Helpdesk ticket lists now sort ticket references in a way that matches how users expect numbers to be ordered. This makes it easier to find the oldest or newest tickets once ticket counts reach 100 or more.
Original PR description
**Issue** With the default `helpdesk.ticket` sequence, once users reach 100 tickets, ordering tickets by `ticket_ref` in the list view is unintuitive as it is a Char field (so '11' > '100') and the results are not useful if the user wants to see the oldest/newest tickets. opw-4891916