Wednesday, April 22, 2026
38 changes · saas-19.2
Enhancements to existing features
This update lets users split a manufacturing order into multiple smaller orders when generating serial numbers. It makes it possible to assign one serial number to each sub-order in a single workflow, which simplifies production for items tracked by serial number.
Original PR description
Since 4bb4e08066449, producing multiple serial that have been generated is only doable on one mo. We can split mo. we can generate serial number but we cannot do both at the same time. This commit adds a new button into the generate serial wizard to split the main mo into the number of serial wanted and attribute one for each sub mo. 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#257694 Forward-Port-Of: odoo/odoo#255577
Odoo now creates a local API key for each database during synchronization when one is missing. This reduces the need to rely on a shared global key and can make database updates noticeably faster, saving around half a second in some cases.
Original PR description
Before this commit, databases fetched from Odoo's SaaS were contacted using the global API key, which is more costly than using a key local to each database. Avoiding the call from the server to Odoo to check the foreign API key can spare about 500ms on each database where this key is not in the LRU. With this commit, after the synchronization with Odoo.com, we try to generate an API key on each database that doesn't have one yet. To do so, it relies on the API introduced by odoo/odoo#246118. Forward-Port-Of: odoo/enterprise#114406 Forward-Port-Of: odoo/enterprise#106372
Resolved issues and error corrections
Fixed an issue on invoices where choosing today’s date for a currency rate did nothing. Users can now select today and have the correct rate applied, making currency conversion selection behave as expected.
Original PR description
On an invoice, using the date picker to choose the currency rate did not allow picking today's date. Steps to reproduce: - Activate a currency - Add currency rate for today, yesterday and tomorrow - Create a new invoice - Select the newly activated currency - Pick yesterday's date - Pick today's date Current behavior: picking today's date close the date picker without doing anything Expected behavior: picking today's date close the date picker and apply today's currency rate (or latest if today's doesn't exist) Cause: The date picker was opened with today's date selected, preventing selecting it again. Opening the date picker with the right date selected isn't possible as we don't save the currency rate date. It would require doing a reverse search among the currency rate date which might be wrong as the currency rate can be customized. opw-6046169 Forward-Port-Of: odoo/odoo#258368
The currency rate service now uses a configurable timeout when contacting mindicador.cl instead of a fixed 30-second limit. This helps avoid missed daily exchange rate updates when the external service is slow, reducing gaps in stored currency rates.
Original PR description
The mindicador.cl provider had a hardcoded 30s timeout on its HTTP requests. The mindicador.cl service is sometimes slow around rate publication time, causing read timeouts that make the cron silently skip currency rate creation for the day due to HTTP Timeouts, leaving permanent gaps in res.currency.rate. Make the timeout configurable through the `mindicador_api_timeout` system parameter (defaults to the previous 30s). opw-6126027 Forward-Port-Of: odoo/enterprise#114153
This fix ensures that employee working schedule hours are recalculated when the day period is changed. It prevents errors in attendance views and keeps schedule data accurate after edits to lunch, morning, afternoon, or full-day periods.
Original PR description
Since #217895, `duration_hours` is now stored and needs to be recomputed when we change the attendance's `day_period` from lunch to morning/afternoon/full_day otherwise we will run into division by 0 in `_get_attendance_intervals_days_data`. ### Steps to reproduce 1. Change the day period of one of the working hours of a working schedule from Lunch to Morning. 2. Open the attendance overview including the attendances of an employee that has the working schedule from step 1. opw-6129881 Forward-Port-Of: odoo/odoo#259904
Mobile portal users can now upload files into shared document folders reliably. This fixes an issue where selecting a file did not complete the upload on phones because the upload menu closed too early.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Create a portal user and share a document folder with edit access 3. Log in as the portal user on a mobile device 4. Try to upload a document inside the…
Steps to reproduce:
1. Install `documents`
2. Create a portal user and share a document folder with edit access
3. Log in as the portal user on a mobile device
4. Try to upload a document inside the shared folder
Issue:
- After selecting a file from the file picker, the document is not uploaded.
Cause:
- On mobile in the portal flow, Upload is triggered from a nested dropdown (inside New) inside the adaptive control-panel dropdown (bottom sheet). By default, DropdownItem uses closingMode="all", so tapping Upload closes parent dropdowns immediately. That unmounts the hidden <input type="file"> before the OS file picker returns. When the user comes back, the input no longer exists, so change never fires and upload does not start.
- Admin/internal users do not hit the same nested adaptive-dropdown path in this view
Solution:
- Set closingMode="'none'" on the Upload DropdownItem so the menu stays mounted while the native picker is open. After a file is selected and onFileInputChange starts upload, close the bottom sheet programmatically with: `window.dispatchEvent(new Event("popstate"))`
opw-5937105
Forward-Port-Of: odoo/enterprise#108486This fix prevents an error when exporting the General Ledger for a Peruvian company that includes draft invoice entries. Users can now complete the export normally, even when some accounting entries are not yet finalized.
Original PR description
**Steps to reproduce:** - Install the `l10n_pe_reports_lib` module and switch to a `PE company`. - Create a draft invoice. - Navigate to Reporting > General Ledger. - Click the gear icon and select `Inventory and Balance`. **Error:** AttributeError: 'NoneType' object has no attribute 'replace' **Root Cause:** For draft entries, `move_name` is `None`, and calling `.replace()` on it causes an error at [1]. **Fix:** This commit prevents errors and ensures users can export the general ledger even when draft entries are included. [1]: https://github.com/odoo/enterprise/blob/5babcb5cb951e0e7beebdbef0781a20a7a19c319/l10n_pe_reports_lib/models/account_general_ledger.py#L168 opw-6104117 Forward-Port-Of: odoo/enterprise#113405
This change prevents access errors that could appear when users set or update suppliers in replenishment for products shared across multiple companies. It ensures only the appropriate company’s suppliers are used, so users can work without unexpected interruptions.
Original PR description
Issue before this commit: ------------------------------------------ In replenishment (multi-company setup), a 'read' access error occurs while setting the supplier, changing the replenishment unit,…
Issue before this commit: ------------------------------------------ In replenishment (multi-company setup), a 'read' access error occurs while setting the supplier, changing the replenishment unit, or changing the min/max when there are suppliers across multiple companies. Steps to reproduce: ------------------------------------------ 1. Install purchase_stock. 2. Create a storable product. 3. Add one vendor for company A and one vendor for company B. 4. Make sure that only company A is active. 5. Create an orderpoint for company A (min/max = 0) and set the route to 'Buy'. 6. Try to set the vendor. Notice that an access error occurs. Cause of the issue: ------------------------------------------ This issue occurs because the `seller_ids` cache gets polluted with suppliers from multiple companies. As a result, when `self.seller_ids` is accessed [1], it returns vendors from both active and non-active companies, ignoring the current company context. [1] https://github.com/odoo/odoo/blob/47deb9f13627a26d6a3179399bd965f639fde436/addons/product/models/product_product.py#L1016 Since users are not allowed to read records from non-active companies, this leads to a read access error when those supplier records are accessed. * Cause of the cache pollution: The cache gets polluted with records from another company because `product.seller_ids` [2] is accessed in a `sudo()` environment. This happens due to the `qty_to_order_computed` field, which is stored and computed. By default, stored computed fields use `compute_sudo=True`, causing the computation to run in a `sudo()` environment and cache cross-company sellers. [2] https://github.com/odoo/odoo/blob/d11b56f9272be39169d382007d19d63739617a8a/addons/purchase_stock/models/stock_rule.py#L169 Solution: ------------------------------------------ Filter the sellers in sudo mode as well, since the `seller_ids` cache will otherwise always be polluted due to the sudo environment. opw-6034990 Forward-Port-Of: odoo/odoo#259403
This update fixes an issue that could stop users from creating accrual entries after changing the review date. The system now handles the date consistently, preventing a type mismatch error and allowing the process to complete normally.
Original PR description
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the…
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the quantity to 1, and `confirm` it. - Navigate to Accounting > Review > `Billed Not Received`. - Change the `date` from the top left. - Select a record and click `Create Accrual Entries`. **Error:** `TypeError: '<=' not supported between instances of 'datetime.date' and 'str'` **Root cause:** At [1], the `accrual_entry_date` is set in the context as a `string`. Later, at [2], this value is retrieved from the context and used directly in a comparison with `ivl.date`, which is a `datetime.date`. **Fix:** This commit converts `accrual_entry_date` to a `datetime.date` object at [2], allowing users to create accrual entries without errors. [1]: https://github.com/odoo/enterprise/blob/3ab460a935c6caf013202ec6be1c3708178c8d7d/account_reports/static/src/views/accrual_list_controller.js#L61-L76 [2]: https://github.com/odoo/odoo/blob/7e17c788babc2715e85456467db9172bb0b8e42d/addons/account/wizard/accrued_orders.py#L166-L188 opw-6110907 Forward-Port-Of: odoo/odoo#260415 Forward-Port-Of: odoo/odoo#259047
When a vendor bill is created using Auto-complete from a previous bill, the Intrastat transaction information is now preserved on the new bill lines. This prevents missing reporting data and helps ensure EU trade declarations remain accurate without manual re-entry.
Original PR description
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to…
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to reproduce:** - Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`. - Create a vendor bill for an `EU partner`, add a product, and set an `Intrastat` (enable from the optional column if needed). - `Confirm` the bill and note its number. - Create a new vendor bill for the `same partner`. - Use the `Auto-complete` feature by selecting the previous bill. - Check the invoice lines. **Observation:** The `Intrastat` is missing from the generated invoice lines. **Root Cause:** - On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] copies invoice lines using `copy_data()`. - However, in `account_intrastat`, `copy_data()` at [2] removes `intrastat_transaction_id`. **Fix:** This commit ensures that `Intrastat` is properly set when creating a vendor bill using the auto-complete feature based on a previously created vendor bill for an EU customer. [1]: https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820 [2]: https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83 opw-5936869 Forward-Port-Of: odoo/enterprise#114520 Forward-Port-Of: odoo/enterprise#112857
This fix prevents the IoT box from overwriting a printer’s manually chosen subtype when devices are sent again after a restart. As a result, user settings stay intact and the printer keeps the correct configuration instead of reverting unexpectedly.
Original PR description
Steps to reproduce: 1. Connect a printer to the IoT box and pair with a DB 2. Manually change the subtype of the printer in the DB 3. Restart the IoT box so it resends its devices. **Expected behaviour**: Subtype remains as the user-set value. **Actual behaviour**: Subtype is reset to the original value. To fix this issue, we simply remove any check for subtype in the device updating condition. Now, a device will only reset if its type changes. Forward-Port-Of: odoo/enterprise#114416
This update removes a duplicate credit note selection in the Colombian e-invoicing setup. It prevents an error that could stop the invoice form from opening correctly when creating a credit note.
Original PR description
The `l10n_co_edi_operation_type` field on `account.move` had two entries with the same selection value `'23'`:
('23', 'Nota Crédito para facturación electrónica V1 (Decreto 2242)'), ('23', 'Inactivo: Nota Crédito para facturación electrónica V1 (Decreto 2242)'),
This caused an OWL crash when opening the invoice form:
"Got duplicate key in t-foreach: 23"
__Steps to reproduce:__
1- Install the l10n_co_edi module
2- switch to colombian company
3- Activate the developer mode
4- Go to Credit Note > Create
__NOTE__: The javascript error is only visible on version 18.4 but the duplicate selection is present since 17.0.
opw-5969595
Forward-Port-Of: odoo/enterprise#112841This change updates the packaging setup so Windows builds include the optional dependencies they need. It helps prevent installation or runtime issues for users deploying Odoo on Windows.
Original PR description
Forward-Port-Of: odoo/odoo#258320 Forward-Port-Of: odoo/odoo#258128
Self-billed invoices are now matched to the correct company when multiple companies are registered on Peppol. This prevents invoices from being assigned to the wrong business entity and helps keep accounting records accurate.
Original PR description
Currently, if a database has multiple companies registered on Peppol, receiving a self-billed invoice may assign it to the wrong company. The system was searching the journal using a domain that included all companies (in self), instead of filtering by the correct current company. Steps to reproduce: - Create a database with 2 companies, both on Peppol - Receive a self-billed invoice from a random other company on Peppol - The received invoice will potentially be assigned to the wrong company This is only a test forward-port of #257380 opw-6045669 Forward-Port-Of: odoo/odoo#259524 Forward-Port-Of: odoo/odoo#259072
Images added to the company document layout now print correctly even when their width is set as a percentage. This prevents logos or other inserted images from disappearing in PDF output, improving the reliability of printed documents.
Original PR description
Problem: When adding an image in the `company_details` field via **Settings > Configure your document layout** and resizing it to a percentage width (e.g. 50%), the image is not visible when printed. Cause: Since fa55c2d1, `wkhtmltopdf` fails to correctly calculate percentage-based image widths because none of the ancestor elements have an explicit width defined. Solution: Force the wrapping table to `width: 100%`, giving `wkhtmltopdf` a concrete width to resolve percentage values against. Steps to reproduce: - Go to **Settings > Configure your document layout** - In the address field, add an image via `/media` - Resize the image to 50% - Print the document - Image is missing in the PDF output opw-6102568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259077
This update fixes the exemption code and exemption reason used for the Belgian 0% S tax. It helps ensure invoices and tax reporting use the correct legal classification, reducing the risk of incorrect records or submissions.
Original PR description
The tax 0% S had a wrong tax exemption code and tax exemption reason. This commit corrects it. Task-6127195 Forward-Port-Of: odoo/odoo#259639
Fixed an issue in the Time Off Gantt multi-create flow where the Time Off Type dropdown could appear empty after selecting multiple dates. The form now correctly refreshes its fields, so users can choose the right time off type and create requests smoothly.
Original PR description
**Steps to Reproduce:** 1. Open Time Off App->Management->Time Off->Gantt View 2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set". 3. Open the "Time Off Type"…
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown. The dropdown appears empty.
**Bug Cause:**
When forceFullDuration is true and request_duration is pre-populated in initial values, the form detects no field changes and skips triggering onchange. This prevents computed fields like allowed_work_entry_type_ids from being evaluated, resulting in an empty domain filter ('id', 'in', []).
**Solution:**
Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option.
By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option. By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the allowed_work_entry_type_ids correctly.
**Task:** 6109569This update corrects how Belgian NISS "bis" numbers are read when deriving an employee’s birth date. It prevents invalid dates from being generated, which helps payroll data stay accurate and avoids errors during processing.
Original PR description
…fset) in birthday parsing The NISS month field can be increased by 20 or 40 for "numéros bis". This caused invalid date parsing. Use modulo 20 to normalize the month before constructing the birthday. task-6144297
Copying a helpdesk ticket no longer fails for users who do not have stock permissions. The system now avoids carrying over a stock-related product when duplicating the ticket, so business users can duplicate records normally.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#114266 Forward-Port-Of: odoo/enterprise#101338
This update prevents loyalty points from being incorrectly rounded down when a company uses a currency with a large rounding factor. As a result, point-based reward programs will work as expected and rewards will remain claimable, while money-based programs still use currency rounding where appropriate.
Original PR description
`_get_real_points_for_coupon` was unconditionally rounding points using `coupon.currency_id.round()`, which uses the currency's rounding factor as a precision unit. For point-based programs (e.g. 1 point per order), a currency with a large rounding factor (e.g. 10) would round 1 point down to 0, making all rewards unclaimable. Currency rounding is only semantically correct when points represent monetary amounts, which is the case when `reward_point_mode == 'money'` (gift_card, ewallet, and money-mode loyalty programs). For all other programs, points are dimensionless and should not be subject to currency precision rules. opw-6111622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259660
This change reverts a previous adjustment that affected how child contact names were shown. It helps ensure invoices and related documents display contact information in the expected way, reducing confusion for customers and internal teams.
Original PR description
This reverts commit 0ef4c1d06fdf999ad5cdad696069aec8f2f943c5. opw-5900567 Forward-Port-Of: odoo/odoo#260186 Forward-Port-Of: odoo/odoo#260065
Imported XML attachments are now kept linked in a safer way so they can still be opened when needed. This prevents access errors when users view bills created from email imports, especially in Mexican e-invoicing flows.
Original PR description
When importing files (manually or from email alias), we unattach the xml files, it can lead to access error in some flows like with l10n_mx_edi Steps to reproduce the flow that triggered the bug: - Install l10n_mx_edi and select MX company - Create an email alias for purchase journal - Receive email with xml file - Create a user with 'group_user' role, 'Administrator' accounting access rights - Login with this user and open the created bill -> Access Error This is because we unattach xml attachmentss when importing them, by setting `res_id` to 0 and `res_model` to False. The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via `_get_mail_thread_data_attachments` which lead to an access error during the `fetch` method opw-5953578 Forward-Port-Of: odoo/odoo#260127 Forward-Port-Of: odoo/odoo#259095
When a packed item is scanned with GS1 information, the system now correctly keeps the due date instead of defaulting to today. This ensures newly created lots carry the right expiration information, reducing manual corrections and avoiding mistakes in shipping and inventory records.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#114327
Forward-Port-Of: odoo/enterprise#112490This change keeps message text readable when users click into a communication box in Helpdesk and related areas. It ensures the text color stays correct even after the field gains focus, which prevents white text from appearing on a white background in dark-themed websites.
Original PR description
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to…
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to reproduce - Install the Helpdesk app - Go to Website > Help - Submit a ticket (the ticket's information is not important) - Click the ticket link shown when the ticket is submitted - Start writing a message in the Communication History. # The problem As long as the text bubble is focused, the text is white even though the bubble is also white, making the text unreadable. Note : the same problem is present for product reviews in the eCommerce application. These text bubbles seems to be intended to stay white even in a dark main background color, so the text should be black : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/composer.scss#L103 # Cause The textarea (text bubble) has a the `.form-control` css class coming from bootstrap that applies `color: var(--bs-body-color)` : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2115-L2131 In our case, it sets `color` to #FFF (I'm not 100% sure where this value is coming from since I did not find any instance where --bs-body-color or --body-color are ever set to that value). Anywyay, this value is overidden by `.o-discuss-text-body`: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/core.scss#L99-L101 But the value is overriden again when the textarea is focused by the `form-control:focus` css class that sets back the color to #FFF: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2143-L2149 The issue was caused by this commit that changed the class used to define the color for the discuss messages : https://github.com/odoo/odoo/commit/3557de4232ebc307c8861379f6573d7b36cd8db6 Because `.o-discuss-text-body` is overriden by `form-control:focus` while `.text-body` is not. This is most probably due to the order in which the stylesheets are applied. # Proposed solution Add `, .o-discuss-text-body:focus` to make sure the rule is also applied when the text bubble is focused opw-6063961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258142
This update prevents an error that could occur when the Purchase app is installed after Accounting on older database versions. It makes the purchase invoice view more resilient so users can continue installing and using modules without the setup failing.
Original PR description
c5ac4867fb708c56aa74e38508347660f1875dd3 added back the computed fields `invoice_vendor_bill_id` and `purchase_vendor_bill_id` on `account.move` in stable. The issue is that the view on purchase expects the view on account to have `invoice_vendor_bill_id` in it. But if a user already had `account` installed before the commit, then install `purchase` after, the purchase view will raise an exception as it expects `invoice_vendor_bill_id` in the view of account. The fix here is to not reference `invoice_vendor_bill_id` in the purchase view and compute its visibility with a non-stored computed field.
This change fixes an error that could happen when opening account report information. It ensures the report uses the correct way to update internal report data, so users can view reports without interruption.
Original PR description
Currently, an error occurs when retrieving account report information. ``` File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy…
Currently, an error occurs when retrieving account report information.
```
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy
render_lines(root_account_groups, current_level, root_line_id, skip_no_group=False)
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1373, in render_lines
child_line.update
^^^^^^^^^^^^^^^^^
AttributeError: 'AccountReportLineData' object has no attribute 'update'
```
After the [recent commit], all lines, columns, format_params, and annotations are converted into custom objects (AccountReportLineData). However, the code still attempts to use the update() method on these objects, which raises an error [1] since AccountReportLineData does not have an update method.
This commit ensures that the update_value() method is used to update AccountReportLineData objects, as intended, like here [2].
[recent commit]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420
[1]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L1373-L1377
[2]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L6565
sentry-7403925422This update improves how the editor handles content inside inline code. It prevents formatting tools from appearing when text is fully inside code, and makes pasted content inside code insert as plain text so the result stays consistent. When a selection includes both code and normal text, formatting is now applied only to the normal text, reducing unexpected changes while editing.
Original PR description
### Purpose of this commit: - Prevent the powerbox and toolbar from opening when the selection is fully inside inline code. When the selection spans inline code and regular text, keep the toolbar visible but ensure formatting commands are applied only to the non-inline-code content. - Ensure that pasted external and editor HTML is converted to plain text when inserted inside inline code. task-5502939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258781 Forward-Port-Of: odoo/odoo#250911
This fix ensures product prices are converted from each product’s own currency to the Point of Sale currency, instead of assuming they were always in the company currency. As a result, prices shown and charged in multi-currency setups will be more accurate and consistent at checkout and on receipts.
Original PR description
Before this commit, in a multi-currency environment, the company currency was used to convert the prices, while it was a wrong assumption that the product prices were in the company currency. The products have a currency_id field, and the price should be converted from that currency to the PoS config currency. opw-6065969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257324
Downloading receipts for kiosk self-order POS orders could fail with an error in some cases. This fix prevents that error so receipts can be opened and downloaded normally.
Original PR description
Currently an error occurs when the user tries to `Download Receipt` of self-orders as the following steps: - Install the pos_self_order module - Create a new POS shop with `Self Ordering` as `Kiosk` - Add Online `Payment Methods` on the above POS shop - Make an order from kiosk mode - Go to Point of Sale > Orders > Orders - Open the recent order which was created from the kiosk. - Click `Download Receipt` > Error Error: `QWebError:Error while rendering the template: AttributeError: 'bool' obje...` This issue occurs because, while rendering pos_order_receipt_header`, the `preset` value is `False`. Attempting to call `.get()` on a falsy value leads to an error. This commit fixes the issue by accessing `preset` only when it is available, preventing errors during rendering. sentry-7402711985
This change filters out characters that are not accepted by the Swiss QR-bill standard before generating QR codes. It helps prevent bank rejections caused by unsupported Unicode characters in payment references or addresses.
Original PR description
**Description of the issue/feature this PR addresses:** QR code is rejected by the bank, when it contains an invalid character `U+202F`. **Current behavior before PR:** Unauthorized Unicode characters are encoded in the QR-Bill, and it is rejected on the receiving part. **Desired behavior after PR is merged:** Any Unicode codepoint which is not in the subset of 324 allowed codepoints has to be filtered out. > spec of QR-bill allows only a subset of characters, a precise list of 324 Unicode codepoints (section 4.1.1, page 30 of the Swiss Implementation Guidelines for the QR-bill) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258680 Forward-Port-Of: odoo/odoo#254980
This update fixes an issue where clicking certain cells in the Trial Balance report could fail for Undistributed Profits/Losses. As a result, users can open the related details normally without encountering an error.
Original PR description
This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report. Steps to reproduce: - Install `Accounting` module - Create `Journal Entry` with past-year…
This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report. Steps to reproduce: - Install `Accounting` module - Create `Journal Entry` with past-year `Accounting Date` (eg: 31-12-2025) and include one `Journal Items` for `Undistributed Profits/Losses` - Open `Trail Balance` report and click on any cell for `Undistributed Profits/Losses` Traceback: `KeyError: 'report_line_id'` Before this [commit], we were returning fields with `null/None` values. After the commit, fields containing `null/None` [value] are removed, and only fields with valid values are returned. As a result, when the `dispatch_report_action` function is called, the `report_line_id` is missing in `params`. [commit]: https://github.com/odoo/enterprise/pull/102808/changes/b92dc397bef029472a40223f51b611cdf5b631dc [value]: https://github.com/odoo/enterprise/blob/626b8157bcea2e3843cd9d5d0c0036e302b8e5ce/account_reports/utils/report_data_objects.py#L42-L43 sentry-7372351871 opw-6119913
This update makes salary and mobility budget calculations behave more consistently. Changes made in the backend or to employer cost now only affect the wage itself, instead of unexpectedly altering other benefits; the full adjustment logic remains available in the salary configurator.
Original PR description
For consistency purposes, we only trigger the inverse on the mobility budget computation if we are in the context of the salary configurator. Changing the wage in the back end or changing the employer cost should only touch the wage and not other benefits Forward-Port-Of: odoo/enterprise#111828
When a product belongs to categories used on multiple websites, the site now chooses a category that is accessible on the current website. This prevents customers from clicking a breadcrumb link and landing on a 404 page when browsing a different website.
Original PR description
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two…
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two Ecommerce categories with the same name, one assigned to Website 1 and the other to Website 2. 2. Create a product and assign both categories to it. 3. On Website 1, navigate to the product page and click the category breadcrumb → works correctly 4. On Website 2, navigate to the same product page and click the category breadcrumb → **404 error** Cause: ====== In `_prepare_product_values`, when no category is passed in the URL, the fallback was: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/website_sale/controllers/main.py#L802 This blindly picks the **first** category from the product's public categories without checking which website it belongs to. If the first category (by ID order) belongs to Website 1, it gets used even when the user is browsing Website 2. The breadcrumb then generates a slug pointing to Website 1's category. When clicked on Website 2, `can_access_from_current_website()` fails for that category, resulting in a 404. Solution: ========= Filter `public_categ_ids` through `can_access_from_current_website()` before selecting the first one. opw-6070191 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258336
This change fixes an issue that could prevent certain sales-related email templates from being saved correctly in the editor. It makes the template content stay in a valid structure during editing, so users no longer run into unexpected save errors.
Original PR description
**Steps to reproduce:** - Install sale / website_sale - In debug mode, go to Settings app - Go to Technical > Email > Email Templates - Try to edit and save "Sales: Order Confirmation" or "Ecommerce:…
**Steps to reproduce:**
- Install sale / website_sale
- In debug mode, go to Settings app
- Go to Technical > Email > Email Templates
- Try to edit and save "Sales: Order Confirmation" or "Ecommerce: Cart Recovery"
- QWebError is raised: 'IndentationError: unexpected indent'
**Issue:**
Before a `mail.template` is rendered in the html editor it must be valid html (even if they contains qweb elements) to avoid the browser silently moving elements around to match its specifications (and breaking template logic). This is also what happens with `DOMParser.parseFromString` function.
e.g. the browser moves html elements out of the parent `<table>` if they are not the children of a `<tr>` `<td>`.
```xml
<table>
<t t-foreach=...>
<tr>
<td>1</td>
</tr>
</t>
</table>
```
Becomes:
```xml
<t t-foreach=...>
</t>
<table>
<tbody>
<tr>
<td>1</td>
</tr>
</tbody>
</table>
```
**Fix:**
The template is still working if not edited, but we need to ensure the template `body_html` is valid html to avoid the hierarchy modification.
related: https://github.com/odoo/odoo/commit/dbd8b879fd95f3e913e1c777cb8619c4e0673b03
similar issue: https://github.com/odoo/odoo/pull/259548
opw-6055026This update fixes an accounting issue where invoices for kits could miss the cost of goods sold entry if one or more kit components were removed from the delivery. It now records the cost based on the components that were actually delivered, which keeps invoice accounting accurate and more reflective of the real shipment.
Original PR description
Steps to reproduce: - Create a kit with 3 or more components - Create a sales order with the kit and confirm it - Remove at least one of the kit's components from the delivery and validate it - Create the invoice from the sales order and confirm the invoice - Check the journal entries included in the invoice form Current behavior: - There is no COGS entry Expected behavior: - There should be a COGS entry Context: In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount. opw-6082565 Forward-Port-Of: odoo/odoo#259875 Forward-Port-Of: odoo/odoo#258982
When users select all documents across multiple pages and open the Share action, the system now correctly applies permission changes to every selected document, not just the ones visible on the current page. This prevents incomplete sharing updates in large document lists.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload more than 80+ files (max page size is 80) - Use the checkbox to select all files on the page - Click the 'Select All' button in the control panel to select allfiles - Use Share action button - Pop-up only takes the current page into account - Rights modifications will not be applied on remaining records **Issue:** `onShare()` only takes current records into account even if the full selection was applied. **Fix:** Fetch all document ids (if needed) before opening the dialog. opw-5957777 Forward-Port-Of: odoo/enterprise#110299
The annual tax report now handles comparison values more safely, even when the report contains text entries. This prevents a crash when users compare the report with one previous period, so the comparison view opens normally.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#113330 Forward-Port-Of: odoo/enterprise#112619
This change prevents an error that could appear when users add task dependencies from the mobile Project view. It ensures the correct part of the screen is updated, so the action works reliably on mobile devices.
Original PR description
Steps to reproduce: - Install Project - Create a project and a task and enable task dependencies - In mobile view, go to the "Blocked by" tab and click "Add" Issue: A traceback occurs in the mobile view. Cause: In this pr https://github.com/odoo/odoo/pull/230738 parent_id was moved inside anchor element. Fix: Update the XPath to correctly replace the element containing parent_id. task-6009997 Forward-Port-Of: odoo/odoo#252804