Daily updates from Odoo
Tuesday, October 14, 2025
75 changes · 19.0
New functionality added to Odoo
A new Databases app lets users monitor and manage multiple Odoo databases from one place. Each database can be handled like a project, with business KPIs such as pending inbox documents, draft journal entries, and tax returns visible in a shared overview.
Original PR description
The new Databases application allows you to manage a list of other Odoo databases from a single interface. Each database is treated as a Project, enabling features such as task and timesheet management within this context. The list view displays a variety of KPIs retrieved from each database - for example, the number of documents in the Inbox folder, the number of draft journal entries, or the tax returns that need to be submitted. Task-id: 5062431
Point of Sale restaurants using UrbanPiper can now connect with Keeta as an additional delivery provider. This expands available delivery channel options and helps businesses reach customers through another food delivery marketplace.
Original PR description
In this commit : - Integrated Keeta as a new food delivery provider in `pos_urban_piper`. Task - 5128817
Adds support for Belgian businesses to connect Odoo with Codaclean through Odoo's IAP service, so CODA bank files can be fetched automatically or on demand and imported into bank journals. This reduces manual bank statement handling and keeps accounting records more up to date.
Original PR description
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server.…
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server. The IAP side does the actual calls to codaclean (with a secret API key). To use the module you have to create a connection to IAP / codaclean and set up a bank journal: - To manage the connection to IAP / codaclean go to Settings -> Accounting -> Codaclean -> Manage Connection - To set up the bank journal you need to configure the following in the "Journal Entries" tab on the journal: - Put the IBAN in the "Bank Account Number" field - Select "Codaclean Synchronization" for the "Bank Feeds" field Coda files will be automatically fetched 2 times per day via the scheduled action called "Accounting: Sync Coda Files from Codaclean". They can also be manually fetched by clicking "Fetch from Codaclean" below the journal on the accounting dashboard (only available when the journal and connection are setup correctly). On an empty journal we start fetching from 1 year ago. When the journal is not empty we start fetching after the last bank statement / bank statement line in the journal. task-4844423 backport of commit 518ab9e Forward-Port-Of: odoo/enterprise#96827 Forward-Port-Of: odoo/enterprise#95747
Enhancements to existing features
Website editors setting up AI live chat can now more easily choose existing internal pages when adding links. This improves usability by showing relevant page suggestions instead of requiring manual URL entry.
Original PR description
Before this commit, the website URL picker used `autocompleteWithPages` to suggest internal links. This commit removes the WebsiteUrlPicker and patches the BuilderUrlPicker to use the autocomplete component, enabling internal link suggestions for existing pages.
The account merge process now gathers existing account codes in one database operation instead of checking each company one by one. This reduces waiting time when merging accounts, especially in databases with many companies.
Original PR description
The merge wizard needs to collect the account codes of the accounts we are merging in order to write them on the merged account as the final step of the merging process. At the moment, collecting the account codes is done in Python and loops over all the existing root companies, retrieving the code of the account for each company. On a recent l10n [runbot](https://runbot.odoo.com/runbot/build/90542336) (with 146 companies), this was causing the merging step to take ~4.5 seconds per account, most of this time being taken just by collecting the account codes. Instead, we collect the codes in a single SQL query. Flamegraphs: [before.json](https://github.com/user-attachments/files/22726956/before.json) [after.json](https://github.com/user-attachments/files/22726960/after.json) task-none Forward-Port-Of: odoo/odoo#230158
This update improves performance when editing website and email content by avoiding unnecessary page recalculations. Users should notice smoother behavior in areas that update many page elements, such as the website builder, HTML editor, and product variant previews.
Original PR description
The goal of this commit is to improve performance when using setAttribute. Using the native setAttribute causes the layout to be recalculated each time it is used, even if the same value is set. We are therefore introducing the setAttribute utils, which will check that the value is different before applying it. These performance issues are noticeable in situations where many elements need to be modified. 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 server action form no longer shows the “Usage” field, reducing clutter for users configuring automated or manual actions. This makes the setup screen easier to understand without changing the underlying action behavior.
Original PR description
task-5090321
Point of Sale orders received through Urban Piper can no longer be manually deleted. This helps keep online order records consistent with the normal cancellation or rejection process handled by the delivery aggregator or restaurant.
Original PR description
Before this commit: =================== - We were able to delete online orders, but generally, online orders are either cancelled by the aggregator or rejected by the restaurant. After this commit: ================== - Online orders can no longer be deleted. Task: 496669
The link editing popover now gives clearer visual feedback when users move through fields and buttons with the keyboard. Focus also stays inside the popover while tabbing, making link editing easier and more accessible.
Original PR description
Steps to Reproduce: - Select a word in the editor. - Press Ctrl + K and Enter to open the link popover. - Use the Tab key to move between the fields and buttons. Current behavior before PR: - It was not clear which field had the focus. - The border was always overridden by the `border-dark-subtle` class with `!important`, so users had no visual feedback when tabbing. - When tabbing, focus could escape the link popover instead of looping inside it. Desired behavior after PR is merged: - Inputs and selects now use the correct border color on focus, aslo discard button changes opacity when focused. - The link popover traps focus: pressing Tab/Shift+Tab will cycle through focusable elements without leaving the popover. task-4965566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223868
This change makes the color picker tab components available for extension across the editor, website, and web interface. It helps developers customize color selection behavior more safely without changing core code, with no direct impact on everyday users.
Original PR description
Since the [1] color picker tabs are plugable, and so, in order to be able to patch them, we'd need to export them. This commit exports them all at once. [1]: https://github.com/odoo/odoo/commit/edc9d5bb9582db704ed02051ee4adb3801ddfaa9
Odoo now identifies Peruvian customers subject to withholding rules and adds the required retention reference to the electronic invoice XML. This helps companies selling to withholding agents stay compliant with Peru's electronic invoicing requirements while keeping invoice totals calculated correctly.
Original PR description
Some customers in Peru are considered "agentes de retención", and as such have special considerations that are necessary. We must perform specific actions when working with these customers, when selling to them we must: - recieve a specific document from the customer (A followup task will add this support for companies to generate this document) - Include a retention reference in our XML. This is represented as a specific `AllowanceCharge` node that is the sum of all of the Withholding taxes on the lines with the specific code of 62. We know an invoice is to a withholding customer because all lines must have a tax that is a part of the withholding tax group. This withholding tax is not included in the monetarytotals, tax totals, or invoice line values. And there can be only one AllowanceCharge node per invoice, not one per line. task-4989463 Forward-Port-Of: odoo/enterprise#94504
The Peru localization now includes the required withholding tax and tax group by default. This helps identify customers who are withholding agents and supports accurate invoice XML generation in related enterprise features.
Original PR description
Withholding taxes are required to indentify if a customer is a withholding agent. This PR introduces the tax and tax group for the enterprise PR that will generate the changes for the Invoice XML. task-4989463 Forward-Port-Of: odoo/odoo#226684
Resolved issues and error corrections
Translated error messages now handle byte strings correctly instead of turning them into lists of numbers. This makes technical error details, such as email server connection responses, easier for users and support teams to read.
Original PR description
Improvements introduced by https://github.com/odoo/odoo/pull/197702 streamlined the auto formating of iterables to lists when passed as an argument to translatable strings in Odoo. While doing so,…
Improvements introduced by https://github.com/odoo/odoo/pull/197702 streamlined the auto formating of iterables to lists when passed as an argument to translatable strings in Odoo.
While doing so, strings were ignored (to prevent formating them as a list of the individual characters), but they failed to account for the fact that **byte strings** might also be passed as arguments in certain parts of the code.
An example can be found here:
https://github.com/odoo/odoo/blob/f037c39ad4d33384f81a418cb63fcdd6a5085d56/odoo/addons/base/models/ir_mail_server.py#L265-L278
`repl` in this context will be a byte string object returned by the SMTP connection.
## BUG:
Before the fix, if you would pass a byte string as an argument to a translatable string using keyword templating, the output would be the raw representation of the bytes as a list instead of the human readable content.
For example if we use in a french localisation:
`raise UserError(_('The server refused the test connection with error %(repl)s', repl=b'TEST byte string'))`
Before the fix we could get:
`Le serveur a refusé la connexion de test avec l'erreur 84, 69, 83, 84, 32, 98, 121, 116, 101, 32, 115, 116, 114, 105, 110 et 103`
And after the fix:
`Le serveur a refusé la connexion de test avec l'erreur b'TEST byte string'`
## Proposed fix:
In the same way that we ignore `str` arguments before auto applying the `format_list` method, we will also ignore them if the type is `bytes`
OPW-5107313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#231179Fixes an issue where an invoice could link users to an older draft payment instead of the confirmed payment that actually settled it. This makes payment navigation from invoices more reliable, especially when payments are reset, duplicated, and reconciled again.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/enterprise#96927 Forward-Port-Of: odoo/enterprise#89089
Turning off weekends in Analytic Reporting no longer causes months to disappear from the yearly grid. The weekend filter is now limited to month-based views, so yearly reports remain complete and easier to review.
Original PR description
To reproduce: ============= 1- Go to Analytic Reporting. 2- From the year dropdown, uncheck "Show weekends". → Some months disappear unexpectedly. Problem: ========= Weekend filtering was applied even in year range. In year view, each column is already a full month, so filtering out weekends is incorrect. Fix: ==== Adjust the condition to skip filtering when range is not "month". Weekend logic now only applies to month range grid. community-pr: https://github.com/odoo/odoo/pull/226975 opw-5078200 Forward-Port-Of: odoo/enterprise#96171 Forward-Port-Of: odoo/enterprise#94593
Fixed an accounting issue where an invoice could link to an old draft payment instead of the confirmed payment that actually settled it. This helps users reliably access the right payment record from invoices, reducing confusion during payment follow-up and reconciliation.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/odoo#231148 Forward-Port-Of: odoo/odoo#202076
This update adjusts an internal test workaround for the Gantt view so automated checks remain compatible with recent changes in the testing framework. It is limited to unit tests and does not change day-to-day product behavior for users.
Original PR description
## Pull Request HOOT 37 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/230556 Forward-Port-Of: odoo/enterprise#96886 Forward-Port-Of: odoo/enterprise#96647
This update improves Odoo's internal Hoot testing tools by making simulated clicks closer to real browser behavior, preventing crashes when comparing complex test data, and simplifying how test helpers are imported. It is limited to the unit test ecosystem, reducing maintenance friction while keeping business-facing application behavior low risk.
Original PR description
## Pull Request HOOT 37 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/96647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231060 Forward-Port-Of: odoo/odoo#230556
Batch sending invoices now correctly applies Peppol only to invoices that are eligible for it. This prevents invoices meant to be sent by email, such as those for non-Peppol customers, from failing and blocking their email delivery.
Original PR description
…ng methods When sending invoices in batch with multiple sending methods (for example 1 by Peppol, 2 by Email), Peppol was wrongly set on invoices where it didn't make sense. Steps to reproduce: 1. Go into a Peppol compatiable company (Eg: Belgium) 2. Go into settings, enable Peppol. 3. Create & post two invoices: one to an US partner, the other one to a Peppol partner (For example a belgian partner with a vat set.). Make sure to set the email on both. 4. Send them in batch: the wizard says 1 by Peppol, 2 by Email, which is correct. 5. If you send them, the one to the US partner that is not supposed to go through Peppol will end up in error, with the email not sent either. Root cause: We are doing some Peppol checks before checking if it actually make sense to apply this sending method on the move. task-none (reported from our production) Forward-Port-Of: odoo/odoo#230880
Fixed an issue that could cause the Invoicing dashboard to crash when users customized its default grouping in Studio and the selected group had no records. The dashboard now handles empty groups gracefully, keeping customization usable without interruption.
Original PR description
Currently an error occurs when a user tries to group account dashboard with a group not having any records. **Steps to replicate:** * Install `account` and `web_studio` * Invoicing > studio > Default…
Currently an error occurs when a user tries to group account dashboard with a group not having any records. **Steps to replicate:** * Install `account` and `web_studio` * Invoicing > studio > Default Group by > Account Online Link **Error:** `SyntaxError: syntax error at or near ')' LINE 19: WHERE j.id in () ^` **Root cause:** * The compute function [1] contains an SQL query that assumes journal IDs are always present. When the account dashboard is grouped by a category with no records (e.g., 'Online Account' when none are connected), no journals are returned, resulting in no journal IDs for the SQL query at [2]. * This issue appeared after PR [3], where the compute method is called even when the record isn’t saved, leading to NewId being passed to self and triggering this error. Similar fixes were applied in commit [4]. **Solution:** * Only run the SQL query if journal IDs exist. If none do,assign false to the computed entry fields. This works because [5] creates a fake group, allowing the dashboard to work normally. [1]: https://github.com/odoo/odoo/blob/a9a058aa063a05755ac3c6a78f99af5373d19fbd/addons/account/models/account_journal_dashboard.py#L205 [2]: https://github.com/odoo/odoo/blob/a9a058aa063a05755ac3c6a78f99af5373d19fbd/addons/account/models/account_journal_dashboard.py#L227 [3]: https://github.com/odoo/odoo/pull/195203 [4]: https://github.com/odoo/odoo/commit/7ba64a8c51f2888b301ee6feae140b02ca4b1b95 [5]: https://github.com/odoo/enterprise/blob/110c23ae23a1c37c15e7913bdcb74f2a26a67858/web_studio/static/src/client_action/view_editor/editors/kanban/kanban_editor.js#L51-L64 sentry-6674695712 Forward-Port-Of: odoo/odoo#230919
The Subscriptions MRR Breakdown report now only considers active companies when preparing its data. This prevents an access error that could appear in multi-company setups after archiving an old company and changing currencies, allowing users to open report details reliably.
Original PR description
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro),…
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro), then set that currency as the Main Currency of the new Company. - Then, set a currency rate on the previous Main Currency i.e USD. - Create a Subscription Sales Order and confirm it. - Open the MRR Breakdown report. - Click into the data of the report. Observation: An error message will occur appear (Access Error) Issue: - when building the query, it also fetches the archived company, due to `active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build which fetches no data, leading to sort of access error as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches. Fix: - we explicitly search for active companies opw-5090463 Forward-Port-Of: odoo/enterprise#95989
This fixes an error that could prevent Odoo from starting or handling URL-related operations when running on Python 3.11 or newer. The change improves compatibility with newer Python environments and avoids disruption caused by a missing dependency constant.
Original PR description
Closes #230990 Description of the issue/feature this PR addresses: - In Python 3.11+, urllib3 stopped relying on its internal _WHATWG_C0_CONTROL_OR_SPACE constant directly in newer releases Current behavior before PR: - As described by #230990 Desired behavior after PR is merged: - Using Python 3.11+ should not throw a _WHATWG_C0_CONTROL_OR_SPACE missing error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users open the forecast view for a product in a company without any warehouse, Odoo now shows a clear warning instead of an error. This prevents a confusing crash and helps users understand that a warehouse must be configured first.
Original PR description
Step to reproduce: - install stock - create a new company and switch to that company - open a storable product - click on forecasted smart button Cause: - StockForecasted component needs at least 1 warehouse, but when we create a new company, it does not have any warehouse https://github.com/odoo/odoo/blob/7747c5810eabe798a1631c3e3b26b81a5c89b4b4/addons/stock/static/src/stock_forecasted/stock_forecasted.js#L49-L52 - clicking on the smart button, raises traceback Fix: - we show a warning when the smart button is clicked and no warehouse is found **Note**: not adding a test case, as issue is not reproducible in test mode due to this https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 opw-5059799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225698
Payment terminal transactions in Point of Sale now complete automatically when cash rounding is applied. This reduces the risk of staff needing to manually validate already-paid orders, helping avoid missed validations and checkout mistakes.
Original PR description
Ensure that when a payment is made via a payment terminal and cash rounding is applied, the payment is automatically validated once the response is received. Previously, validation did not always occur because we relied on `get_due` is not exactly what is left to pay, as it does not account for cash rounding rounded amounts. The condition for auto-validation was simplified, since `is_paid` already checks whether there is nothing left to pay. Thus, using `get_due` is redundant. Steps to reproduce: 1. Create a cash rounding and set it on the POS. 2. Sell a product priced at e.g. 1.99 EUR, paid via a terminal (e.g. Worldline). 3. Notice the payment is not auto-validated and requires manual validation, which can lead to mistakes or missed manual validations. opw-4862684 Forward-Port-Of: odoo/odoo#231153 Forward-Port-Of: odoo/odoo#228608
This update fixes visual alignment in blog list cards and keeps selected tag filters when date filters are changed or cleared. It helps website visitors and editors get more consistent blog navigation without losing their chosen filters.
Original PR description
This PR addresses the following issues: **Issue 1: Date Misalignment** **Steps to Reproduce:** 1. Navigate to website → Blog Page → Edit. 2. Change the layout from Grid to List. 3. Toggle the Cards…
This PR addresses the following issues:
**Issue 1: Date Misalignment**
**Steps to Reproduce:**
1. Navigate to website → Blog Page → Edit.
2. Change the layout from Grid to List.
3. Toggle the Cards button on.
4. The date and tags will appear slightly misaligned.
**Solution:**
Adding `#{` code in the `t-attf-class` attribute will align the date with the blog post content and tags.
**Expected Behavior:**
The date should align with the blog post content and tags preview.
**Issue 2: Some Tag Filters Getting Removed**
**Steps to Reproduce:**
1. Add a date filter from the sidebar of the blog.
2. Remove this filter by clicking the X button.
3. If multiple tags are present in the filter section, only the first tag remains while the rest are removed when the date filter is added or removed.
**Solution:**
Sending a POST request whenever the date filter is selected or removed. To achieve this, we introduced the `post_link` class to the `<select>` and `<a>` elements. When a date option is chosen, the click event triggers the `_onClickPost` handler
function, which extracts the URL from the `value` attribute of the `<option>` tag.
**Expected Behavior:**
All previously added tags should remain after adding or removing the date filter.
**Issue 3: All Tag Filters Getting Removed**
**Steps to Reproduce:**
1. Navigate to website → Blog Page → Turn On the Sidebar.
2. Select any tag from the tags section in the sidebar.
3. Ensure no blog is selected.
4. Select a date from the archives in the sidebar.
5. Change the date to '-- All Dates' in the archives dropdown.
6. All tags in the filter are removed along with the date.
**Solution:**
Removing the condition for navigation based on whether a blog is present or not will ensure tags remain in the filter section after selecting the '-- All Dates' option.
**Expected Behavior:**
Tags present in the filter section should remain after selecting the '-- All Dates' option.
task-3937884
Forward-Port-Of: odoo/odoo#230592
Forward-Port-Of: odoo/odoo#225845UrbanPiper POS orders now apply the correct taxes when a store operates under a branch company. This prevents missed taxes on order lines and improves accuracy for businesses using multi-branch setups, including cases where taxes are split into sub-taxes.
Original PR description
Steps to reproduce: --- - Install `pos_urban_piper`. - Create a branch under *Main Company*. - Switch to the new branch. - Create a POS config in this branch and set up UrbanPiper. - Sync "Apple Pie". - Place an order with "Apple Pie". Issue: --- - The 15% tax defined on Apple Pie is not applied on the orderline. Cause: --- - While creating the order line, the tax company was compared directly with the POS config’s company. In this case, the tax belongs to the parent company, while the POS config belongs to a child company. Fix: --- - Compare the `root_id` of both companies instead of the direct company ID to ensure taxes are applied correctly in multi-branch setups. - Additionally, handled the case where a main tax has sub-taxes (e.g., 5% GST split into 2.5% SGST and 2.5% CGST). In such cases, we now fetch the tax type from the sub-taxes instead of the main tax. Task-5050682 Forward-Port-Of: odoo/enterprise#96672 Forward-Port-Of: odoo/enterprise#93467
Invoices eligible for early payment discounts now remain marked as partially paid when only part of the amount is paid. This prevents unpaid balances from being incorrectly moved to a suspense account, improving payment accuracy and receivables reporting.
Original PR description
Problem: If partial payment is done for Invoice which is eligible for early payment discount, Invoice is marked as paid and remaining amount is debited in suspense account. Cause: While preparing credit entry for receivable account, only eligibility of Invoice for early payment discount was checked and whole residual amount of Invoice is credited instead of amount which is paid, and this is done for partial payments also(which shouldn't be done). After this commit: If partial payment is done for Invoice which is eligible for early payment discount, Invoice is marked as partially paid and only amount which is paid is credited from receivable account and nothing in suspense account. task-5128802 Forward-Port-Of: odoo/enterprise#95994
This fix prevents the Point of Sale configuration from entering an endless update cycle when no default or available preset is set. It helps ensure POS settings can be saved reliably in empty or newly configured setups.
Original PR description
The condition `config.default_preset_id.id not in config.available_preset_ids.ids` is equivalent to True when both default_preset_id and available_preset_ids are empty. This triggers an infinite loop as assigning with `|=` triggers a nested write. 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 fixes an issue where bold text inside blog quote blocks could not be reapplied correctly after being toggled off. Blog editors can now use bold formatting in quoted text reliably, improving editing accuracy and reducing formatting frustration.
Original PR description
Problem: The bold check inside a blockquote in Website Blog is incorrect. Cause: `isBold` checks if the node’s computed font weight is higher than `500` or if the `closestBlock` has a different weight than the node. However, this is wrong when an ancestor (that is not a block) has a different font weight — that ancestor should also be considered in the check. Solution: Instead of comparing with the `closestBlock`, find the closest ancestor that has a different computed font weight and use it for the bold check. Steps to reproduce: 1. Go to a blog post. 2. Select text inside a blockquote that is already bold. 3. Click the bold button → bold is removed. 4. Click the bold button again → text is not bold (incorrect). task-2906482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Printing Kanban views with many records now handles page breaks more reliably. This prevents records from being cut off across printed pages, making printed reports easier to read and share.
Original PR description
This commit fixes the kanban view print to better handle the page break. The issue was caused by the flex layout: when printing, heights often misbehave on the last row or at page breaks. task-4630646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230927 Forward-Port-Of: odoo/odoo#229259
The customer portal now shows the invoice delivery preference explanation only when the related choice field is actually available. This prevents customers from seeing confusing guidance for an option they cannot change.
Original PR description
Currently, there is no validation in place to determine when the labe related to invoice_sending_methods should be added to the portal_my_details_fields template in the inheritance made in [1].
This results in the following:
For invoice_sending_methods, the label/message: 'You can choose how yo want us to send your invoices, and with which electronic format.' is always displayed, even if the <select> to define the method is not visible.
Now, a validation has been added to display this label only when necessary, in order to avoid user confusion.
[1]: https://github.com/odoo/odoo/commit/de567b6
Before:
After:
Forward-Port-Of: odoo/odoo#229962
Forward-Port-Of: odoo/odoo#200261Recruitment users can now add applicants to a talent pool without being blocked by employee access permissions. This prevents an unnecessary error and keeps the talent pool workflow usable for recruiters with limited employee data access.
Original PR description
Steps to reproduce: ==================== 1. Grant admin access for Recruitment to demo user. 2. Go to the Recruitment app. 3. Open Applications > Talent Pool. 4. Select a talent pool. 5. Click "Add to pool". Problem: ========= If the user lacks read access on Employees, an access error occurs. This happens because `_add_applicants_to_pool` tries to access `proposed_contracts`, https://github.com/odoo/enterprise/blob/95b9942316c962950ace6b899faa6f1e6c8fee9a/hr_contract_salary/models/hr_applicant.py#L17 which triggers a read on `hr.version`. Since `hr.version` uses `_order`, https://github.com/odoo/odoo/blob/f0eb0c792b77fbaf0ef3738ea88d9c2bae880a85/addons/hr/models/hr_version.py#L28 it tries to sort the result, leading to a access rights error. Fix: ==== Use `sudo` when calling _add_applicants_to_pool. opw-5074018 Forward-Port-Of: odoo/odoo#227246
When a user types a full URL and it is automatically turned into a link, opening that link now correctly shows the option to replace the URL text with the page title. This makes the editor experience clearer and helps users create more readable links without extra steps.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Type a full valid URL e.g. `https://odoo.com` - Press space to create link. - Open popover by clicking on link. There is no banner at the bottom of popover showing "Replace URL with its title?" when a newly link is created. After merging this commit [1], When the link popover is opened for the first time, replace title option should be visible in the popover. **Desired behaviour after PR:** Now, replace title banner is shown at the bottom of popover if link is created by transformation. [1]: https://github.com/odoo/odoo/commit/7da241d6fd3a3fa1e6d617b436d397b5b28320cf task-5085975 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227391
The Dutch localization now uses the correct default accounts for deferred revenue and expenses. This helps Dutch companies post deferred items to the right balance sheet accounts and improves accounting accuracy when setting up or using the localization.
Original PR description
The default deferred accounts in the Dutch localization were incorrect. This commit sets the proper accounts and adjusts the `account_type` of the default deferred expense account from "Prepayments" to "Current Assets". task-5152529 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230902 Forward-Port-Of: odoo/odoo#230499
This update removes a repeated condition in the purchase stock logic. It is a small cleanup that reduces the chance of confusion during future maintenance without changing expected business behavior.
Original PR description
The same field is used twice in the condition at [1]. This commit removes duplicate code. [1]- https://github.com/odoo/odoo/blob/b84741d494f12b8d595b2977bc5bc40da39eed89/addons/purchase_stock/models/stock_move.py#L150 No task ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-ordering product screen now shows the missing required details prompt only when it is useful, such as when multiple attributes overflow the visible area. This reduces unnecessary on-screen clutter and fixes the arrow button display so customers get clearer guidance while ordering.
Original PR description
Before this commit: ================ - `MissingRequiredDetails` template was always displayed and had no condition based on the product attributes and screen layout. - The arrow-up icon inside the template was not displayed properly. After this commit: ================ - Added `shouldDisplayMissingAttributes()` method to handle conditional display. - The component now shows only when content overflows and there are multiple attributes. - Fixed the button styling so the arrow-up icon displays correctly. Task - 5153070 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
CRM and subscription spreadsheet dashboards now calculate key totals correctly and load the sales pipeline view with a more relevant recent-time filter. This improves dashboard accuracy and makes record drill-downs less likely to apply unintended filters or defaults.
Original PR description
See commit messages
The Point of Sale checkout now handles repeated selection of an online payment method without crashing. This prevents interruptions during payment processing and helps cashiers complete sales smoothly.
Original PR description
Steps to Reproduce(On Runbot): - Navigate to Pos>Configuration>Payment Method - Create an 'Online Payment' method using 'Demo Payment' for a shop (e.g., bakery shop). - Open a session for the bakery shop, select any product, and proceed to payment. - Select the online payment method multiple times. Error: `TypeError: Cannot read properties of undefined (reading 'currency')` After this commit: - Users can select the payment method multiple times without a crash. task-5122932
This fix removes reliance on a Python internal detail that may be missing in some supported Python versions. It helps avoid failures for customers running affected Python 3.10 or 3.11 environments, with no expected change to user-facing behavior.
Original PR description
This is a private variable of the stdlib, it was added in Python 3.12 (python/cpython#102508) and only backported to 3.11.4 (python/cpython#104575) and 3.10.12 (python/cpython#104592) so is not necessarily available in versions of 3.10 and 3.11 clients might be running. So embed the content into the file directly to avoid depending on the stdlib. Not to mention the concept of C0 is not exactly novel or mutable. Also inline it in its sole use, there's no reason to have multiple string literals and a runtime concatenation. Fixes #230990
This change corrects how the Belgian reports partner form is extended so the citizen identification field is found in the right view. It prevents errors when updating Belgian reporting-related modules, improving upgrade reliability for affected databases.
Original PR description
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view. That led to…
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view.
That led to a traceback when updating account_reports/l10n_be_reports modules in 19.0+ versions:
This fix PR is a backport requested from upgrade: https://github.com/odoo/enterprise/pull/92104#pullrequestreview-3144302023.
```py
Odoo Server Error
Occured on 86642809-master-all.runbot135.odoo.com on model ir.module.module on 2025-08-11 14:04:32 GMT
Traceback (most recent call last):
------- A lot of calls ------
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/data/build/odoo/odoo/tools/convert.py", line 745, in convert_xml_import
obj.parse(doc.getroot())
File "/data/build/odoo/odoo/tools/convert.py", line 616, in parse
self._tag_root(de)
File "/data/build/odoo/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/data/build/odoo/odoo/tools/convert.py", line 570, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /data/build/enterprise/account_followup/views/partner_view.xml:4
Error while parsing or validating view:
Element '<xpath expr="//field[@name='citizen_identification']">' cannot be located in parent view
View error context:
{'file': '/data/build/enterprise/account_followup/views/partner_view.xml',
'line': 1,
'name': 'res.partner.view.form',
'view': ir.ui.view(5824,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(127,),
'xmlid': 'res_partner_view_form'}
```
Forward-Port-Of: odoo/enterprise#96855Payroll processes now identify a company's country through its linked partner record instead of relying on a company field that cannot be searched. This prevents payroll and Swiss payroll exports or transmissions from failing or missing companies because of that lookup issue.
Original PR description
As the country_id field on the company is computed and not searcheable, this commit adapts the domain to search for the country of the associated partner. task-5096037 Forward-Port-Of: odoo/enterprise#95255
The Invoices dashboard has been corrected so the Top Invoices list updates when users apply a time filter. This keeps dashboard figures consistent and helps teams make decisions from the right reporting period.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When assigning a future driver to a vehicle, the system now marks only the driver's other vehicles as planned for change. This avoids incorrectly flagging the vehicle being assigned, helping fleet managers keep vehicle transition plans accurate.
Original PR description
WHen a new vehicle is created for someone in a non waiting column, we are settign his other cars in plan_to_change. When we set a future driver on a car, we set the others as plan to change, but not the one on which we are setting the future_driver --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230952
The Point of Sale flow now stops order validation when a cashier cancels the required customer popup for Customer Account payments. This prevents incomplete orders from causing an error and keeps the checkout experience stable.
Original PR description
Steps to reproduce: =================== - Open POS and add a product to the cart - Go to the Payment screen - Select `Customer Account` as the payment method and Validate Order - The `Customer Required` popup appears - Click `Cancel` on the popup Issue: ====== - POS still continues with the order validation process - This leads to a traceback since the order data is incomplete Cause: ====== - The `_askForCustomerIfRequired()` always returned a value that allowed validation to continue - As a result, validation continued even after clicking Cancel Fix: ==== - `validateOrder()` now checks the return value and aborts validation if the user cancels the popup Task: 5094722
Opening a manufacturing Bill of Materials overview could fail when Odoo tried to plan a very large producible quantity beyond work center capacity. The system now falls back to the actually requested quantity, allowing users to view the overview and continue replenishment planning.
Original PR description
### Steps to reproduce: 1. Install mrp + purchase 2. Create a new product (A) 1. Add the Buy route on the product 2. Add a vendor line on the Purchase tab 3. Set the quantity on hands to 2000 3.…
### Steps to reproduce: 1. Install mrp + purchase 2. Create a new product (A) 1. Add the Buy route on the product 2. Add a vendor line on the Purchase tab 3. Set the quantity on hands to 2000 3. Create a second product (B) with manufacturing route 4. Create a BoM for this product (B) 1. Add the product (A) as the component with 1 quantity 2. Create a new operation with a duration of 600:00 5. On the product B's page, click Replenish 1. Put 10 quantities to replenish 2. Select the manufacturing route and confirm 6. Go to the BoM and open the BoM overview 7. 'Impossible to plan. Please check the workcenter availabilities.' https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715 ### Before this commit: When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed. ### After this commit: If the quantity producible cannot be planned, we retry automatically with the requested quantity. opw-5031724 Forward-Port-Of: odoo/odoo#229745 Forward-Port-Of: odoo/odoo#227433
The Point of Sale scan button now reliably opens the camera to scan a QR code even when an order is selected on the ticket screen. This helps cashiers continue scanning without switching screens or clearing their selection, reducing checkout friction.
Original PR description
Before this commit: = - The scan button did not function when an order was selected. After this commit: = - The scan button now opens the camera to scan a QR code even when an order is selected. Task: 4778136 Forward-Port-Of: odoo/odoo#230868 Forward-Port-Of: odoo/odoo#211875
Employee attendances left open from previous days will now be closed correctly by the automatic checkout process. This prevents stale attendance records when the server was offline or the scheduled job did not run for more than a day.
Original PR description
Problem: the auto-checkout feature was basing the computation on the fact that the unclosed attendance was starting today. However, it might not always be the case, for example if the server is shutdown for more than 24 hours after checking in. Steps to reproduce: - Activate the auto-checkout feature - Create an open-ended attendance for two days ago - Run the cron - Result: the attendance is not closed. This commit solves the issue by taking into account the days delta between today and the check-in date. task-5082359 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#227981
The working schedule calendar now shows the hours-per-week value on a single line. This small visual fix makes employee schedule information easier to read and avoids awkward wrapping in the interface.
Original PR description
Changed the style of hours/week in working schedule calendar so it doesn't appear on 2 lines task-id: 5003432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231237
The Attendance kiosk barcode scanner now opens correctly when debug mode is enabled. This prevents an error screen caused by sending unsupported data to the scanner dialog, helping administrators and testers use kiosk mode reliably.
Original PR description
**Step to reproduce:** - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode - open the scanner **Observation:** - We get a traceback **Cause:** - we pass a extra prop `token` to BarcodeDialog component, which is not accepted by it https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L12 - this raises issue from OWL when we have debug-mode on **Fix:** - reuse the actual `scanBarcode` method and remove the faulty one. https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L47-L60 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227715 Forward-Port-Of: odoo/odoo#225738
Saving an overtime ruleset without a required quantity period no longer causes an unexpected system error. Users now receive the intended validation message, making the attendance setup flow clearer and preventing confusion during configuration.
Original PR description
Currently, an error occurs when user saves an overtime ruleset.
Steps to reproduce:
- Install the `hr_attendance` module.
- Go to `Overtime Rulesets` and create a rule.
- Add an `overtime rule` in this `ruleset` with:
- `Rule is based on: Quantity`
- and `clear the 'If the worked hours on' field`.
- Save the `rule` and `ruleset`.
`TypeError: UserError.__init__() got an unexpected keyword argument 'name'`
This error occurs when a user saves the ruleset without setting the rule's quantity period, and due to two arguments being wrongly placed in the ValidationError[1], the error is raised.
This commit ensures that the validation error works correctly by passing a single argument.
[1]: https://github.com/odoo/odoo/blob/34409128de0bb84cdee309b031b307c46d8b07c7/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L147
sentry-6932048427
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe QR Menu for Belgian blackbox-enabled Point of Sale setups no longer shows a blank page when the register session has not been opened. This ensures customers can still view the digital menu as expected, avoiding lost service availability before the PoS session starts.
Original PR description
When you open the QR Menu of a PoS that uses the blackbox, the menu will not appear if the session is not opened. Steps to reproduce: ------------------- * Setup a PoS to use the blackbox * Setup the same PoS to use the QR Menu * Try to open the menu without opening the PoS > Observation: The QR Menu never show anything, the page stays blank. Why the fix: ------------ Here (https://github.com/odoo/enterprise/blob/0635388bdc9f115d527e0d2da43dfcd0d4a00d1f/pos_blackbox_be/static/src/self_order/overrides/services/self_order_service.js#L61-L62) if the session is not opened, we try to read `_product_product_work_in` on session that is undefined. opw-4829700 Forward-Port-Of: odoo/enterprise#93196
Swiss payroll salary rule screens now include the same configuration options that were already available in the backend. This helps payroll administrators review and manage wage type settings more reliably without switching to technical views.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
Fixed an issue where point of sale quick-add payment buttons such as +10 or +50 could calculate wildly incorrect amounts for users in languages that use a comma as the decimal separator. This ensures cashiers can rely on the buttons to add the intended payment amount, reducing checkout errors.
Original PR description
**Steps to reproduce:** - Set your database in a language with a "," as a decimal separator, such as French - Make a purchase, chose a payment method - Before paying, click any +10/20/50 button - The…
**Steps to reproduce:** - Set your database in a language with a "," as a decimal separator, such as French - Make a purchase, chose a payment method - Before paying, click any +10/20/50 button - The price will be multiplied by 100, then add the desired amount **Why the fix:** There were two places where the decimal separator was causing issues. First when we try to get the current price, *currentBufferValue*, we try to get it when it's in float state, but as we have a language with a decimal separator set as "," the "." in this float will be ignored, and we will take the decimal as units as well, explaining the *100 amount, because the decimals become whole numbers. Secondly, when we try to make the addition of the two and convert it to string again, the *toString* method will convert it with a default "." not taking the current decimal separator into account. Once again, the "." will be ignored later on, leading to an even more over the top number. We now convert the numbers and the strings using the correct decimal separator. opw-5126224 Forward-Port-Of: odoo/odoo#229735
Fixes an issue where users could see a misleading connection warning when joining or following a Discuss call from another browser tab. The warning now appears only where connection details are actually available, reducing confusion during calls.
Original PR description
Before this commit, the forward port[1] of a call indicator fix[2] did not account for the cross-tab call feature[3], introduced in saas 18.2 which makes it possible to be considered inside a call without having connection state information (as the remote tab does not manage connections), thus incorrectly showing the connection state indicator. [1]: https://github.com/odoo/odoo/pull/229166 [2]: https://github.com/odoo/odoo/pull/228601 [3]: https://github.com/odoo/odoo/pull/198109 Forward-Port-Of: odoo/odoo#231170
This fixes a crash that could happen when a user hid an HTML field while newly added images were still being processed. The editor now preserves the content safely during that delay, helping users avoid interruptions and potential lost edits.
Original PR description
**PROBLEM** When hiding a HtmlField field from a view with pending images in it, there is a traceback. **STEP TO REPRODUCE** 1. Using studio, create a HtmlField on the view of your choice. 2. Add a…
**PROBLEM** When hiding a HtmlField field from a view with pending images in it, there is a traceback. **STEP TO REPRODUCE** 1. Using studio, create a HtmlField on the view of your choice. 2. Add a checkbox next to it, and link the HtmlField visibility to the button. 3. Add a image to the HtmlField (don't save the record !) 4. Hide the HtmlField using the checkbox, there should be a traceback. (if not, try with a bigger image). **CAUSE** commitChanges() will try to retrieve the field value to commit by looking at the related element in the DOM. Before retrieving this value, we call savePendingImages() to save the new images added to the HtmlField. https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/html_editor/static/src/fields/html_field.js#L159-L162 This introduces a delay, during which the DOM element could be destroyed. **FIX** We don't call commitChanges() in OnBlur(). Instead, we cache the new value in a property of HtmlField called `newValue` when `OnChanges()` is called. Inside OnBlur(), we save the pending images by directly calling `savePendingImages()` and we commit the new value by calling `updateValue(this.newValue)` opw-5061820 Forward-Port-Of: odoo/odoo#230980 Forward-Port-Of: odoo/odoo#227482
This fix prevents an error when a user clears the period date while creating or editing a payslip. It helps payroll users continue their work without an unexpected crash when required date information is missing.
Original PR description
This error occurs when the user removes the period date from the payslip. Steps to reproduce: --- - Install `hr_payroll` module - Create a New Payslip - Add `Employee` and remove `Period` date Traceback: --- `TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'` This error occurs because at [1], the `date_to` field is received as `False` after the date is removed from the payslip. [1]: https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/hr/models/hr_version.py#L388 sentry-6925445279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when a payroll user removes the period date from a payslip. It keeps payslip editing stable and avoids an unexpected interruption during payroll preparation.
Original PR description
This error occurs when the user removes the period date from the payslip. Steps to reproduce: --- - Install `hr_payroll` module - Create a New Payslip - Add `Employee` and remove `Period` date Traceback: --- `TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'` This error occurs because at [1], the `date_to` field is received as `False` after the date is removed from the payslip. [1]: https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/hr/models/hr_version.py#L388 sentry-6925445279
This fixes an issue where refund requests for payment providers other than Adyen could lose their expected result. It helps keep refund processing reliable across all supported payment providers.
Original PR description
Commit [efc2788](https://github.com/odoo/odoo/commit/efc2788) introduced bug. Ensure _send_refund_request returns the value from super() when the provider is not Adyen.
Corrected a misspelled database table name used during payroll data neutralization. This prevents the cleanup process from failing, helping ensure test or sanitized databases are prepared correctly.
Original PR description
There is a `s` in the table name of `ir_config_parameter`
```py
2025-10-14 12:30:43,043 278 ERROR ? odoo.sql_db: bad query: b"DELETE FROM ir_config_parameters WHERE key = 'l10n_au_payroll_iap.endpoint';\nUPDATE res_company SET l10n_au_payroll_mode = 'test';"
ERROR: relation "ir_config_parameters" does not exist
LINE 1: DELETE FROM ir_config_parameters WHERE key = 'l10n_au_payrol...
^
2025-10-14 12:30:43,043 278 CRITICAL ? odoo.cli.neutralize: An error occurred during the neutralization. THE DATABASE IS NOT NEUTRALIZED!
```Edited messages now place the “edited” label at the end of the final paragraph instead of adding it after the full message content. This prevents unwanted extra line breaks and keeps edited messages visually clean for users.
Original PR description
When a message is edited, the "edited" label should be added at the end of the last paragraph/div. In this case, there is no extra line break added. This is due to the fact that the body now is sent as a full HTML fragment and not plain text. So we should create the "edited" node and append it to the last paragraph/div rather than directly appending the HTML string. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product descriptions in accounting documents now display as regular text when users are not editing them. This prevents layout height issues and makes product lines appear more reliably in forms and sales-related views.
Original PR description
The product_label_section_and_note_field product description used a textarea even outside edition. This caused height miscalculations due to a conflict between the autoresize and magicColumnWidth hooks. To fix this, the description is now rendered as plain text when not in edit mode, ensuring autoresize only applies once the field enters edition. task-5040151
Discuss now handles encrypted or unreadable PDF attachments without showing an error. Users can continue uploading files normally, while invalid previews are handled gracefully instead of interrupting their workflow.
Original PR description
Currently, an error occurs when trying to preview the first page of a PDF attachment in Discuss if the PDF is `encrypted` or contains `invalid encoding`. **Steps to produce:** - Install the `mail`…
Currently, an error occurs when trying to preview the first page of a PDF attachment in Discuss if the PDF is `encrypted` or contains `invalid encoding`. **Steps to produce:** - Install the `mail` module. - Open `Discuss` and attach the encrypted file [1], or the invalid PDF file [2]. (`Note`: Ensure Python version 3.12+ is used.) **Error:** `PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm` `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa4 in position 0: invalid start byte` **Root cause:** At [3], `extract_page` directly calls `PdfFileReader`, when it fails to read or decrypt the file, Python raises an error. **Fix:** This commit prevents errors when a user attaches a PDF file that is unreadable or encrypted. [1]: https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing [2]: https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing [3]: https://github.com/odoo/odoo/blob/11cbbb85b1ee2a620d752b79e86fc51a8e3b33e4/odoo/tools/pdf/__init__.py#L227 sentry-6912765819
The duplicate transaction warning in bank reconciliation was not taking users to the tool for finding duplicates. This fix restores that link, helping accounting users quickly review and resolve possible duplicate bank transactions.
Original PR description
Before this commit, the action "Some transactions may be duplicates." was broken because 2 elements from the old bank reconciliation widget were removed. The commit [[1]] of the new bank reconciliation widget forgot to add the action service and a link to the journal. These 2 elements were used to redirect the customer to the Find duplicates tool. This commit adds, in the extension of the bank reconciliation kanban controller, the call to the action service and adapt the old code to match the new one. no task id [1]: https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109 Forward-Port-Of: odoo/enterprise#96849
Opening an individual contact from a sales order no longer shows the address of the contact's parent company in the company field. This prevents confusing or misleading address information from appearing where it should not be displayed.
Original PR description
Be on a sale order, set as customer a contact that isn't company, but which has a parent_id with an address. From the sale order, open the customer (with the right arrow icon). In the partner form view, the address of the contact's company (the parent_id field) is displayed, it shouldn't. This commit fixes the issue by forcing `show_address: False` on that field, as we never want to see the address there. This overrides the context that is propagated from the many2one field of the sale order form view. opw~5026032 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 fixes a barcode inventory test so it behaves consistently when demo data is installed. The test now matches its intended setup by preventing new lot creation on outgoing transfers, reducing false failures in automated validation.
Original PR description
When running this test with demo data, it will always fail because the option to create new lots on outgoing picking is activated, even though the docstring says it shouldn't be. This fix disable `use_create_lots` on outgoing pickings in accordance with the docstring.
This change prevents upgrade failures when databases with Saudi localization and demo data are updated. It removes an automatic demo setup step that depended on data not yet available during the upgrade, improving reliability without affecting normal business features.
Original PR description
The post_init_hook breaks the upgrade of databases with demo data with l10n_sa installed. The reason is that the upgrade installs it, being in the dependencies. And l10n_account_withholding_tax is installed before l10n_sa is updated. The post init hook then breaks because it gets tags that don't exist yet, appearing in the update of l10n_sa. We remove this post_init_hook as it just tries to create a demo tax to show users how it works. runbot-error-233167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Peppol advanced fields module is being marked as deprecated because it was released before it was ready and still lacks important functionality. This helps prevent businesses from installing an incomplete feature while a better solution is prepared.
Original PR description
This module was merged prematurly, it's not fully working and still lacks important features. We'll come up with a better solution, in the meantime we try to avoid that people install it. task-none
Fixes an issue where creating a new email marketing message could crash if the company logo had been removed. Users can now select mail templates normally, and the system only displays a logo when one is available.
Original PR description
Currently, an error occurs when a user selects a mail template after removing their company logo. **Steps to replicate** * Install `mass_mailing` * Companies > YourCompany > Remove company logo *…
Currently, an error occurs when a user selects a mail template after removing their company logo.
**Steps to replicate**
* Install `mass_mailing`
* Companies > YourCompany > Remove company logo
* Email Marketing > New > Start From Scratch
**Error:**
```
`QwebError:
Error while rendering the template:
KeyError: 'user'
Template: mass_mailing.s_mail_block_header_social
Reference: 805
Path: /t/section/div/div/div[1]/div/a/img
Element: <img class='o_b64_image_to_save o_editable_media' t-att-src='image_data_uri(company_id.logo if company_id.logo else user.company_id.logo)'...`
```
**Root cause:**
* This error occurs because [1] tries to access `user` after the company logo is removed. As shown in [2], `user` isn’t in values but exists in `env` or as `user_id` ,causing a key error and a qweb exception.
* The template change that introduced this behavior was made after commit [3].
**Solution:**
* Show the logo only if at least one is available, similar to the approach in `18.4` [4]. Without this condition, the template fails when both the selected company and the user's default company are the same and have no logo. This leads to a type error at [5] because accessing the logo through the user returns `False`, and a boolean is not subscriptable.
[1]:
https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/addons/mass_mailing/views/snippets/mass_mailing_headers_snippets.xml#L9-L10
[2]:
https://drive.google.com/file/d/1XwASk3CGcfkVk7sifuqZE7t_QtCZpuRU/view?usp=sharing
[3]:
https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6#diff-8f450b28258a6e33b353e751dcb8c71e5ac6c93743efe6eea35a8744d9f7d6b5
[4]:
https://github.com/odoo/odoo/blob/3a712861be1e3536e593a94e741457840da46907/addons/mass_mailing/views/snippets_themes.xml#L90
[5]:
https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/odoo/tools/image.py#L562
sentry-6923986938Fixed the display of Time Off alerts so Indian sandwich leave warnings no longer appear collapsed when creating a new request. Alert spacing is now consistent, making important leave information easier for employees and HR teams to notice.
Original PR description
Issue: The sandwich leave alert for l10n India was incorrectly shown folded when creating a new time off entry for Indian companies. Additionally, the leave_type_increases_duration alert lacked proper top margin, causing inconsistent spacing. Steps to Reproduce: - For the sandwich alert: When shown, it appears folded automatically when creating a new time off entry (only for Indian companies). - For leave_type_increases_duration: When displayed, it lacks top margin. Fixes: - Moved the sandwich leave alert to the header alongside other alerts for consistency. - Adapted margins for all alerts. Task ID: 5071899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226229
This fix ensures that when a point of sale payment is force-completed, the system correctly clears the in-progress terminal payment state. Cashiers can then start another card terminal payment without payment options becoming unavailable.
Original PR description
Before this commit, the function sendForceDone was not setting paymentTerminalInProgress to false, which blocked the user from doing another terminal payment as the payment methods linked to a terminal are not clickable. After this commit, sendForceDone can be used without blocking future terminal payments. opw-4978772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231098 Forward-Port-Of: odoo/odoo#230969
The Belgian reporting module now uses clearer descriptions and updated translations for audit checks. This helps users understand compliance checks more easily across supported languages without changing business processes.
Images placed inside website card snippets now follow the same rounded corners as the card itself. This fixes a visual inconsistency so website content looks cleaner and more polished.
Original PR description
Specification: - Border radius on the image in the card snippet was not being applied correctly. - Border radius should be consistent with the card's border radius. After this commit: - The image inside the card snippet will now correctly inherit the border radius from the card. - This change ensures that the image appears rounded in the same way as the card itself. task-4848288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213632
Close buttons in website popups, side panels, and notifications now automatically adapt to the site's chosen color palette. This keeps these interface elements readable and visually consistent across different website designs.
Original PR description
This commit makes `.btn-close` color dynamic based on the color palette of the website. Impacted components that are using `.btn-close`: `.modal` (e.g.: `.o_sale_product_configurator_dialog` `.offcanvas` (e.g.: `#o_wsale_offcanvas`) `.o_notification` task-4630175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221047
This fixes the value used when neutralizing Nemhandel users so it matches the expected Nemhandel proxy type. It helps ensure the related cleanup or deactivation process targets the right users and avoids incorrect handling caused by the previous value.
Original PR description
The value to neutralize a user should be nemhandel and not l10n_dk_nemhandel --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231264
Code cleanup and technical improvements
A reusable checkbox display component has been moved into the core web area so more Odoo apps can use it without extra dependencies. It also gains an option to show checkboxes in a vertical list, improving flexibility for future screens such as database-related features.
Original PR description
### [REF] account,web: move widget json_checkboxes to web The `json_checkboxes` widget could be used in other modules than `account` and its descendants. With this commit, we move it to `analytic`, which is shared by a lot more modules, which will make it available to them. In particular, we will use it in the new enterprise `databases` module. We keep the name account_json_checkboxes for the stable backward compatibility. Task-id: 5062431 ### [IMP] web: add stacked mode to widget json_checkboxes With this commit, the json_checkboxes widget, which displays inlined checkboxes by default, now has a `stacked` option that allows displaying the checkboxes in a column. Task-id: 5062431