Tuesday, April 21, 2026
25 changes · saas-19.1
Enhancements to existing features
This change reduces the time needed to validate large stock transfers by batching several database operations instead of repeating them one by one. It matters because pickings with many lines should complete much more reliably and avoid timeouts.
Original PR description
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for…
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids. This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings. Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the `purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s). Benchmarks: | No. move lines in delivery | Before | After | | -------------------------- | ------- | ----- | | 7579 | Timeout | < 200 s | opw-5826905 Forward-Port-Of: odoo/enterprise#110587 Forward-Port-Of: odoo/enterprise#110153
Inventory valuation for older dates now checks stock quantities using a narrower set of products at a time. This reduces unnecessary work on large databases and makes valuation calculations complete much faster, while keeping the same results.
Original PR description
When computing Inventory Valuation with a past `As of` date for AVCO products, `_run_average_batch()` reads `qty_available` for each manual `product.value` entry with `product.with_context(to_date=manual_value.date).qty_available`. On large databases, products can carry a broad prefetch set through the `product.value` browsing path. As a result, each distinct `to_date` may compute `qty_available` for more products than necessary. This change narrows the prefetch ids to the products sharing the same manual value date before reading `qty_available`. This keeps the same `to_date`, the same quantity computation, and the same per-product result, while reducing the amount of historical quantity computation done for each date. | Stock moves | Before PR | After PR | | --- | ---: | ---: | | 785k | fails after ~900s | 183s | opw-5944584 Forward-Port-Of: odoo/odoo#256684
Resolved issues and error corrections
This fix prevents imported invoices from getting the wrong tax amount when an EDI document contains multiple tax subtotal sections. It now uses the tax totals linked to the invoice’s own currency, which avoids incorrect adjustments in supported international invoice formats.
Original PR description
When the EDI document has multiple document-level TaxSubtotal nodes (which can happen under Japanese PINT rules), `_correct_invoice_tax_amount` erroneously amends the tax total, and the imported invoice gets the wrong value. In BIS3 EDI, two TaxTotal nodes are created if the document currency and the company currency are different. The TaxTotal node in the company currency is generally for tax reporting purposes. Up until now, `_correct_invoice_tax_amount` worked correctly because base BIS3 EDI requires TaxTotal nodes with the document currency to have a TaxSubtotal node. This commit fixes the bug by only correcting the taxes based on the TaxTotal node that has a currency ID equal to the document currency. Note 1: This fix is targeting 19.0 and above because `l10n_jp_ubl_pint` and other PINT modules are available starting from 19.0. Forward-Port-Of: odoo/odoo#258301
Removing an attachment from a scheduled chatter message no longer causes an error. This makes editing scheduled messages more reliable and prevents users from losing time on an unexpected traceback.
Original PR description
scheduled message editor Problem: When editing a scheduled chatter message, removing an attachment raises a traceback. Cause: `fullComposerBus` is available in the `Composer` environment but not in `ScheduledMessage`. The code assumed its presence and attempted to use it unconditionally. Solution: Check whether `fullComposerBus` exists in `env` before using it. Steps to reproduce: - Add a log note. - Open the full Composer. - Add an attachment. - Schedule the message. - Save. - Edit the scheduled message. - Remove the attachment from the attachments list. - Observe a traceback. opw-6098302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258839
This update prevents a crash that could happen when searching for an employee in Attendance kiosk mode. It makes the search logic ignore invalid internal conditions, so the kiosk stays usable instead of showing an error.
Original PR description
**Steps to Reproduce:**
1. Install `hr_attendance` module with demo data.
2. Go to Attendances > Kiosk Mode > Identify Manually.
3. Select any department.
4. Try searching for an employee.
**Error:**
`ValueError - not enough values to unpack (expected 3, got 1)`
**Cause:**
The `employees_infos()` controller assumes that every item in the domain is a valid triplet (field, operator, value). However, the domain may also contain logical operators ('&'), which are not triplets. And then trying to unpack such entries leads to a ValueError.
**Fix:**
Add a validation to ensure the condition is a proper triplet before unpacking. Non-conforming entries (logical operators) are skipped.
sentry-7401444075
opw-6113268
Forward-Port-Of: odoo/odoo#258825Preparation printers now show the selected variant’s attribute value when a combo item uses an instant variant. This ensures kitchen or prep tickets display the correct product details instead of only the base product name, reducing confusion and order mistakes.
Original PR description
Before this commit, the preparation printer did not display the attribute value for an instant variant added inside a combo choice. This occurred because the attribute value was not properly set on the variant order line. Steps to reproduce: * Create a PoS product with multiple variants. * Create a combo product with a choice containing the variants. * Configure a preparation printer. * Open a PoS session and order the combo. * The printer displays only the base product name. opw-5949132 Forward-Port-Of: odoo/odoo#256981
The domain selector and expression editor now display numbers using the user’s language and regional settings, such as decimal and thousands separators. This makes values easier to read and avoids confusion, while keeping the underlying expression unchanged.
Original PR description
Before this commit, the domain selector (and expression editor) did not format numbers according to the localization parameters (decimal and thousands separators), while the parsing step did. After this commit, the value is displayed in the correct format to the user, while the expression remains unchanged. 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#259732 Forward-Port-Of: odoo/odoo#258287
This change prevents the IoT box from overwriting a printer’s subtype when it resends device information. As a result, any subtype set by a user in the database stays intact unless the device’s main type actually changes.
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.
This update refreshes the spreadsheet component to the latest version and brings in several fixes that improve reliability and formatting accuracy. It also updates the underlying build and development tooling, which helps keep the spreadsheet feature compatible with newer software versions and easier to maintain.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d734b5fc76 [REL] 19.1.15 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d734b5fc76 [REL] 19.1.15 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7b46b15ef7 [IMP] package: backport rolldown and TS 6.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/1aa2e82583 [IMP] typescript: upgrade to 6.0.2 [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/d14f831597 [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/7847979c1f [IMP] package: upgrade rolldown to latest version [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/00e9fad82d [IMP] config: rename rolldown config file [Task: 6071659](https://www.odoo.com/odoo/2328/tasks/6071659) https://github.com/odoo/o-spreadsheet/commit/a2ce36fa84 [IMP] config: replace rollup with rolldown [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/c55874a9e8 [IMP] eslint: enforce type exports [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/835572ba20 [IMP] pre-commit: bypass eslint's typescript compilation [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/038b30f1b7 [IMP] tsconfig: moduleResolution bundler [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/33a9eea8a1 [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/cb35b4680b [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834) https://github.com/odoo/o-spreadsheet/commit/fb86c10488 [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/4bfa5fde13 [FIX] clipboard: prevent cross-version copy/paste [Task: 6095101](https://www.odoo.com/odoo/2328/tasks/6095101) https://github.com/odoo/o-spreadsheet/commit/d3a54d258d [IMP] tests: add tests for `chartShowValuesPlugin` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/fc0e6941c9 [FIX] css: remove unused variables [Task: 6119435](https://www.odoo.com/odoo/2328/tasks/6119435) https://github.com/odoo/o-spreadsheet/commit/744bfffe99 [FIX] computed style: fix multi-user clear formatting [Task: 6086129](https://www.odoo.com/odoo/2328/tasks/6086129) https://github.com/odoo/o-spreadsheet/commit/269bec6457 [FIX] format: large number format with no digits [Task: 6010376](https://www.odoo.com/odoo/2328/tasks/6010376) https://github.com/odoo/o-spreadsheet/commit/c438eb31b0 [FIX] format: number format with no digit [Task: 6068824](https://www.odoo.com/odoo/2328/tasks/6068824) 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 change makes Odoo catch invalid filter values earlier, such as using text where a number is expected. It helps prevent hidden errors and makes domain checks more reliable before they are used in practice.
Original PR description
`Domain([('num_field', '=', 'dfd')]).validate(model)` should raise an exception because 'dfd' is not a valid number. Currently, the optimization does not check the data types for all operators, but these are checked during SQL generation. Let's generate the SQL to validate the domain.
task-6132976
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe editor now avoids showing or using formatting tools on content that cannot be edited. This prevents unexpected errors and infinite loops when users try to format protected content, while still allowing the toolbar in the specific cases where it is needed for QWeb and icon elements.
Original PR description
Current behavior before PR: - Removing formatting on a contenteditable false element infinite loop when removing format. - The toolbar could appear even when the target element had contenteditable false Desired behavior after PR is merged: - Now,the toolbar no longer opens when the selected element is contenteditable false - The toolbar is now only shown for elements with contenteditable true, except for QWeb and icon elements, where it remains accessible. task-5265416 Forward-Port-Of: odoo/odoo#259453 Forward-Port-Of: odoo/odoo#231613
Fixed an issue where images added to the company document layout could disappear in printed PDFs after being resized to a percentage. This ensures customer-facing documents print correctly with the intended branding and layout.
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
Searching for a setting on mobile could previously trigger an error. This update fixes the issue so users can reliably find settings on smaller screens without interruptions.
Original PR description
Before this commit, when searching a setting in mobile a error as raised. opw-6140257
Access error messages now point to the actual record rule that blocks a user, instead of incorrectly suggesting a company-related issue. This makes permission problems easier to understand and reduces confusion when opening archived records.
Original PR description
When accessing an archived record directly, if access is prevented by a record rule other than a multi-company global rule, the error message incorrectly reports that all rules are failing, suggesting a company issue even though it is not the actual cause. The problem is that when access is denied, the diagnostic method `_get_failing` is used to determine which rules are failing. This method performs several count queries with different rule domains. However, `active_test` is True by default, excluding archived records from the count, causing the rule evaluation to miss some records and incorrectly mark rules as failing. With this commit, `_get_failing` evaluates rules with `active_test=False`, ensuring that only actually failing rules are reported. Forward-Port-Of: odoo/odoo#259592 Forward-Port-Of: odoo/odoo#259344
When editing a page in one language while using a different interface language, the text editor could show writing direction incorrectly. This update makes the editor follow the language of the content being edited, so typing in right-to-left languages like Arabic now appears correctly while editing.
Original PR description
Steps to reproduce: ==================== 1. Install Arabic and set it as a website language 2. Log in as a user whose UI language is English 3. Edit a page / article in Arabic and type some text =>…
Steps to reproduce: ==================== 1. Install Arabic and set it as a website language 2. Log in as a user whose UI language is English 3. Edit a page / article in Arabic and type some text => Text rendered left-to-right in the editor Cause: ======= this was introduced after this change [1] When editing a website/article in a language whose direction differs from the logged-in user's UI language, text entered in the builder appeared in the wrong direction (e.g. writing in Arabic showed the caret/text aligned to the left instead of the right). Saving reverted the content to the correct direction, but the authoring experience was broken. The builder was initializing the editor's `direction` config from `localization.direction`, i.e. the *user's* UI locale, instead of the direction of the document being edited. As a result, an LTR admin editing an RTL site (or the reverse) got an editable whose `dir` attribute did not match the site. Solution: ========= Use the editable itself as the source of truth: if it carries the `.o_rtl` class (already used to set `isEditableRTL`), set `direction = "rtl"`, otherwise `"ltr"`. => Text now renders right-to-left, matching the site [1]:https://github.com/odoo/odoo/pull/256045/changes/0490b2229dba7e0cb4a58e5cf4d68772e5640697 opw-6109987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259541
This fix prevents an error that could appear when adding multiple tags in the Blog Post Cover editor. It makes tag search handle newly created items correctly, so users can continue editing without seeing a traceback.
Original PR description
# How to reproduce - Go to a blog page and edit the Blog Post Cover - Add a tag - Try to add another one # The problem A traceback is shown # Why When adding a new record for a many 2 many relation, the framework ensure the user cannot create a record with a name that already exists via a name search. This commit (https://github.com/odoo/odoo/commit/3631757a4766bc59378bb975e01e115c92ef1dd4) changed the way the name search is done to add this domain to the request : ```py domain.push(["id", "not in", selectedIds]); ``` But selectedIds can contain strings in the case of uncreated records, which causes the SQL query to throw an error trying to match the model id with strings opw-5978305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258451 Forward-Port-Of: odoo/odoo#251469
This change corrects how unit prices are written in Peppol invoice XML so the totals now match exactly. It prevents valid invoices from being rejected during validation because of a rounding mismatch.
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
Fixed an issue in the Forum help page where clicking a snippet category could fail to insert content. This restores a smooth editing experience by allowing the editor to use the only available insertion area when needed.
Original PR description
Steps to reproduce the issue: - Go to Forum, then go to the Help page - Enter Edit mode - Try to drag and drop a snippet => The dropzone in the s_cover at the top of the page are available - Try to click on a snippet group => Nothing happen, because all dropzones are filtered The s_cover element has the [data-snippet] attribute. When clicking on a snippet group, the editor filters out dropzones inside other snippets. Since s_cover is treated as a snippet, its dropzones are excluded, even though they are the only ones available on the page. The solution is to treat dropzones inside snippets as low priority instead of strictly forbidden. If no other valid dropzones exist, we allow these as a fallback to ensure snippet insertion remains possible. task-5938138 Forward-Port-Of: odoo/odoo#258487 Forward-Port-Of: odoo/odoo#256078
This fix ensures that events with unlimited ticket availability can be sold correctly from the Point of Sale, even when multiple time slots are enabled. Previously, these tickets could be incorrectly treated as unavailable, causing customers to see an error that all slots were full.
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
The Intervat configuration is now shown for companies using Belgian taxes through a Belgian fiscal position, not only for companies registered in Belgium. This lets users review, change, or disable Intervat redirection when it was previously hidden.
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 Forward-Port-Of: odoo/enterprise#112609
When a product belongs to categories from multiple websites, Odoo now chooses a category that is available on the website the customer is currently browsing. This prevents category breadcrumb links from leading to a 404 page and improves the shopping experience 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 Forward-Port-Of: odoo/odoo#258336
This update fixes an error that could appear when users create accrual entries from the Billed Not Received screen after changing the date. It ensures the date is handled correctly so the action completes normally without interrupting accounting work.
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#259047
This update preserves the visual formatting of spreadsheet cells that contain Odoo links when a dashboard is frozen and shared. The links are made non-clickable for public viewers, while keeping the same link-like appearance needed for layout consistency.
Original PR description
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that…
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content. By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout. To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click). Task-6063301 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#260250 Forward-Port-Of: odoo/odoo#256357
This change fixes a problem where manual capture and void actions could fail in Adyen payments, and ensures the related payment records are updated correctly. As a result, businesses can complete payment operations more reliably without transactions getting stuck or rejected.
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 Forward-Port-Of: odoo/odoo#259223
This change fixes an issue where invoicing a kit could miss the cost-of-goods-sold entry if one of its components had been removed from the delivery. It also improves the calculation so the cost entry reflects only the components actually delivered, which makes accounting more accurate.
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#258982