Daily updates from Odoo
Friday, August 22, 2025
52 changes · saas-18.4
Resolved issues and error corrections
Removing the last bank account from a contact or vendor no longer triggers an error. This helps accounting users update partner bank details smoothly without being blocked by a traceback.
Original PR description
On removal of bank_ids from res_partner, When there was only one bank_id is left, when removing the last bank_ids from res_partner, a traceback appeared. `None` being passed to `duplicate_bank_partner_ids` and no null check was executed. We now avoid passing `None` **Steps to recreate**: 1. Go to Vendor 2. Create a Contact 3. Go to Accounting Tab inside contact 4. Create bank account 5. Save contact 6. Remove the bank account from that contact Task [link](https://www.odoo.com/odoo/project/967/tasks/4976409) task-4976409
A flaky automated test for public chat channels was corrected so repeated runs target the right messages and avoid unnecessary reload steps. This helps keep quality checks stable and reduces false failures during release validation.
Original PR description
This tour had many race conditions in the past and keeps having them. Some of them are actually due to the fact the tour is ran twice, but the selectors completely ignore this fact, leading to unexpected results. The message body is now updated before the second run to avoid confusion and the selectors are adapted to always target the message of the current run. Also remove the reload for emojis as they are showing immediately after being added. Also remove the useless comments that makes the test twice as long to read and to understand. https://runbot.odoo.com/odoo/runbot.build.error/230901 Forward-Port-Of: odoo/odoo#223839 Forward-Port-Of: odoo/odoo#223807
This fixes how accounting entries are paired during reconciliation when multiple partners are involved. Debit and credit lines are now matched by partner first, reducing confusing hidden partial reconciliation amounts and improving accounting consistency.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Accounting / Journals / Journal Entries" - Create the following MISC entries in this order: 1) | Account | Partner | Debit | Credit…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Accounting / Journals / Journal Entries" - Create the following MISC entries in this order: 1) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner A | 1000 | 0 | | Account X | Partner A | 0 | 1000 | 2) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner B | 1001 | 0 | | Account X | Partner B | 0 | 1001 | 3) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner C | 1002 | 0 | | Account X | Partner C | 0 | 1002 | 4) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner C | 0 | 1002 | | Account X | Partner C | 1002 | 0 | 5) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner B | 0 | 1001 | | Account X | Partner B | 1001 | 0 | 6) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner A | 0 | 1000 | | Account X | Partner A | 1000 | 0 | - Go to "Accounting / Accounting / Journals / Journal Items" - Select the 6 created lines linked to the Receivable Account - Reconcile them **Issue:** The 6 lines are fully reconciled, but when checking the amounts of the partial reconcile records (not visible in the UI), the debit and credit amounts are matched by their actual order. So, the first debit line of 1000 is matched with the first credit line of 1002, which results in a residual credit of 2 that is then matched with the second debit line of 1001, which leads to a residual debit of 999 and so on. This generates weird amounts in the partial reconcile records. **Solution:** In the case there are several lines with different partners, the lines can be sorted by partner to try to match the lines with the same partner together. opw-449356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223815 Forward-Port-Of: odoo/odoo#223512
Spanish 0% EU and export sales taxes are now classified as exempt with the correct legal exemption reasons. This helps ensure Spanish electronic tax reporting uses the right tax treatment and removes older duplicate exempt tax entries that are no longer needed.
Original PR description
Currently 2 sales taxes are misconfigured.
They both should be marked as 'exento' ("Exento") instead of 'no_sujeto_loc' ("No Sujeto por reglas de Localization")
- "0% EU G"; with "Exempt Reason" E5 / "Art. 25"
- "0% EX G"; with "Exempt Reason" E2 / "Art. 21"
This commit updated those taxes
Due to this the following sales taxes become obsolete.
- "VAT Exempt (Art. 21)"
- "VAT Exempt (Art. 25)"
They are deleted in this commit.
opw-4850585
Forward-Port-Of: odoo/odoo#223829
Forward-Port-Of: odoo/odoo#223603Manufacturing order overviews now calculate Bill of Materials costs using the correct unit of measure. This prevents costs from being overstated when products are manufactured in packs, giving users accurate production cost information.
Original PR description
Steps to reproduce:
- Create a storable product “P1”:
- UoM: Unit
- BoM:
- Pack of 6 of P1
- Components:
- C1: 6 units (price = $5)
- C2: 6 units (price = $10)
- Create a manufacturing order:
- 1 Pack of 6 of P1
- Confirm the MO
- Go to the MO overview
Issue:
- MO cost = $90 → ($5 * 6) + ($10 * 6) → correct
- BoM cost = $540 → ($5 * 36) + ($10 * 36) → wrong
Cause:
The BoM cost calculation uses `product_uom_qty` (6 units) of the production instead of computing the real quantity needed with the correct UoM.
As a result, component quantities are multiplied twice.
opw-4954953
Forward-Port-Of: odoo/odoo#223730This update adjusts internal email-related tests so they pass consistently when an optional file-detection library is present. It helps keep Odoo's automated quality checks stable without changing business features or user workflows.
Original PR description
Those tests are failing when python-magic is installed. Since 26f9c82b99 Odoo > saas-18.4 has this lib as a requirement and comes with appropriate fixes. This commit adapts some test from 17.0 up to saas-18.4 to also work when the python-magic lib is installed. Forward-Port-Of: odoo/odoo#223780 Forward-Port-Of: odoo/odoo#223609
This fixes an issue where older Saudi ZATCA Phase 1 invoice QR codes could disappear after the electronic invoicing module was installed. Businesses can now see the correct Phase 1 or Phase 2 QR code on invoices, helping keep Saudi invoicing documents complete and compliant.
Original PR description
Phase 1 ZATCA QR codes disappear when l10n_sa_edi is installed, there is a check for document submission to display the QR code for Phase 2 which older Phase 1 invoices will not pass as it doesn't use edi. Description of the issue/feature this PR addresses: Phase 1 ZATCA QR Code disappears once l10n_sa_edi is installed Current behavior before PR: Always hide Phase 1 ZATCA QR Code Desired behaviour after PR is merged: Showing Phase 1 and Phase 2 ZATCA QR codes based on the invoice task-5005304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222627 Forward-Port-Of: odoo/odoo#222285
This fixes a sales order issue where a customer's signature could be saved too early, leaving the order impossible to sign again if confirmation failed. The change ensures failed confirmations can roll back properly, so customers can retry signing after the underlying issue is resolved.
Original PR description
In this bug, sale order signature is commited before confirm, causing sale order not be able to be signed later, if confirm fails. To reproduce the bug: 1- Create a consumable product with `Buy` and `Dropship` routes enabled in the inventory tab 2- Do not put in any vendors in the purchase tab 3- Create a sale order with this product and uncheck the online payment option. 4- On an incognito browser, sign in as portal user and open the sale order 5- Click on the `Accept & Sign` button and confirm 6- We get an invalid operation error because of not having vendors 7- Reload the order. As you see, it is not possible to sign it To fix the issue, we use flush instead of commit, so when confirm fails it can rollback. Note: It is not easy to write a test for this case, because the `action_confirm` fails in a specific case when `purchase_stock` and `stock_dropshipping` are installed. opw-4864150 Forward-Port-Of: odoo/odoo#223610
Fixes an issue in the website form builder where disabling a list option could remove its saved identifier. This prevents duplicate options from being added by mistake and keeps form configuration consistent.
Original PR description
Since [1] the id of list items is lost when clicking on the enable/disable value of builder list. This commit only updates the id when an actual value is modified. Steps to reproduce: - Install website_mass_mailing - Drop a form - Add a field for "Mass Mailing" - No new option can be added, as expected - Un-default the first value => That value could then be added again, and the option value that contained the record id was lost inside the form. [1]: https://github.com/odoo/odoo/commit/db8be44e1361898af659a28b488b2288ff5b66fc task-4367641
Employee presence tooltips now show the intended work location label, such as “Office”, instead of a more detailed internal location description. This helps HR users and managers quickly understand where an employee is working without confusing or misleading wording.
Original PR description
…icon_display task-4933881 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
Dragging certain website building blocks no longer loses the original drop spot when the block is the only visible item in its container. This makes page editing more reliable and keeps drop indicators looking consistent for users arranging content.
Original PR description
Steps to reproduce: - Drop the "Banner" snippet. - Click on the "Blockquote". - Start to drag it. => No dropzone appears where it was so we cannot drop it back. When starting the drag and drop of an element that is the only (visible) child of its parent, an invisible clone is created and added where the element was, in order to have a dropzone to drop it where it was. The issue here is that this clone is a simple `<div>`, and inner snippets cannot be dropped next to `<div>` elements, which is why no dropzone is appearing despite the clone being present. This commit fixes that by making this clone a real clone of the dragged element, so it always has valid classes and tagname to make the dropzone appear. In addition, by giving the clone the same dimensions as the element, it allows to have better looking dropzones (e.g. a vertical one when dragging the last column of the "Steps" snippet instead of a big horizontal one). task-4367641
Orders placed through self-ordering and paid online are now sent to the preparation display, matching the behavior of terminal payments. This helps kitchen or preparation staff see and fulfill paid orders without manual intervention or delays.
Original PR description
After this pr: https://github.com/odoo/odoo/pull/213493 the orders were not sent to the preparation display if the order was payed with and online payment method. This commit add the same logic as the terminal payments to send the order to the preparation display. 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#222648
This fix restores an optimization that avoids unnecessary image data loading when only file size information is needed. It can make product kanban and similar views load faster, especially when image storage has higher latency.
Original PR description
Since 7744886d6141ca7971d91807d0444c707e10fdf8, reading binary field with bin_size=True still reads the ir.attachment datas field, which is relatively slow with some storage backends. In the products kanban view this can easily add 1 sec to web_search_read, if there is a 10ms latency when reading images. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223812 Forward-Port-Of: odoo/odoo#221270
This fixes an issue where replacing an image in the website editor could save the uploaded file without linking it to the correct page or content record. Images now use the nearest editable website content to keep attachments properly organized and reliable after saving.
Original PR description
[FIX] html_builder, *: save attachment with correct resource info *: html_editor, website Steps to reproduce the problem: - Add a "Text-Image" snippet on the website. - Replace the image. - Save. -> The `/html_editor/modify_image/` is called with the `res_model` and `res_id` parameter set to `null`. The problem appeared since the [website refactoring]. To solve the problem, the `res_model` and `res_id` parameters are set thanks to the information of the closest savable element from the image. Related to task-4367641 [website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This update makes an automated website popup test more reliable by allowing extra time for the popup to appear before it is closed. It helps reduce random test failures in the release process without changing customer-facing website behavior.
Original PR description
Before to this commit, the ‘closing s_popup with the X button updates the invisible elements' panel test failed sometimes on runbot. We think boostrap.js takes longer than normal to display the popup. Solution: We're going to increase the waiting timeout so that the crash doesn't recur. We've taken this decision because the problem is very specific and probably link to bootstrap.js. 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
The Paymob payment module icon has been adjusted so it displays correctly without distortion. This is a small visual fix that improves the appearance of the module in Odoo apps and settings.
Original PR description
This commit adapts the module icon to prevent distortion and ensure correct display. task-5031863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now shows the right checkout message when a takeaway or delivery order is missing required details such as a time slot, customer, or delivery address. This helps staff quickly fix the exact issue and avoids orders being blocked by misleading prompts.
Original PR description
STEPS TO REPRODUCE: ---------------- - Install `pos_restaurant`. - Set up a "Takeaway" preset with "identification = not required". - Remove all slots for today. - Try to place an order using "Takeaway" or "Delivery" without selecting a slot or address. ISSUE: ----------- - Only the "customer required" popup appeared, even if slot or address was missing. - For Delivery, missing address was not checked. CAUSE: ----------- - One single dialog was used for all checks, so it didn't check each thing separately. FIX: --------------- - Show specific popup depending on what is missing (customer, address, or slot). Task-4892105 Forward-Port-Of: odoo/odoo#222387 Forward-Port-Of: odoo/odoo#216216
Partial payment links on invoices now request the intended partial amount instead of the full invoice balance. This prevents customers from being asked to overpay when using a payment link and makes invoice payment flows more reliable.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an unpaid invoice; 2. generate a partial payment link; 3. open partial payment link; 4. click the Pay button. Issue ----- The invoice's full amount gets requested. Cause ----- Commit 5697493e0091 added `amount` as a named keyword parameter in an `_invoice_get_page_view_values` override, but failed to pass it along to the call to `super`. As the base method no longer receives an `amount` parameter, it defaults to the invoice total. Solution -------- Pass `amount` to the `super` call. opw-5013044 Forward-Port-Of: odoo/odoo#223554
This fix prevents a crash when users freeze and share a spreadsheet that contains an Odoo List. It ensures the spreadsheet is created with the right context so the sharing flow works reliably.
Original PR description
Steps to reproduce: - Install documents_spreadsheet (enterprise) - Create a spreadsheet with an Odoo List - Open the document view - Select the spreadsheet - Click on "Freeze and Share" => Boom Please see the enterprise PR for the test. Task: 5025331 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
This fix ensures custom readonly fields on invoice lines remain non-editable when users work with invoices. It prevents accidental changes and unnecessary dirty-state prompts caused by checkbox fields being toggled despite being marked readonly.
Original PR description
Steps to reproduce ================== - Go to invoices - Open studio - Click on the invoice lines - Edit the list view - Add a new field of type checkbox - Mark that field as readonly - Exit studio - Open an invoice - Click on the checkbox => The form is marked as dirty and the checkbox is toggled Cause of the issue ================== https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90 If the state is not in ["cancel", "done", "posted"], the fields are never in readonly Solution ======== Only do this for the "name" and "product_id" fields opw-4917471 Forward-Port-Of: odoo/odoo#222849 Forward-Port-Of: odoo/odoo#222595
This fix prevents automated test builds from failing when URL parameters reference tests or suites that are not installed. Missing excluded IDs are now ignored quietly, while relevant missing included IDs can still be logged for developers.
Original PR description
Before this commit, URL test/suite IDs were warned in the console if they didn't match any test/suite registered by the test runner. This is an issue for Runbot which runs sub-builds with the same URL parameters regardless of the installed addons, which repeatedly fails such builds. This commit changes the warning to a regular log, so that these builds stop failing, while still allowing a developer to get the information that an ID has been removed/ignored. runbot [230082](https://runbot.odoo.com/odoo/runbot.build.error/230082) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223242
Fixes an issue where changes to custom button colors or border width were not immediately reflected in the page preview. This helps users see their styling choices accurately before saving, reducing trial and error when editing website content.
Original PR description
When adjusting custom button colors or border width, the in-page preview is not updated. This commit updates the in-page preview upon color preview and border width modification. task-4367641
Updated the Point of Sale loyalty gift card test data so the customer name is unique and can be found reliably during automated checks. This helps prevent false test failures and supports more stable validation of loyalty flows.
Original PR description
This commit make sure that the partner name is unique and can be retrieved in the PoS opw-230992 Forward-Port-Of: odoo/odoo#223656 Forward-Port-Of: odoo/odoo#223387
This fix ensures invoice journal line amounts are restored correctly when a user switches from a foreign currency to the company currency and back before saving. It prevents exchange rates from being applied twice or incorrectly, helping keep invoice accounting values accurate.
Original PR description
Steps to reproduce: - Enable a foreign currency with rate - Create an invoice in foreign currency - Switch to company currency, then back to foreign currency before saving - Check journal items values Issue: Amount currency and balance have been affected by the currency rate even if the original currency was restored before saving opw-4864994 Forward-Port-Of: odoo/odoo#222870
The Italian localization now includes the required 0% EU service export tax with the correct legal note. This helps businesses issue compliant invoices for EU service exports without manually adjusting tax wording.
Original PR description
Description of the issue this commit addresses: The export tax for services is missing in the italian localization. It's required because it has a different legal note than the usual 0% EU tax. --- Desired behavior after this commit is merged: The italian localization has a 0% EU S for exported services in EU with the right legal note. --- task-4715771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223620 Forward-Port-Of: odoo/odoo#205521
Fixed an issue where employees assigned to company-wide working schedules could be missed when creating timesheets for public holidays. This ensures holiday-related timesheet entries are generated consistently for employees using global schedules.
Original PR description
_*= project_timesheet_holidays Steps to Reproduce: --------------------------- 1. Create a global working schedule (company should be False). 2. Assign this working schedule to any employee. 3. Create a public time off (for all the working schedule). 4. You will notice that the timesheet entry is not generated for the public holiday for that employee. Issue: ------------------------------- - Employees who use the WS without a company are excluded from timesheet creation. Cause : -------------------------------- - When grouping employees by calendar global WS (with no company) were being excluded. - And the timesheets were not generated due to the check `calendars_dict[calendar_id].company_id != company` when the WS had no company Fix: ------------------ - We will add the domain to include the global WS and and we will check if the the WS has company id then only check the condition. task-4900941 Forward-Port-Of: odoo/odoo#219916
Turkish e-Dispatch XML files now use the main commercial customer for customer details and the specific delivery contact for the delivery address. This improves compliance and accuracy, including using customs ZIP information for non-Turkish customers and hiding XML generation when no delivery address is available.
Original PR description
Behaviour before this commit: - Previously, the picking partner was used for sending both the Delivery Customer and delivery address in the XML. - Secondly, ZIP was used in Delivery Customer regardless of the country of the partner (Turkish or Non-Turkish) Desired behaviour after this commit: - After this commit, the commercial partner of the picking partner will be used for sending the Delivery Customer data and picking partner itself will be used for sending the Delivery Address in the XML. - Additionally, if the commercial partner is non turkish, customs ZIP will be used in the Delivery Customer in the XML. - If the delivery is validated without giving Delivery Address, then the 'Generate e-Dispatch (XML)' button will be hidden. TaskID:4918748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223563 Forward-Port-Of: odoo/odoo#218096
This fix ensures copied databases with the Greek EDI module cannot accidentally interact with live external tax or invoicing services. It helps support teams investigate issues safely without affecting production data or customers.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gr_edi module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] odoo#203428 Forward-Port-Of: odoo/odoo#223714 Forward-Port-Of: odoo/odoo#223536
The Attendance overview list now shows only employees who actually have attendance records when grouped by employee. This avoids clutter and makes attendance reporting easier to review without changing the Gantt view behavior.
Original PR description
To reproduce: ============= - Activate the "Attendances" app. - Go to Attendances > Overview. - Switch to list view. - Group by Employee. Issue: ====== The current domain fetches all employees…
To reproduce: ============= - Activate the "Attendances" app. - Go to Attendances > Overview. - Switch to list view. - Group by Employee. Issue: ====== The current domain fetches all employees matching the filter, regardless of whether they have attendance entries in the grouped model. https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/addons/hr_attendance/models/hr_attendance.py#L677 Fix: ==== Restrict the employee list to only those linked to a resource that appears in the grouped data https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/odoo/models.py#L2360-L2361 The problem is the behavior of gantt view will change it's behavior So we have to applied only to the list. there's something unique when we call it from the gantt which is `gantt_start_date` property that we will use it so we can differentiate between list and gantt view -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223594 Forward-Port-Of: odoo/odoo#223181
This update prevents the website editor from accidentally making protected page areas editable and improves how replaceable media is detected. It helps avoid unintended edits to content that should not be changed or saved, reducing editor confusion and preserving page integrity.
Original PR description
[FIX] html_builder: avoid setting contenteditable on some elements The goal of this commit is to prevent the system from setting the `contenteditable` attribute to true on elements located inside…
[FIX] html_builder: avoid setting contenteditable on some elements The goal of this commit is to prevent the system from setting the `contenteditable` attribute to true on elements located inside `.o_not_editable`. This behavior was lost since the [website refactoring]. Related to task-4367641 [website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [FIX] html_builder: avoid editing non savable media The goal of this commit is to improve the handling of the `click` and `dblclick` events on elements inside the editable. The idea is that we want to do an action to replace the media (open a tooltip to show that the media is replaceable or open the media dialog) when the user clicks or double clicks on an editable media. To do so, the `mediaSelector` selector was built to remove the elements that had the branding (`data-oe` information) from the list of elements on which we want to do the action. The idea was that if the element itself had the branding, it was not savable (its content is savable but the element in itself is not) so we do not want to replace it. This is true but it is redundant of the `isReplaceableMedia` method. This commit removes the `mediaSelector` selector and improves the `shouldEditableMediaBeEditable` util function; a media that has the `o_editable_media` class is considered editable if it is a descendant of a savable element (an element that has the `o_editable` class) but is not a savable element itself. Indeed, attributes such as `src` are not saved on savable elements. Even if there are nothing failing before this commit, a test has been added for the sake of completeness Related to task-4367641
This fix prevents the product page editor from reloading too early when replacing a product’s main image, avoiding a crash during image selection. It also restores missing editor action dependencies so layout and width controls work reliably on product pages.
Original PR description
__Current behavior before commit:__ When trying to replace the main image on a product page, the iframe reloads before the user can choose an image in the dialog. Therefore, when the user chooses on an image the editing element is already removed, leading to a crash. __Description of the fix:__ Disable the automatic reload for `ProductReplaceMainImageAction` like it was done in saas-18.3. __Steps to reproduce the issue:__ 1. Go to a product page 2. Open the editor 3. Click on the "Replace" button next to "Main Image" 4. Click on an image in the dialog 5. Traceback: `TypeError: Cannot read properties of null (reading 'getComputedStyle')` opw-5010040
Downloading the ADEME database in ESG now takes users directly to the emission factors page instead of leaving them on the database configuration page. This makes the workflow clearer after a successful download and adds logging to help monitor how long the ADEME data fetch takes.
Original PR description
Steps to reproduce: - go on configuration -> databases in ESG - download the ademe database What's happening: A success message is displayed, but the user stays on the database page. What's expected: The user is redirected towards the factor emissions page Additional fix: Small addition of an extra logger in the ADEME download process to allow checking the time needed to fetch the data from the ADEME website Task [link](https://www.odoo.com/odoo/project/967/tasks/4751902) task-4751902 Forward-Port-Of: odoo/enterprise#87058
Fixes an accounting reconciliation issue where invoices and vendor bills involving different partners could be marked paid with the wrong partner on generated transfer lines. This helps keep partner-based financial reports, such as the Partner Ledger, accurate in workflows where customer invoices and vendor bills are reconciled together.
Original PR description
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open…
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open "Payments Matching" - Select the invoice and the bill - Reconcile them **Issue:** A move is created with 2 lines that will mark both invoice and bill as paid. However, on both created lines, the partner is "Vendor Y", which is wrong as it will generate incorrect reports (e.g. Partner Ledger). One line should have "Vendor Y" as partner and the other line should have "Customer X". This kind of reconciliation is apparently current in India. **Cause:** When reconciling lines from 2 accounts exactly, a transfer from one account to the other one is created. The transfer is made from the account where the absolute amount to move is the lowest. A transfer is made for each partner that has a move being reconciled with the source account. The transfer is crediting (or debiting) the source account and debiting (or crediting) the reconcile account with the same partner. This is working most of the time but it totally ignores all the partners linked to the moves with the reconcile account. **Solution:** Create one line of the transfer with the source account and the partner as before. For the line on the reconcile account, first check if there's one for the same partner, currency and sign (of the amount to transfer). If not, try to find another partner with the same currency and sign. Otherwise, fall back on the same partner as the line on the source account as it was done before. opw-4735147 Forward-Port-Of: odoo/enterprise#92909 Forward-Port-Of: odoo/enterprise#89972
The automated walkthrough for field service reports was adjusted so it follows the correct steps more reliably. This helps keep quality checks stable and reduces the chance of false failures during testing.
Original PR description
In this commit, we fix tour by splitting
{
isActive: ["auto"],
trigger: 'body:not(.modal-open) nav.o_main_navbar, button[name="action_generate_new_template"]',
run: "click",
},
in two distinct steps
For this, we use isActive key of a step that allow to activate the step with conditions.
We take advantages of this commit to add expectUnloadPage where it is required.This update fixes an automated test that could fail when run with Python 3.13 because sorting behavior produced a different order. It helps keep payment-related quality checks reliable across supported technology versions without changing business functionality.
Original PR description
**Issue:** "test_partner_account_batch_payments_with_journal_entry" is failing when executed in a Python 3.13 env. **Cause:** Sorting the account move lines on a tuple doesn't necessarily result in the same order between version 3.13 and previous ones. runbot-230794 Forward-Port-Of: odoo/enterprise#92357
This fix ensures Sendcloud shipping information is read correctly when filtering delivery options. It prevents an invalid index error, helping users manage Sendcloud-related delivery workflows without interruption.
Original PR description
Before this commit: `sendcloud_shipping_id` is of type `Object`. Trying to index the field was causing `invalid index error`. After this commit: Value is accessed correctly with the key `id`. opw-5011642
Bank transaction labels are now handled more safely when matching reconciliation rules. This prevents special characters such as plus signs, slashes, dots, or asterisks from disrupting the matching process, helping reduce missed or incorrect matches.
Original PR description
This commit will change the way we normalise the label. We now firstly check that the label is a structure reference and if so we don't escape the numbers. Otherwise, we do an escape of the label and the numbers. Escaping the label will allow to avoid case where we use character like * or . that would mess up the match regex. Example: '+++344/0660/16938+++' will be \\+\\+\\+344\\/0660\\/16938\\+\\+\\+ 'This is a test' will be 'This\\ is\\ a\\ test' task-5023114 Forward-Port-Of: odoo/enterprise#92616
Receipt validation now correctly prints lot or serial number labels when a required quality check is completed. This prevents missed labels during receiving workflows and also improves handling when receipts contain products with and without quality checks.
Original PR description
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The…
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The wizard is automatically opened but when you click on the Pass button, the wizard was closed without sending the print action ## Cause: The action wasn't return by the wizard function 'action_generate_next_window()' making the only action to be a 'act_window_close' ## Note: The state wasn't correctly set to done for all products when you validate pickings both with and without QCs in them at the same time, it should now be fix Enabling Delivery Slip for the Receipts will make the SN to not be print even after disabling the option ## Steps to reproduce: - Toggle the Lot/SN Labels option in the Hardware Tab for the Operation Type Receipts - Create a Product tracked by Unique Serial Number - Add a Quality Check for the Receipts operation - Create a New Receipt for the product - Mark as Done and Add the Serial Number - Validate the receipt and Pass the check - Before the fix, no document was downloaded opw-4790427 Forward-Port-Of: odoo/enterprise#92783 Forward-Port-Of: odoo/enterprise#90134
FedEx delivery requests now send province or state codes in the shorter format FedEx expects, without the country prefix. This helps prevent shipping label or rate requests from failing for countries where standard province codes include the country code, such as Sweden.
Original PR description
Before this commit: The province code for some countries includes the country code too. FedEx expects a two letter code in the request. For example, the standard code for Stockholms lan is "SE-AB" and the code FedEx expects is "AB". After this commit: The country code is excluded from the province code. opw-4984662 Forward-Port-Of: odoo/enterprise#92650
Products that are neither sellable nor rentable are no longer shown when adding items to a standard sales order. This prevents sales teams from accidentally selecting unavailable products and adds test coverage to keep the behavior correct.
Original PR description
This PR adds a test for the explained case which was solved by: - PR https://github.com/odoo/enterprise/pull/91701 - Commit…
This PR adds a test for the explained case which was solved by: - PR https://github.com/odoo/enterprise/pull/91701 - Commit https://github.com/odoo/enterprise/commit/a2bbf33f5e787420389f1550d8e66b7b6995dc75 #### Issue: Not rentable product were displayed in sale order product dropdown list whether they were salable or not #### Step to reproduce: - install Sale, Rental, - create a product no Sales, no Rental - create a new sale order #### Current behavior: - your product appears in the dropdown list to add a product #### Expected behavior: - your product shouldn't appear in the dropdown list to add a product #### Cause: - From the commit [d5f72c2](https://github.com/odoo/enterprise/commit/d5f72c201bf0642f2f47315f06468528268251a3) domain for rental are computed on back end. - sale_renting module override the `_domain_product_id()` method. It add a OR to the domain on `'rent_ok' = order_is_rental`. Therefore, if one create a sale order outside of the rental app, every not rentable product is displayed. #### Solution: - This domain should apply only if `order_is_rental` is enabled. Therefore add a AND to check if `order_is_rental` is enabled. opw-4966082 Forward-Port-Of: odoo/enterprise#91210
A test was added to ensure spreadsheets containing an Odoo List can be frozen and shared from Documents without triggering a crash. This helps protect users from interruptions when sharing spreadsheet-based reports, while the functional fix is handled in the related community change.
Original PR description
Steps to reproduce: - Install documents_spreadsheet (enterprise) - Create a spreadsheet with an Odoo List - Open the document view - Select the spreadsheet - Click on "Freeze and Share" => Boom This commit contains only the test, the fix is done in the community PR. Task: 5025331
This fix prevents one country's Intrastat reporting rules from unintentionally affecting another country's export data. Businesses using multiple localizations can rely on more accurate country-specific Intrastat report outputs.
Original PR description
Previously, it was possible for the _get_exporting_dict_data from a localization to change the data of another localization. Forward-Port-Of: odoo/enterprise#92892 Forward-Port-Of: odoo/enterprise#92830
This fix ensures employee identification details are included when point-of-sale sessions sync after clocking actions. This prevents errors on other devices when they communicate with the Belgian fiscal blackbox, improving reliability for affected POS setups.
Original PR description
Before this commit, when clocking, the session was synchro with other devices but without the _employee_insz_or_bis_number custom field. _employee_insz_or_bis_number was thus not accessible after the device receives the websocket message and the pos was returning a traceback when trying to send a message to the blackbox. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#92847
This fixes a timing mismatch that could cause Mexican electronic invoices to show a different CFDI date than the invoice posting time. It also keeps invoice records properly locked during sending, reducing the risk of inconsistent invoice processing.
Original PR description
`fecha_datetime` could be set to a different value than the `document_post_time` passed as parameter because of the `min`. We also must revert the `_cr.commit` during the sending because it removes the lock on records. Instead we set the invoice post time and commit before locking. task-none Forward-Port-Of: odoo/enterprise#92355
This update makes an automated test for embedded PDF handling work consistently whether an optional file-detection library is installed or not. It helps keep the Documents Accounting area stable across different deployment and testing environments without changing user-facing behavior.
Original PR description
The test `test_embedded_pdf` fails when the magic lib is installed. modified cherry-pick of 22cbdb477 Adapted to work with or without the lib as the lib is not required in version < 19.0. Forward-Port-Of: odoo/enterprise#92791 Forward-Port-Of: odoo/enterprise#92778
Users can now clear the partner field after setting an account on a bank statement line. This prevents incorrect partner information from being stuck on accounting entries and supports more accurate bank reconciliation.
Original PR description
Before this commit when doing a set account on a bank statement line, and then editing this line to remove the partner was not working. This commit will allow the user to remove the partner when editing the line. task-4984569 Forward-Port-Of: odoo/enterprise#91422
The Danish RSU module has been renamed to better match the naming used by other Denmark-related modules. This is a small consistency fix that should make the module easier to recognize and manage, with no expected change to business functionality.
Original PR description
This commit will edit the name of the module to be consistent with the other denmark modules no task id Forward-Port-Of: odoo/enterprise#92759
This update fixes an issue in the Belgian salary contract workflow. It helps ensure salary offers are processed correctly, reducing potential errors for HR teams using Belgian payroll features.
Original PR description
Forward-Port-Of: odoo/enterprise#88918
Booking updates sent through Google Reserve now keep all existing slot information while adding the party size. This ensures Google receives correctly formatted booking details, reducing the risk of failed or incorrect appointment updates.
Original PR description
The controller incorrectly modified the given "slot" to only contain the party size key. Instead, it should update the information to add this key next to the existing ones, and in turn return a properly formatted slot to Google. Task-3083812 Forward-Port-Of: odoo/enterprise#92839
Regular users can now retrieve DHL shipping rates without being blocked by an access error on protected shipping account details. This keeps quotation workflows moving when DHL legacy delivery methods are used.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have DHL (legacy) as a delivery method; 2. log in as demo user; 3. create a quotation with a shippable product; 4. click "Add shipping"; 5. select DHL; 6. click "Get rate". Issue ----- > Access Error: > You do not have enough rights to access the field "dhl_account_number" on Shipping Methods (delivery.carrier). Cause ----- The error gets thrown in the `_set_dct_bkg_details` method. In previous versions, the `dhl_account_number` field would still be in cache after `srm.check_required_value` was called, as this method checks whether the `carrier.dhl_account_number` field is non-empty in sudo mode. As of saas-18.3, field access is checked even if the value is available in cache, resulting in the access error. Solution -------- Use `sudo` to retrieve the `dhl_account_number`. opw-4899776 Forward-Port-Of: odoo/enterprise#92557
A test setup was corrected by removing an unnecessary timesheet approval permission that was not required for the manufacturing work order accounting checks. This prevents failures when the app is tested on its own, improving reliability of the release process without changing user-facing behavior.
Original PR description
on the test `test_mrp_aa_employee_without_account_rights` the user was created with the group `hr_timesheet.group_hr_timesheet_approver` which is not needed and was causing the test to fail on Single app test as this module does not depend on hr_timesheet. This commit removes this group from the user creation. runbot-231137 Forward-Port-Of: odoo/enterprise#92747
This fixes an issue where tax report grouping could fail when expected tax group information was missing. The correction helps ensure accounting reports continue to show the right tax information without interruption.
Original PR description
The previous domain wasn't working as country is a recordset and not an id. Forward-Port-Of: odoo/enterprise#92829