Tuesday, April 21, 2026
25 changes · 19.0
Resolved issues and error corrections
Peppol XML documents that include an embedded PDF now show the expected PDF thumbnail instead of raw XML content or an error. This makes invoice and document review smoother for users working with electronic billing files in Documents.
Original PR description
**Steps To Reproduce** - Go to Documents app - Upload a Peppol XML file containing an embedded PDF (e.g., invoice with attached PDF) - Open the document **Issue** Opening a Peppol XML document with…
**Steps To Reproduce** - Go to Documents app - Upload a Peppol XML file containing an embedded PDF (e.g., invoice with attached PDF) - Open the document **Issue** Opening a Peppol XML document with an embedded PDF causes: `UserError: Only PDF files can have a thumbnail` The kanban view also shows raw XML code instead of the PDF preview. **Cause** Since this commit: https://github.com/odoo/odoo/commit/37e38b8cd34e The mail module's `mail_attachement_update_thumbnail` route has a strict mimetype check that rejects thumbnail updates for XML files: https://github.com/odoo/odoo/blob/c350592b85001b5f36ea6aaf803ee3974e5ebfc1/addons/mail/controllers/attachment.py#L146-L147 Additionally, the documents thumbnail service only generates thumbnails for files where `isPdf()` returns true: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/static/src/views/helper/documents_client_thumbnail_service.js#L27-L35 **Solution** Add `_allow_thumbnail()` hook to allow overriding the mimetype check And from this PR, I see that a proper thumbnail is the proper behavior: https://github.com/odoo/enterprise/pull/49111 Which required the thumbnail generation flow multiple overrides: 1. **`isPdf()` check**: The documents thumbnail service only generates thumbnails for files where `isPdf()` returns true. XML files return false, so thumbnail generation is never triggered: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/static/src/views/helper/documents_client_thumbnail_service.js#L28-L35 2. **`pdf_first_page`**: When thumbnail generation runs, it fetches the first page of the PDF via these routes. For XML with embedded PDFs, the routes must extract and return the embedded PDF bytes instead of the raw XML content: https://github.com/odoo/odoo/blob/c350592b85001b5f36ea6aaf803ee3974e5ebfc1/addons/mail/controllers/attachment.py#L120-L127 https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/controllers/documents.py#L515-L528 3. **`isTextualDocument` in kanban**: XML files are treated as textual documents and displayed showing raw XML code, even when they contain an embedded PDF that should be previewed instead: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/views/documents_document_views.xml#L106 opw-5252946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Peppol integration now uses the 0208 identifier instead of 9925 as the primary identifier. This helps customers stay aligned with current regulatory requirements for electronic invoicing.
Original PR description
Due to many users using 9925 as their main Peppol identifier, we need to switch it to 0208 to comply with regulations. task-5463018 related PRs: https://github.com/odoo/iap-apps/pull/1360
This fix ensures self-billed Peppol invoices are assigned to the correct company when multiple companies use Peppol in the same database. It prevents invoices from being routed to the wrong company, reducing accounting confusion and manual corrections.
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#259072
Product pages now choose a category that belongs to the website the customer is currently browsing. This prevents shoppers from hitting a 404 error when clicking category breadcrumbs on products shared across multiple websites.
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
Peppol invoice XML generation now keeps unit prices consistent with the amounts used to calculate invoice line totals. This prevents valid invoices with many decimal places from being rejected during Peppol validation.
Original PR description
**PROBLEM** Previously, we rounded the unit price up to 6 digits in the generated xml for peppol. However, odoo compute the lineExtensionAmount with the raw unit price. The generated xml is invalid because `priceAmount*InvoicedQuantity != LineExtensionAmount`. **STEP TO REPRODUCE** 1. Create an invoice with unit price of 0.01110515964, and quantity of 278362.5. 2. Generate an XML with peppol, and try validating the invoice. You should have the following error: `[PEPPOL-EN16931-R120]-Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount` opw-6009771 Forward-Port-Of: odoo/odoo#259759 Forward-Port-Of: odoo/odoo#255358
When customers confirmed sales orders through the portal, Odoo could use the wrong company's project template for service products in multi-company setups. This fix ensures the correct company context is used, preventing confirmation errors and creating projects for the intended company.
Original PR description
[FIX] sale_project: Multi-Comp. Product creates comp-specific projects project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company. Following examples earlier in the function, call `.with_company` while accessing project_template_id. Steps to reproduce: 1. Install Sales and Project 2. Create second company 3. Create Customer with portal access, under created company 4. Create service product with different projects for each company 5. Create sales order with customer and service product, send to customer 6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes Odoo's spreadsheet component and includes several fixes that improve day-to-day reliability. Users should see fewer crashes with pivot data, steadier chart panel behavior, safer copy/paste handling, and better consistency when clearing formatting in shared spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b0ce391ef8 [REL] 19.0.30 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b0ce391ef8 [REL] 19.0.30 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/aaff7031fa [IMP] package: backport rolldown and TS 6.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/18e934bec2 [IMP] typescript: upgrade to 6.0.2 [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/7c6ee698ca [FIX] package: add rolldown binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4bd37ce8d0 [IMP] package: upgrade rolldown to latest version [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/3c7beef8f4 [IMP] config: rename rolldown config file [Task: 6071659](https://www.odoo.com/odoo/2328/tasks/6071659) https://github.com/odoo/o-spreadsheet/commit/5cfca4dd5a [IMP] config: replace rollup with rolldown [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/077ac1b251 [IMP] eslint: enforce type exports [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/421be34699 [IMP] pre-commit: bypass eslint's typescript compilation [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/e1359d35e9 [IMP] tsconfig: moduleResolution bundler [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/39d5bc36d9 [FIX] spreadsheet_pivot: avoid crash on invalid dimension values [Task: 6111913](https://www.odoo.com/odoo/2328/tasks/6111913) https://github.com/odoo/o-spreadsheet/commit/e357c8d07f [FIX] side_panel: prevent chart picker layout shift on hover [Task: 6095239](https://www.odoo.com/odoo/2328/tasks/6095239) https://github.com/odoo/o-spreadsheet/commit/4c3577ede2 [FIX] clipboard: prevent cross-version copy/paste [Task: 6095101](https://www.odoo.com/odoo/2328/tasks/6095101) https://github.com/odoo/o-spreadsheet/commit/a83a722331 [IMP] tests: add tests for `chartShowValuesPlugin` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/a5923f66fd [FIX] computed style: fix multi-user clear formatting [Task: 6086129](https://www.odoo.com/odoo/2328/tasks/6086129) 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 fix prevents an error that blocked users from creating accrual entries after changing the date in the Billed Not Received review. It ensures the selected date is handled correctly, so accounting teams can complete accrual processing reliably.
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
The Discuss call menu now includes a Picture-in-Picture option, making it easier for users to keep a call visible while moving to other conversations or records. The update also fixes faded menu actions so Fullscreen and Picture-in-Picture appear clearly in the call menu.
Original PR description
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of…
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of Discuss is to join a call, switch to another conversation or chatter, and then wanting to keep an overlay of the call. Without the "Picture-in-Picture" in Call Menu, this forces user to access the Discuss conversation again and then click on "Picture-in-Picture" there, when clicking on the call menu would be faster. This commit adds the "Picture-in-Picture" action in the call menu to ease using this feature. Also fixes an issue where "Fullscreen" and "Picture-in-Picture" actions have reduced opacity in the Call Menu. This comes from opacity hover effect that should be limited to their inline visual in the Call view but was mistakenly also present in the dropdown. Before / After <img width="440" height="369" alt="Screenshot 2026-04-17 at 14 15 58" src="https://github.com/user-attachments/assets/2accb779-28f5-4930-a101-db5e52b029b7" />
Manual capture and void actions for Adyen payments now send the original payment reference required by the provider. Follow-up status updates are also applied to the correct follow-on transaction, preventing payments from remaining stuck in draft.
Original PR description
Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen…
Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen payment provider. 2- Enable `Capture amount manually`. 3- Create a SO and confirm. 4- Generate a payment link and pay. 5- In SO, capture the full amount. Cause: --- After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created. However the child tx is missing the `provider_reference` required to send the payment provider. Issue 2: --- The child tx created for capture/void is always remains in draft state. Cause: --- This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed. opw-6120846 opw-6120071
This fixes an issue where some loyalty rewards could become impossible to claim when a currency used large rounding increments. Currency rounding now applies only to money-based rewards, so point-based loyalty programs keep the correct point balance.
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
Fixes an issue where mentioning roles in the full email composer could send messages to the wrong address or no address, and show an incorrect link. This helps ensure role-based notifications reach the right people and display accurate information.
Original PR description
There is an issue when tagging a role using the full composer: 1. Emails are sent to the wrong address or sometimes no address at all 2. The displayed URL is not correct This commit fixes the issue by correctly rendering the mention block for roles in the full composer, using the correct configuration. task-6139162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now buy event tickets in Point of Sale when multi-slot events are configured with unlimited capacity. Previously, these unlimited slots were treated as unavailable, incorrectly blocking sales with a fully booked message.
Original PR description
**Steps to reproduce:** - Make an event, put it to announced state - Allow multi slots and create a product - Go to the pos and try to order it - "All slots are booked out for this event" appears **Why the fix:** When we set 0 as a maximum quantity for an event slot, the quantity is unlimited, in the code, the availability is set to a string "unlimited". This was not taken into account in the case of multi slots, as we only checked if the availability was a number greater than 0. As "unlimited" is not a number, we thought we didn't have any slots available and returned the error that said all slots were full. We now add the unlimited tickets to the availability list. opw-6006696 Forward-Port-Of: odoo/odoo#254220
Projects created from sales orders now keep the correct billable setting and sales order link. Project template choices are also limited to the relevant company or shared templates, preventing users from selecting templates from another company.
Original PR description
Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project --------------------- **Issue:** When a project is created from the sale app, it is not billable by default,…
Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project --------------------- **Issue:** When a project is created from the sale app, it is not billable by default, and the sale order / sale order line are not set. **Fix:** Remove default_allow_billable = False in the Create a Project **Note:** default_allow_billable = True already exists in action_view_project_ids, but that default context is replaced when opening the project directly from the view. This happens because default_allow_billable = False is set in the Create a Project action. Fix 2: sale_project: show only relevant project templates per company ---------------- **Steps:** - Install sale_project - Create two companies (A, B) - Create three project templates: - Template A (company A) - Template B (company B) - Template C (no company → visible to all) - Create a sale order for company A with a service product - Confirm the sale order - Create a project and try to select a template **Issue:** All project templates were visible even if the sale order had a company set. **Fix:** Added a filter (domain) on the project template field so only templates for the sale order’s company or templates with no company are shown. Users cannot select templates from other companies. task-5074893
This fix prevents incorrect cost-of-goods-sold entries when products use different units of measure or when customer returns move through multiple stock steps. It helps keep sales margins and accounting valuations accurate when invoices are posted.
Original PR description
[FIX] sale_stock: convert quantity using correct UoM The quantity unit conversion was applied to an already summed value, ignoring the fact that individual COGS lines may have different UoMs. --- [FIX] stock_account: Do not copy field 'value' of StockMove When a customer return is split into multiple steps (e.g., Customer -> Input -> Stock), the `value` field of the stock move was being copied from the first step to the second. This caused the second step (which should not be valued) to inherit the monetary value, leading to incorrect COGS entries when the invoice was posted. The value should only be set when the move is Done, not during a copy. --- OPW-6076350 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents replenishment screens from showing access errors when products have vendors linked to multiple companies. Users working in one active company can now set suppliers and adjust replenishment quantities without being blocked by vendors from another company.
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
Inter-company delivery and receipt returns now reverse the same stock interim account used by the original transaction. This prevents returns from being posted to the wrong stock account, improving accuracy in inventory valuation and financial reporting.
Original PR description
### Problem: When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to…
### Problem:
When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to another company will debit the stock output account, but returning the delivery will create an account move that credits the stock input account. Compare this to normal return behavior which will credit the stock output account to reverse the original delivery's entry.
### Solution:
When deciding whether a stock move is a return, we will include transit locations as valid locations.
### Steps to reproduce (Runbot v18)
- Automatic accounting
1. Create a SO for the automatically accounted product, selling to another company in the system
2. Validate the delivery, check the valuation and note there is a debit on the stock output account
3. Create a return for the delivery and validate it, check the valuation and note the credit on the stock input account
To clarify, this differs from when the customer on the SO is anything other than a res.company, where we will see a credit on the stock output account when the return is validated.
Also, this flow is the same for POs, and the same bug is addressed by this fix.
### Before
<table>
<th>Move type</th>
<th>Account</th>
<th>Debit</th>
<th>Credit</th>
<tr>
<td>Delivery</td>
<td>Stock output</td>
<td>100</td>
<td>0</td>
</tr>
<tr>
<td>Delivery Return</td>
<td style="{color: red}">Stock input</td>
<td>0</td>
<td>100</td>
</tr>
</table>
### After
(Or normal behavior without inter-company transfer)
<table>
<th>Move type</th>
<th>Account</th>
<th>Debit</th>
<th>Credit</th>
<tr>
<td>Delivery</td>
<td>Stock output</td>
<td>100</td>
<td>0</td>
</tr>
<tr>
<td>Delivery Return</td>
<td>Stock output</td>
<td>0</td>
<td>100</td>
</tr>
</table>
opw-5993147
Forward-Port-Of: odoo/odoo#259703
Forward-Port-Of: odoo/odoo#255439This fixes an issue where shoppers could not increase the quantity of certain combo products beyond one, even when stock was available. Online stores can now sell the correct available quantity for combo products while still respecting out-of-stock restrictions.
Original PR description
You cannot increase the quantity of a combo product that has options with Sell when Out-of-Stock disabled Steps to reproduce: 1. Install Inventory and eCommerce 2. Go to Website > eCommerce > Products and create a new product "Combo" 3. Set the Product Type to Combo, create and edit a Combo Choice "test" with two options "test 1" and "test 2". Both have Track Inventory enabled, 5 Quantity On Hand and Sell when Out-of-Stock disabled 4. Publish product "Combo" to the website 5. Click on smart button "Go to Website" to open the shop page of product "Combo" 6. Try to increase the quantity 7. The quantity is limited to 1 Solution: Always set the quantity input's maximum when `has_max_combo_quantity` is true Issue: We only set the quantity input's maximum if `allow_out_of_stock_order` is false This error was introduced in https://github.com/odoo/odoo/commit/0247538efe788a9ff9a4d58f64470325348a4eaa opw-6050876
This fixes an issue where XML files imported for vendor bills could become detached from the related record, causing access errors in some electronic invoicing flows such as Mexican localization. Keeping the XMLs properly linked helps accounting users open and process imported bills reliably.
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#259095
Opening a Peppol XML file that contains an embedded PDF now displays the PDF preview instead of showing raw XML or an error. This makes invoice documents easier to review in Documents and prevents the thumbnail generation from failing for this common file type.
Original PR description
**Steps To Reproduce** - Go to Documents app - Upload a Peppol XML file containing an embedded PDF (e.g., invoice with attached PDF) - Open the document **Issue** Opening a Peppol XML document with…
**Steps To Reproduce** - Go to Documents app - Upload a Peppol XML file containing an embedded PDF (e.g., invoice with attached PDF) - Open the document **Issue** Opening a Peppol XML document with an embedded PDF causes: `UserError: Only PDF files can have a thumbnail` The kanban view also shows raw XML code instead of the PDF preview. **Cause** Since this commit: https://github.com/odoo/odoo/commit/37e38b8cd34e The mail module's `mail_attachement_update_thumbnail` route has a strict mimetype check that rejects thumbnail updates for XML files: https://github.com/odoo/odoo/blob/c350592b85001b5f36ea6aaf803ee3974e5ebfc1/addons/mail/controllers/attachment.py#L146-L147 Additionally, the documents thumbnail service only generates thumbnails for files where `isPdf()` returns true: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/static/src/views/helper/documents_client_thumbnail_service.js#L27-L35 **Solution** Add `_allow_thumbnail()` hook to allow overriding the mimetype check And from this PR, I see that a proper thumbnail is the proper behavior: https://github.com/odoo/enterprise/pull/49111 Which required the thumbnail generation flow multiple overrides: 1. **`isPdf()` check**: The documents thumbnail service only generates thumbnails for files where `isPdf()` returns true. XML files return false, so thumbnail generation is never triggered: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/static/src/views/helper/documents_client_thumbnail_service.js#L28-L35 2. **`pdf_first_page`**: When thumbnail generation runs, it fetches the first page of the PDF via these routes. For XML with embedded PDFs, the routes must extract and return the embedded PDF bytes instead of the raw XML content: https://github.com/odoo/odoo/blob/c350592b85001b5f36ea6aaf803ee3974e5ebfc1/addons/mail/controllers/attachment.py#L120-L127 https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/controllers/documents.py#L515-L528 3. **`isTextualDocument` in kanban**: XML files are treated as textual documents and displayed showing raw XML code, even when they contain an embedded PDF that should be previewed instead: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/views/documents_document_views.xml#L106 opw-5252946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A typo in the quality module prevented newly created quality alerts from being assigned to the correct stage, causing them to appear under "None". This fix restores the proper grouping so records are shown where users expect them.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016)
Companies that use Belgian taxes through a Belgian fiscal position can now see the Intervat settings in the configuration screen. This fixes a blocker where the settings could not be reviewed or turned off even though Belgian tax rules were active.
Original PR description
### Issue: When demo data is disabled, creating a Belgian fiscal position installs the Belgian taxes and enables BE accounting Starting from 19.0, Intervat redirection is enabled automatically, but the Intervat settings are not available because the company itself is not Belgian As a result, the Intervat configuration cannot be changed or disabled ### Cause: The Intervat settings were only shown when the company country was Belgium However, companies using Belgian taxes through `account_enabled_tax_country_ids` must also be considered ### Steps to reproduce: - Disable demo data and install `accountant` - Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040) - Click the alert to install the Belgian taxes - Open Settings Before the fix: The Intervat settings are not available opw-6068480
This fix restores document uploads for portal users on mobile devices when sharing folders with edit access. It keeps the upload menu open long enough for the file selection to complete, so uploads start reliably after choosing a file.
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-5937105When a packed product is scanned with its lot and due date information, the system now correctly keeps the expiration date instead of replacing it with today’s date. This ensures lots created during barcode operations retain the right expiry information, which helps avoid inventory and delivery errors.
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#114123
Forward-Port-Of: odoo/enterprise#112490This update fixes two issues affecting project creation from sales orders. It now correctly uses the delivery address for the project customer and avoids a conflict that could block creating FSM projects from a template. This makes the sales-to-project flow more reliable for users.
Original PR description
FIX 1: industry_fsm_sale: set delivery address on project customer] ----------------------- **Steps to reproduce:** - Create a product: - Product Type: Service - Service Tracking: Create on Order…
FIX 1: industry_fsm_sale: set delivery address on project customer] ----------------------- **Steps to reproduce:** - Create a product: - Product Type: Service - Service Tracking: Create on Order (project) - Project Template: FSM type project template - Confirm a sale order with this product - Check the generated project customer **Issue:** The customer's delivery address is not set on the generated project. **Fix:** Set the delivery address as the project customer when creating the project. [FIX] industry_fsm_sale: remove default sale line in fsm projects ------------ **Steps to reproduce:** - Install industry_fsm_sale - Create a project template of fsm type - Create a sale order (service-type product) - Confirm the sale order - Create a project and select the fsm-type project template - Create the project **Issue:** - SQL constraint is triggered, preventing project creation. **Fix:** - If the project template is of fsm type, remove the default sale line from the context. task-5074893