Daily updates from Odoo
Wednesday, July 29, 2026
23 changes · master
Enhancements to existing features
When users open the new-product form from barcode lookup, existing notifications are no longer cleared automatically. This keeps helpful messages visible because mobile notifications now appear at the bottom and no longer block the form.
Original PR description
…n click This reverts commit https://github.com/odoo/enterprise/pull/68352. That commit cleared all open toast notifications before opening the new-product form, because on mobile a notification used to take up a large chunk of the screen, forcing the user to wait out its autoclose timeout before they could interact with the form underneath. Notifications on mobile are now anchored to the bottom of the screen (M3 snackbar), so they no longer overlap the form and this workaround is no longer needed.
This update refreshes icon usage in several Odoo Enterprise areas to align with the latest web interface standards. Users should see more consistent visual elements in affected screens, with minimal change to day-to-day workflows.
Belgian payroll screens and reference data were updated to make DMFA work location information clearer and more consistent. This helps payroll users identify and manage work location details more easily when preparing Belgian social security reporting.
Original PR description
[IMP] l10n_be: dmfa work location adjustments Renaming and view adjustments for dmfa work location task-6381334
Add a new notification in the bank reco widget when a user do a reconciliation with a partner different from the one on the st_line. The idea is to let the user chose if he wants to move the bank account from the st_line partner to the move he tries to reconcile. task-6303397 Forward-Port-Of: odoo/enterprise#125702 Forward-Port-Of: odoo/enterprise#120900
Original PR description
Add a new notification in the bank reco widget when a user do a reconciliation with a partner different from the one on the st_line. The idea is to let the user chose if he wants to move the bank account from the st_line partner to the move he tries to reconcile. task-6303397 Forward-Port-Of: odoo/enterprise#125702 Forward-Port-Of: odoo/enterprise#120900
Payroll users can now open the full Time Off request form directly from a leave entry in the Gantt view. The new expand button makes it easier to review or update all request details without navigating away manually.
Original PR description
Before this commit, users could click on a leave entry in the Gantt view of the Payroll app, but they could not open its full form view. This commit adds an expand button (double arrow icon) that allows users to open the complete Time Off request form. Task-6360136
When users try to create an expense card before Stripe is connected, they are now directed to the settings page to complete the connection. This reduces confusion and helps users resolve the setup issue more quickly.
Original PR description
When a user tries to create a card but the configuration is not connected, redirect the user towards the settings to do the connection. task-6272805 Forward-Port-Of: odoo/enterprise#125113
This update makes the field selection experience in Studio behave consistently when debug mode is enabled. It helps advanced users see the same options and behavior when configuring relational fields as they already do in domain filters.
Original PR description
This commit evaluates the `isDebugMode` prop which is passed to ModelFieldSelector so that the component acts the same for Relational field selector as in Domain field selector. Task~6369639
Marketing automation synchronization is now prepared to focus on campaigns that are currently running, helping avoid unnecessary processing for inactive campaigns. The related enrollment tests were reorganized to make future improvements easier to maintain.
Original PR description
Add some filters on main API synchronization methods so that they are limited to running campaigns. Move enroll sepcific tests into a new test file to ease future updates. Prepares Task-6425785 [marketing_automation] Incremental sync
Resolved issues and error corrections
This fixes outdated internal test expectations for marketing automation after a previous change was merged. It helps keep performance monitoring accurate and reduces false alarms in automated checks, with no direct change for end users.
Original PR description
Finally forgotten when merging odoo/enterprise#66823
The Vietnam Sales Tax Report now shows VAT amounts consistently as positive values when users expand report details to the invoice level. This prevents confusion from sales tax amounts appearing negative in detailed views while totals remain positive.
Original PR description
## Current behavior: In Vietnam's Sales Tax Report, when unfolding until the minimum layer, the VAT now displays the value in negative ## Expected behavior: The VAT value in the minimum layer should…
## Current behavior: In Vietnam's Sales Tax Report, when unfolding until the minimum layer, the VAT now displays the value in negative ## Expected behavior: The VAT value in the minimum layer should be consistent with the upper layers and kept positive ## Steps to reproduce: - Install l10n_vn (l10n_vn_reports will install as well) - Switch to VN Company - With demo data, go to Invoicing / Reporting / Tax Report - Change Tax Report (VN) to Sales/Purchase Tax Report (VN) - Unfold the lines all the way to the minimum layer: VAT on sales of goods and services 10% -> INV/2026/00003 - Observe that the VAT 10% line is at negative, which is inconsistent with the Total line below ## Cause of the issue: - In Odoo, tax journal items store tax_base_amount with the accounting sign (negative for sales). This is expected behavior - However, Vietnamese VAT listing expects commercial amounts, which means sales bases need to be displayed as positive numbers ## Fix: Normalized tax_base_amount sign in _query_tax_lines function before building the SQL query opw-6344577 Forward-Port-Of: odoo/enterprise#125257 Forward-Port-Of: odoo/enterprise#122785
Sales order information on planning slots is now visible for companies using a single-company setup. This prevents users from missing key sales order links when viewing or editing planning slot forms.
Original PR description
The `sale_line_id` field was previously injected after `company_id`. Because the first instance of `company_id` in the base view is wrapped inside a `<t groups="base.group_multi_company">` block, the inserted fields were inadvertently hidden in single-company databases. This commit changes the XPath target to `role_id` to ensure the sales order fields are always visible in the planning slot form view, regardless of multi-company settings. task: 6398673 Forward-Port-Of: odoo/enterprise#125712
Users without certain Planning or Project permissions can now open the product catalog from sales quotations without hitting an access error. The fix checks user permissions before reading restricted field service or planning information, keeping sales workflows usable for limited-access users.
Original PR description
A user without Project rights cannot add a product from the catalog on a sale order Steps to reproduce: 1. Install industry_fsm_sale module 2. Go to Settings > Users & Companies > Users and open user Marc Demo 3. Set Field Service and Project rights to No 4. Log in as Marc Demo 5. Go to Sales and open any quotation 6. Click on Catalog in the order lines 7. An access error is raised Issue: industry_fsm_sale overrides `action_add_from_catalog` and tries to read sale.order.tasks_ids but users can't always access this field as it requires Project rights Solution: Check that the user has Project rights before trying to read tasks_ids opw-6315647 Forward-Port-Of: odoo/enterprise#125526 Forward-Port-Of: odoo/enterprise#123228
The Australian payroll scheduled data update now restores required rule category data before updating salary rules. This prevents the scheduled action from failing if payroll rule categories were previously deleted, helping payroll maintenance run reliably.
Original PR description
Currently, an error occurs when the "Payroll: Update Data" scheduled action is run. **Steps to Reproduce:** - Install `l10n_au_hr_payroll` with demo data. - Switch to `Australian Company`. - Go to…
Currently, an error occurs when the "Payroll: Update Data" scheduled action is run. **Steps to Reproduce:** - Install `l10n_au_hr_payroll` with demo data. - Switch to `Australian Company`. - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. - Delete all records related to the `Australian Company`. - Go to `Scheduled Actions` and run `Payroll: Update Data`. `ValueError: External ID not found in the system: l10n_au_hr_payroll.rule_category_ote` After [this commit], the category_id field becomes non-required, allowing users to delete a rule category record even if it is linked to a salary rule. When updating the data file [1], an error is raised due to the missing rule category. This commit ensures that when updating the salary rule data, it updates the category data beforehand as like [here] [this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e [1] https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_au_hr_payroll/models/hr_payslip.py#L76-L83 [here]: https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_ch_hr_payroll/models/hr_payslip.py#L1074-L1087 sentry-7349905716 Forward-Port-Of: odoo/enterprise#121167
Marketing Automation campaigns no longer trigger an error when a user clears the Target field while editing a campaign. This keeps campaign setup stable and avoids an unexpected interruption in the user workflow.
Original PR description
Currently, an error occurs when a user removes the target model from a marketing campaign. **Steps to Reproduce:** - Install the `marketing_automation` module. - Go to `Marketing Automation` >…
Currently, an error occurs when a user removes the target model from a marketing campaign. **Steps to Reproduce:** - Install the `marketing_automation` module. - Go to `Marketing Automation` > `Campaigns`. - Create a `new campaign` and clear the `Target` field. `KeyError: False` After the recent commit that added the recipients_count field and its computation [1], when the user removes model_id(Target), model_name is set to False [2]. The domain is then updated by a compute method, which triggers the computation of recipients_count. Since the computation only checks whether domain is set and does not verify that model_name is available, it attempts to access the model using model_name, raising the error [3]. This commit ensures that, when computing the recipient count, it also checks that model_name is set. Since model_id is a required field, once it is set, the recipient count is computed correctly based on the domain and model_name. [recent commit]: https://github.com/odoo/enterprise/commit/5485e8eaa7636c7dd0b305b4e26fb772aff6d030 [1]: https://github.com/odoo/enterprise/blob/1cbb21eaf0f24cedb4cc18a31065a76b1dd9783e/marketing_automation/models/marketing_campaign.py#L43 [2]: https://github.com/odoo/enterprise/blob/1cbb21eaf0f24cedb4cc18a31065a76b1dd9783e/marketing_automation/models/marketing_campaign.py#L33 [3]- https://github.com/odoo/enterprise/blob/1cbb21eaf0f24cedb4cc18a31065a76b1dd9783e/marketing_automation/models/marketing_campaign.py#L146-L148 sentry-7612724367 Forward-Port-Of: odoo/enterprise#124649
This fixes an internal test setup for Indian payroll so percentage calculations are checked using dedicated sample employee data. It helps prevent unrelated employee payroll values from affecting test results, without changing payroll behavior for users.
Original PR description
Use a dedicated employee/version for the percentage computation test instead of Rahul, whose existing payroll values affect copied version data. Define the test amounts in common and reuse `employee.version_id` in the test, so percentages are derived from amounts without changing payroll behavior. task-6340923 Forward-Port-Of: odoo/enterprise#124330 Forward-Port-Of: odoo/enterprise#121918
Draft invoices no longer show the vehicle field as a clickable link on invoice lines. This keeps draft invoice behavior consistent with products and prevents users from opening related vehicle records before the invoice is posted.
Original PR description
The vehicle under account on the invoice lines should not be clickable when the invoice is in draft. Only when it is posted, like the product. task-6385436 Forward-Port-Of: odoo/enterprise#125688 Forward-Port-Of: odoo/enterprise#124514
Timesheet descriptions in the assistant now expand automatically so long entries can be read in full instead of being cut off. This helps users review and edit detailed time entries without losing important context.
Original PR description
- changed the description field to expand dynamically to display long descriptions in full instead of truncating them in the assistant Task-6348575 Forward-Port-Of: odoo/enterprise#125536 Forward-Port-Of: odoo/enterprise#123428
This update corrects how Belgian payroll notification files are analyzed. It helps ensure payroll declarations are processed more reliably, reducing the risk of errors when handling official ONSS notifications.
Original PR description
Forward-Port-Of: odoo/enterprise#125500
Fixed Chilean invoice PDFs so the legally required CEDIBLE disclaimer is always shown in Spanish, regardless of the customer's language settings. This helps ensure printed invoice copies remain compliant with Chilean requirements.
Original PR description
Steps to reproduce: - Set the database language to Spanish (Latin America). - Create a customer invoice, confirm it and send it to the SII. - Print it using Print > Invoice PDF copy (Chile). - Scroll…
Steps to reproduce:
- Set the database language to Spanish (Latin America).
- Create a customer invoice, confirm it and send it to the SII.
- Print it using Print > Invoice PDF copy (Chile).
- Scroll to the CEDIBLE section at the bottom of the PDF.
Cause of the issue:
The CEDIBLE footer is merged into l10n_cl.report_invoice_document, which account.report_invoice (odoo/addons/l10n_cl/views/report_invoice.xml) renders with t-lang set to the invoice partner's lang, not the database/user language. The disclaimer text was hardcoded in English and relied on the regular translation to be shown in Spanish, so as
soon as the partner's lang field isn't Spanish, the translation lookup falls back to the untranslated English source, regardless of the database language.
Solution:
This disclaimer is boilerplate mandated by Chilean law: it must always be printed in Spanish, independently of the invoice partner's or current user's language. The same template already follows that rule a few lines above for the SII stamp block ("Timbre Electrónico SII..."), which is hardcoded in Spanish instead of relying on translation.
opw-6390207
Forward-Port-Of: odoo/enterprise#125463
Forward-Port-Of: odoo/enterprise#124916This fixes how Swiss payroll declarations check the status of BVG-LPP pension fund submissions. The fund number is no longer included where it should not be, helping avoid incorrect status lookups or rejected declaration handling.
Original PR description
Forward-Port-Of: odoo/enterprise#126040
Swiss employee payslips now show the actual contract withdrawal date instead of a related version end date. This helps ensure payroll reports display the correct employment end information when those dates differ.
Original PR description
The Withdrawal Date in the payslip of CH employees was printing the date_end relative to the version related to the payslip. Instead, it should print the end of the contract of that version, since they can be different. The end date of the contract is in l10n_ch_withdrawal. Task: 6398291 Forward-Port-Of: odoo/enterprise#124848
Code cleanup and technical improvements
This update refreshes internal component wiring to align with the latest Owl framework behavior. It helps keep several Odoo Enterprise apps maintainable and compatible without changing user-facing features.
Original PR description
Follow-up of the community commit removing `useChildRef` and `useForwardRefToParent`: Owl 3 refs are signals, so a parent creates its ref with `signal.ref()`, hands it to the child (which binds it with `t-ref`) and reads the element by calling it instead of through `.el`.
Default values for certain records are now initialized per record instead of being shared globally, reducing the risk of confusing or unintended behavior. The WhatsApp composer patch was also cleaned up to avoid copying stray data onto the shared model definition.
Original PR description
A plain value on a model prototype, typically from patch(Model.prototype, { flag: false }), is shared data: every record of the model reads the same value, and nothing tells a reader whether it got a default or a value set on the record. Such defaults belong to the record, so they move into setup().
The whatsapp composer went through Object.assign with a stray name argument between the target and the values, so the characters of that name were copied onto the prototype as numeric keys. It uses patch() like every other model patch.
https://github.com/odoo/odoo/pull/279104