Daily updates from Odoo
Thursday, September 25, 2025
19 changes · master
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