Saturday, March 21, 2026
15 changes · 19.0
Resolved issues and error corrections
The website editor now checks the specific snippet a user selected before showing where it can be placed. This prevents users from adding content blocks, such as embed code, into restricted areas where they should not be allowed.
Original PR description
Before this commit, the dropzones activated would not always be correct clicked on a group and then selected a snippet. The dropzones would be determined based on a default section and not based on the selected snippet. Therefore, even though there could be rules preventing a snippet from behing in a certain dropzone, the dropzone would still be activated because the snippet chosen would not be taken into account. This commit fixes the issue by using the chosen snippet to activate the dropzones. task-5428387 Forward-Port-Of: odoo/odoo#240547
Sharing a project with a portal user no longer changes the project's visibility setting unexpectedly. This preserves the access level selected by the user and avoids accidentally broadening project visibility during the share flow.
Original PR description
Steps to reproduce: - Create/open any project - Set visibility to `Invited internal users and portal users`. - Share project with a portal user - Visibility changes to `All internal users and invited portal users`. Cause: - Previously, this behavior was implemented specifically for sharing the project from the cog menu. However, the `Share Project` option has now been removed from the cog menu. - After introducing the new `invited_users` visibility option, the existing share logic was not updated to support this new value; as a result, the project's existing visibility is unintentionally overwritten. Solution: - Remove the hardcoded update of `privacy_visibility` in the `action_send_mail` method. task-5924243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet component up to the latest version and fixes several user-facing issues. Users should see more reliable copy-paste behavior, chart labels and map data, dashboard filters, pivot grouping, and formula editing.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b6f5b5a83b [REL] 19.0.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b6f5b5a83b [REL] 19.0.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7fb8fe65f1 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382) https://github.com/odoo/o-spreadsheet/commit/45802f75ad [FIX] Chart: Update geojson data [Task: 5224009](https://www.odoo.com/odoo/2328/tasks/5224009) https://github.com/odoo/o-spreadsheet/commit/ec6002c763 [FIX] Formulas: fix missing debugger char in formula reconstruction [Task: 6019586](https://www.odoo.com/odoo/2328/tasks/6019586) https://github.com/odoo/o-spreadsheet/commit/bd978fc931 [FIX] filters: allow criterion filter in dashboard [Task: 6017734](https://www.odoo.com/odoo/2328/tasks/6017734) https://github.com/odoo/o-spreadsheet/commit/a16f44c5d0 [FIX] charts: hierarchical charts should show formatted labels instead of raw [Task: 5913296](https://www.odoo.com/odoo/2328/tasks/5913296) https://github.com/odoo/o-spreadsheet/commit/23d7a75566 [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522) https://github.com/odoo/o-spreadsheet/commit/40523158d3 [FIX] standalone_composer: wrong composer content on start edition [Task: 6022743](https://www.odoo.com/odoo/2328/tasks/6022743) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This pull request fixes several issues affecting point of sale refunds and combos, accounting form updates, web save redirections, manufacturing order creation, inherited fields, and translations. It also improves performance when creating records with large HTML content, which can speed up mass mailing and reduce memory usage.
Original PR description
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
Malaysia POS consolidated e-invoices now show the full invoice amount as payable instead of being reduced to zero by already-recorded counter payments. This aligns the e-document totals with MyInvois expectations and helps avoid validation or compliance issues.
Original PR description
For POS consolidated invoices, the PrePayment Amount was mapped to the payment linked to the document. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document , regardless of prior payments. This commit forces the PaidAmount to 0 for consolidated documents, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-[6021698](https://www.odoo.com/odoo/all-tasks/6021698) Forward-Port-Of: odoo/odoo#253499 runbot-[241948](https://runbot.odoo.com/odoo/runbot.build.error/241948) --- In the commit message, I wasn't sure how to mention the extra modifications made in this PR so I simply added the runbot link.
Invoices containing fixed deposit-style taxes on zero-priced return lines now generate compliant Peppol e-invoices. This prevents validation failures by keeping tax exemption details consistent in the VAT breakdown.
Original PR description
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the…
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations. **STEP TO REPRODUCE** 1. Create a fixed tax used for 'vidange/consigne'. 2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'. 3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08]. **CAUSE** Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice: line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange. After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%. line 2: qty=-1, unit_price=0, taxes: 0%. line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None. When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'. Line 2 reason comes from: https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274 opw-5912986 Forward-Port-Of: odoo/odoo#254704 Forward-Port-Of: odoo/odoo#250413
Odoo now blocks users from deleting tax groups that are already used in business records, preventing accidental data inconsistencies. Related point of sale behavior was adjusted to deactivate taxes instead of deleting them, and tax usage checks were made more efficient.
Original PR description
Before this PR: - Group of taxes can be deleted by a user, even if they are used. After this PR: - If a user tries to delete a group of taxes in use, a validation error is raised. - Fixed a test case in POS and deactivated the tax instead of deleting the tax. Related PR: https://github.com/odoo/enterprise/pull/105174 task-5472834 Forward-Port-Of: odoo/odoo#254730 Forward-Port-Of: odoo/odoo#245243
Uploaded PEPPOL BIS 4a customer invoice XML files can now find supplier partner details even when they are stored in an older XML location. This prevents newly created invoices from missing the partner, reducing manual correction after import.
Original PR description
Currently, invoices created by uploading an e-invoice xml may not have the partner correctly filled in. Steps to reproduce: - Upload a customer invoice XML in format PEPPOL BIS 4a Issue: Partner is not set on the newly created record. On the chatter can be observed the message "Could not retrieve partner with details: Name: None, Vat: None, Phone: None, Email: None" Analysis: After https://github.com/odoo/odoo/commit/b4da4a77da3e0dc18707b935786b1924ca473796 we look for partner information under AccountingSupplierParty/Contact However older format may still be used to encode partner info under AccountingSupplierParty/Party opw-5970610 Forward-Port-Of: odoo/odoo#251808
Odoo now sends presence updates only after a user presence record is fully removed, so other users see the correct offline status. It also corrects missed presence updates so each contact’s own status is reported instead of the current user’s status.
Original PR description
Before this commit, presence channel notifications for unlinked records were sent before the records were actually removed from the database. This caused `im_status` to be calculated using stale data, occasionally resulting in statuses other than "offline" being broadcast. This commit ensures notifications are sent only after the presences have been unlinked, guaranteeing an accurate status. Forward-Port-Of: odoo/odoo#254186 Forward-Port-Of: odoo/odoo#249314
Odoo now correctly handles Hungarian customer VAT details when creating electronic invoices. If the standard VAT format is not available, it uses the domestic Hungarian tax number so invoices can be accepted by NAV.
Original PR description
Problem --------- When building the UBL, invoices with Hungarian partners get hit with the following constains: "The VAT of the [role] should be prefixed by the country code". However, Hungary allows for VAT numbers that do no start with the country code. Every Hungarian business is assigned a Tax Number (Adószám) that follows a fixed 11-digit format: NNNNNNNN-Y-CC. Solution --------- Build the VAT number from the Domestic Tax Number if it is not the case. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253663
This fix corrects how Spanish Facturae electronic invoices group and round tax totals at the invoice level. It helps ensure generated XML invoices match expected legal and validation formats, reducing errors when sending electronic invoices.
Original PR description
- Adjusting invoice-level `<TaxesOutputs>` nodes to be generated per tax rather than per line - Enabling rounding for invoice-level tax data aggregation - Adding a second rounding test derived from bug ticket task-6009108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253305
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#110660 Forward-Port-Of: odoo/enterprise#106902
This update fixes a bug where project timesheets didn't accurately reflect changes in employee costs when switching workers on a manufacturing order. The fix automatically adjusts the AAL (analytic accounting line) linked to the work center, ensuring accurate timesheet calculations and reporting. This improves the reliability of project cost tracking.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#109695
This update resolves an issue preventing new employee creation when generating BVG-LLP reports in the Swiss module. The fix addresses a technical problem with how Odoo compares report data, ensuring correct employee creation functionality. This ensures accurate payroll calculations for Swiss companies.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335This update resolves an issue where tax calculations for invoices in Peru (PE) were incorrect due to a missing configuration. The team re-introduced a key element, 'TierRange,' within the tax category settings, ensuring accurate tax calculations for ISC (Impuesto Sobre la Renta) taxes on PE invoices. This ensures compliance and accurate financial reporting for our Peruvian customers.
Original PR description
In [^1] the PE implementation for XML generation was rewritten to use the new dict_to_xml design rather than a large QWeb view. In that refactor the `TierRange` key on `TaxCategory` was lost. This PR re-introduces it. task-6046603 [^1]: odoo/enterprise#87598 Forward-Port-Of: odoo/enterprise#111061