Daily updates from Odoo
Tuesday, October 14, 2025
213 changes
16 changes
Resolved issues and error corrections
This update improves Odoo's internal Hoot testing tools so automated tests better match real browser behavior and produce clearer failure reports. It also simplifies how developers use test helpers, reducing confusion while keeping the changes limited to the testing ecosystem and lowering risk for business features.
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
This update adjusts an internal test workaround in the Gantt planning area so automated checks continue to run correctly after recent testing changes. It is limited to the unit test environment and should not affect day-to-day product behavior.
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 fixes an internal Peppol test so it no longer depends on Belgian localization logic that may not be present in all build configurations. The change helps keep Odoo's automated checks stable and reduces false failures during releases.
Original PR description
This commits fixes test we previously added [1]. In Belgium, the Company Registry (0208) and the VAT number (9925) can be computed from each other (`0208:0400000000` <-> `9925:BE0400000000`). [This compute](https://github.com/odoo/odoo/blob/0d8aadb2db7f10d439e10f222ec0ab6dcfab3672/addons/l10n_be/models/res_partner.py#L13) is actually only available in l10n_be, while the test rely on it to deduce the expected EAS, and therefore fails on single Apps builds. [1]: https://github.com/odoo/odoo/pull/230880 [runbot-error-233343](https://runbot.odoo.com/odoo/runbot.build.error/233343) Forward-Port-Of: odoo/odoo#231314
This fix prevents the Invoicing dashboard from crashing when users customize its default grouping in Studio and the selected group has no records. The dashboard now handles empty groups gracefully, so users can continue configuring views 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
Users who open a product forecast in a newly created company without any warehouse will now see a clear warning instead of an error. This prevents a confusing crash and helps users understand what setup is missing before viewing stock forecasts.
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
Fixes issues on blog pages where dates could appear misaligned and selected tag filters could be lost when changing archive date filters. This helps visitors keep their chosen blog filters intact and improves the visual consistency of blog listings.
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#225845Point of Sale payments made through a payment terminal now complete automatically when cash rounding is applied. This prevents staff from needing to manually validate fully paid orders, reducing checkout delays and the risk of missed validations.
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
The Subscriptions MRR Breakdown report now ignores archived companies when preparing its data. This prevents access errors in multi-company setups where the original company has been archived and another company with a different currency is active.
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
Invoices that qualify for an early payment discount are no longer incorrectly marked as fully paid when only a partial payment is received. This prevents the unpaid balance from being moved to a suspense account, giving accounting teams a more accurate payment status and cleaner reconciliation.
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
UrbanPiper POS orders now apply the correct product taxes when the POS is set up under a company branch. This prevents undercharged orders in multi-branch setups and also handles split taxes such as GST more reliably.
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
This fixes an issue where time off spanning two allocation periods could incorrectly count a public holiday as extra leave. Employees and HR teams will see more accurate leave balances when vacations overlap public holidays at the start of a new allocation period.
Original PR description
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to…
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan) - Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026) ### Cause: When we are checking the leave duration after having a public holiday the will return the attendance without the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days. https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230 https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254 ### Fix: We check for public holidays in the interval we are fetching its attendance to avoid assuming it is an excess days in the leave opw-5006119 Forward-Port-Of: odoo/odoo#230861 Forward-Port-Of: odoo/odoo#225433
This fix prevents an invoice delivery preference message from showing when customers cannot actually choose a delivery method. It reduces confusion on the customer portal by only displaying the guidance when the related option is visible.
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#200261Printing Kanban views with many records now handles page breaks more reliably. This prevents cards from being cut off at the top of later pages, making printed views easier to read and use.
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
Payroll processes now identify a company's country through its linked partner record instead of a field that cannot be searched reliably. This helps payroll exports and Swiss payroll transmissions select the correct companies without search errors.
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 Dutch accounting setup now uses the correct default deferred accounts. This helps Dutch companies start with more accurate accounting configuration, including classifying deferred expenses under current assets.
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
Fixes an error that could block Romanian E-Factura submission when a bank is linked to an invoice payment reference. The change ensures bank address details are read correctly, improving reliability for electronic invoicing workflows.
Original PR description
Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for rev.bank. Cause: The state field is defined differently for rev.bank and rev.partner. rev.partner uses state_id, while rev.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for rev.bank. Fix: The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly. Test: Linked the bank in the test suite. The test fails without this fix, confirming the issue is resolved. opw-5099816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
9 changes
Resolved issues and error corrections
This fix prevents the Accounting dashboard from showing an error when Studio is used to group it by a category with no records, such as online account links when none are connected. Users can now adjust the default dashboard grouping without interruption, even when the selected group is empty.
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
Users opening a product's forecast view in a newly created company without a warehouse now see a clear warning instead of an error. This prevents a confusing crash and helps users understand that a warehouse must exist before stock forecasts can be shown.
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
The Subscriptions MRR Breakdown report now ignores archived companies when preparing report data. This prevents an access error in multi-company setups where the original company was archived and another active company is used.
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
The duplicate transaction warning in bank reconciliation now works again. Users who see the banner can be directed to the tool for finding duplicate transactions, reducing confusion and helping them clean up bank data.
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
The customer portal now shows the invoice delivery preference explanation only when customers can actually choose an invoice sending method. This avoids confusing customers with guidance for an option that is not visible or available.
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#200261The Dutch accounting localization now uses the correct default accounts for deferred expenses and revenues. This helps companies in the Netherlands post deferred items to the right balance sheet categories by default, reducing manual corrections and reporting errors.
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
Printing Kanban views now handles page breaks more reliably when records span multiple pages. This prevents cards from being cut off at the top of later printed pages, making printed reports easier to read and use.
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
Payroll features now identify a company's country through its linked partner record instead of relying on a field that cannot be searched directly. This helps payroll and Swiss payroll processes correctly find relevant companies and avoid errors in country-based filtering.
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
This fix keeps text colors and gradient formatting intact when users change heading styles inside lists. It also prevents formatting issues with checklist strike-throughs and avoids invalid nested formatting when continuing to type after a list.
Original PR description
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list…
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list item. - Move the cursor outside the list by pressing Enter twice and start typing in the new container. Current behavior before PR: - When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent. - This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`. Desired behavior after PR is merged: - All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element. - Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice. task-5039499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224262
5 changes
Resolved issues and error corrections
The subscription MRR Breakdown report now ignores archived companies when preparing report data. This prevents an access error in multi-company setups where the original company was archived and another company uses a different main currency.
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
The working schedule calendar now keeps the hours per week information on one line. This makes employee schedule details easier to read and avoids awkward line breaks in the interface.
Original PR description
Changed the style of hours/week in working schedule calendar so it doesn't appear on 2 lines Forward-Port-Of: odoo/enterprise#96774 Forward-Port-Of: odoo/enterprise#91993
This update corrects how payroll features identify companies by country, using the country on the linked partner record instead of a company field that cannot be searched reliably. This helps ensure Swiss payroll and work entry export flows find the right company records and avoid incorrect filtering.
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
This fix corrects how a Belgian reporting partner form customization is connected, preventing update failures during module upgrades. It helps ensure Belgian tax reporting features continue to install and update reliably without server errors.
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#96855Fixed an issue where the QR Menu could show a blank page for Belgian blackbox-enabled Points of Sale when the PoS session had not been opened. Customers can now view the menu as expected, avoiding a blocked self-ordering experience.
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
24 changes
Resolved issues and error corrections
Creating a Belgian company with an alphanumeric ZIP code no longer triggers an error. The system now skips regional assignment when the ZIP code is not valid for Belgium, preventing interruptions during company setup.
Original PR description
Currently, in the Belgium localization, creating a company with an alphanumeric ZIP code raises an error. **Steps to Reproduce:** 1) Install **account,l10n_be_reports** module 2) Navigate to…
Currently, in the Belgium localization, creating a company with an alphanumeric ZIP code raises an error. **Steps to Reproduce:** 1) Install **account,l10n_be_reports** module 2) Navigate to **Settings>Users & Companies>Companies**. 3) Create a New Company and first set country as `Belgium` and then set a alpha-numeric value to `ZIP=(e.g. R93R2R3)` 4) Click anywhere on the screen **Error:** `ValueError: invalid literal for int() with base 10: 'R93R2R3'` **Root Cause:** since [this commit](https://github.com/odoo/enterprise/pull/93219/commits/d9f116b5ceda85a11c997b8d46ec9af5425cbf09), a new field `l10n_be_region_id` is computed based on zip as shown at [1]. When an alphanumeric `ZIP` is added, the computation searches the company region based on `zip_start` and `zip_end` as shown at [1]. However, `zip_start` and `zip_end` expect integer values only, as mentioned at [2], which causes the error. **Fix:** Prevent calculation of region for companies with invalid zip code for belgium localization. [1]- https://github.com/odoo/enterprise/blob/424a470188756fffed4437b83d127039795fbe59/l10n_be_reports/models/res_company.py#L37-L45 [2]- https://github.com/odoo/enterprise/blob/71cc92c9526234dcd44ec756375647a67729029f/l10n_be_reports/models/l10n_be_company_region.py#L17-L18 sentry-6931185627 Forward-Port-Of: odoo/enterprise#96736
This fixes an access error in the Subscriptions MRR Breakdown report that could appear after archiving an old company and using a new company's currency setup. The report now only considers active companies, so users can open subscription revenue details without being blocked by archived company data.
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
Invoices eligible for early payment discounts now remain marked as partially paid when only part of the invoice is paid. This prevents unpaid balances from being incorrectly treated as paid or moved to suspense, improving payment status accuracy for accounting teams.
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
Fixes an error that prevented users from validating payments in Point of Sale when using Kenya OSCU electronic invoicing. This ensures sales can be completed normally for Kenyan companies using the POS flow.
Original PR description
**Steps to reproduce:** 1. Install `l10n_ke_edi_oscu_pos`. 2. Set company to a Kenya (KE) company. 3. Open POS → Clothes shop → add a product → go to Payment → try to Validate → traceback occurs.…
**Steps to reproduce:**
1. Install `l10n_ke_edi_oscu_pos`.
2. Set company to a Kenya (KE) company.
3. Open POS → Clothes shop → add a product → go to Payment
→ try to Validate → traceback occurs.
**Issue:**
- A traceback is raised when validating a payment in the POS screen.
`undefined
TypeError: Cannot read properties of undefined (reading 'services')
at OrderPaymentValidation.beforePostPushOrderResolve`
**Cause:**
- ` this.env` and `this.orm` is not directly accessible in `OrderPaymentValidation`.
https://github.com/odoo/enterprise/blob/8ca771eb28a1fac13037c0d45e8d716d3dfc6ed2/l10n_ke_edi_oscu_pos/static/src/app/utils/order_payment_validation.js#L7-L24
**Solution:**
- Use `this.pos.env` instead of `this.env`, and `this.pos.data.call` instead of
`this.orm.call` to correctly access the environment and execute data calls
during payment validation.
> Reference:
https://github.com/odoo/enterprise/blob/5a794a6e69ba884862b4a3f399143d1392caa6f0/pos_barcodelookup/static/src/overrides/components/product_screen/product_screen.js#L8-L10
[Related Community PR](https://github.com/odoo/odoo/pull/230069)
**opw - 5137557**
Forward-Port-Of: odoo/enterprise#96284UrbanPiper POS orders now apply the correct taxes when the POS is configured under a company branch. This prevents missing tax amounts on order lines and improves accuracy for businesses operating with parent and child company structures.
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
The invoice payment button now points to the actual confirmed payment linked to the invoice, even when an earlier payment was reset to draft and duplicated. This helps accounting users avoid confusion and prevents them from being sent to an outdated payment record.
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#97003 Forward-Port-Of: odoo/enterprise#89089
SEPA payment files will now mark payments as high priority only for Belgian companies. This avoids unnecessary bank fees in other countries, such as Switzerland, while preserving the required behavior for Belgium.
Original PR description
Having priority set as HIGH for SEPA payments can induce extra fees (ex. in CH). This commit only sets the priority to HIGH for BE companies. task-4874217 Forward-Port-Of: odoo/enterprise#97006 Forward-Port-Of: odoo/enterprise#95420
Belgian payroll users can now generate Group S reports without encountering an error. The fix corrects the report date handling and adds test coverage for the full process from work entry creation to file export.
Original PR description
Generating a Group S report caused a traceback. Fixed by replacing 'date_start' with 'date' in the 'l10n.be.hr.payroll.export.group.s' model. Added a test to validate the change is working with the whole flow from creating a work entry till exporting the file. task-5005925 Forward-Port-Of: odoo/enterprise#95482
This update corrects access settings for Swiss payroll employee version fields so the right payroll users can view and use them. It prevents HR officers from running into access issues when opening employee records, helping payroll-related workflows and automated checks run reliably.
Original PR description
Some fields on the version were still with the hr_user group where they should be payroll_user. This was causing some tour to fail when an HR officer tries to access an employee. Build error: https://runbot.odoo.com/odoo/runbot.build.error/233204
Payroll salary rules can no longer have their salary structure changed once they are linked to employee-specific properties. This helps prevent accidental changes that could affect payroll calculations or employee compensation records.
Original PR description
As some other `hr.salary.rule` fields (like Section and Unit), Salary Structure is now readonly when the rule has a property on an employee. 5135927 [task-5135927](https://www.odoo.com/odoo/project/1251/tasks/5135927) Forward-Port-Of: odoo/enterprise#96938
This update corrects the Belgian payroll deduction rule known as deduction 3000 so it remains accurate through July 2025. It helps ensure payroll calculations follow the latest expected values, reducing the risk of incorrect employee pay or compliance issues.
Original PR description
Forward-Port-Of: odoo/enterprise#96951
Employee contracts in Swiss payroll now only allow selecting insurance records that belong to the employee's company. This prevents accidental use of another company's insurance settings in multi-company environments and helps keep payroll data accurate.
Original PR description
Currently, in a multi-company setup, you are able to select insurances from other companies on the employee contract task-5157106 Forward-Port-Of: odoo/enterprise#96932 Forward-Port-Of: odoo/enterprise#96821
This update adjusts an internal workaround used by Gantt chart unit tests so the test suite remains compatible with recent testing framework changes. It is limited to automated tests and does not change business functionality for end 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#97046 Forward-Port-Of: odoo/enterprise#96647
A typo was corrected so importing multiple images for a product variant no longer causes a crash. This improves reliability when generating or importing product content for online stores.
Original PR description
Fixed a typo that leads to a crash when importing multiple images for a product variant Forward-Port-Of: odoo/enterprise#96134
This fix updates an automated payroll pay run check so it no longer depends on a net payslip amount that can change from month to month. It helps keep payroll validation builds stable while still confirming wages are calculated and the net amount is present.
Original PR description
Instead of checking the net payslip amount which may vary from month to month, just check the basic wage and that the net amount is not 0. Build error: https://runbot.odoo.com/odoo/runbot.build.error/233213
Phone numbers in the VoIP call list now line up properly when no country flag is shown. This removes a small visual offset, making call records easier to scan and more consistent.
Original PR description
In the voip.call list view, when no flag is displayed, the phone number is slightly offset to the right. This is because the margin that separates the flag from the phone number is still present. This commit moves the margin from the phone number (always displayed) to the flag (sometimes absent). How to reproduce: 1. Make a call to an invalid phone number 2. Go to voip.call list view 3. Look at the numbers without a flag Forward-Port-Of: odoo/enterprise#96877
This change corrects how the Belgian reports partner form is linked so updates no longer fail when the citizen identification field is required. It helps ensure Belgian reporting modules can be upgraded smoothly without a server error blocking the process.
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#96855The Swiss payroll salary rule screen now includes all relevant configuration fields that were previously only available in the backend. This helps payroll teams review and adjust wage type settings more easily, reducing the risk of incomplete salary rule setup.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
This fixes an issue where documents selected for a draft chatter note were immediately linked to the underlying record before the note was posted. Attachments now stay with the draft composer until posting, preventing unintended files from appearing on leads, expenses, or other records after a page reload.
Original PR description
When adding attachment from documents in the composer, link the attachment to the composer and not to the thread as it must be linked to the thread only once the message is posted. How to reproduce: - Install the app documents and crm - Open a lead - In the chatter click on "Log a note" - Then click on "Add from Documents" - Select a document and click on "Add from Documents" - Reload the page without posting the message The attachment selected in document is now linked to the lead which shouldn't be the case. Note that if you do the same for an expense, as the attachment is linked to the expense right away when added, the preview panel open immediately, and you have to reopen "Log a note". That was the original bug detected. Task-5075835 Forward-Port-Of: odoo/enterprise#94594
CRM and subscription spreadsheet dashboards now calculate key totals correctly by using the right aggregation method. The CRM pipeline dashboard also focuses on the last 12 months and avoids applying irrelevant default filters when users open the underlying records.
Original PR description
See commit messages Forward-Port-Of: odoo/enterprise#96810
This update corrects how Swiss payroll records identify companies by using the country set on the related partner record. This prevents payroll processes from missing the right companies when the company country value cannot be searched directly.
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#97040 Forward-Port-Of: odoo/enterprise#95255
Fixed an issue where Belgian EC Sales List XML exports could omit the month or quarter when opened from the VAT Return page. This ensures exported tax files contain the complete reporting period expected for compliance and submission.
Original PR description
**Issue** When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a…
**Issue** When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected. **Steps to Reproduce** 1. Install the Accounting module and Belgium localization. 2. Go to the Accounting dashboard. 3. Open the VAT Return via the "Miscellaneous Operations" section. 4. Click the smart button to access the EC Sales List report. 5. Use the gear icon to export the XML. 6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing. **Root Cause** If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered. **Fix** Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period. Opw-4702613 Forward-Port-Of: odoo/enterprise#93647 Forward-Port-Of: odoo/enterprise#89290
Restores the broken action behind the “Some transactions may be duplicates” banner in online bank synchronization. Users can again navigate from the reconciliation screen to the tool for finding duplicate bank transactions, reducing confusion and manual follow-up.
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
This update adjusts an internal barcode inventory test so it matches the intended setup when demo data is present. It helps prevent false test failures and supports more reliable validation of inventory barcode workflows.
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. Forward-Port-Of: odoo/enterprise#97141
28 changes
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#9685517 changes
Resolved issues and error corrections
This fixes an issue where accounting users limited to a company branch could not select accounts from the parent company when creating journal entries. The change ensures branch-only users can access the appropriate parent-company accounts, reducing blocked accounting workflows.
Original PR description
**Steps to reproduce:** - Install accountant - Create a company branch for a company - Create a non-admin user with Accounting rights and access to the branch only - Connect with the created user - Go to "Accounting / Accounting / Journal Entries" - Create a journal entry and try to set an account on a line **Issue:** There is no account available. The accounts from the parent company should be selectable. **Cause:** The accounts are searched with a "parent_of" domain on "company_ids" field, which is a many2many field. However, as the user doesn't have access to the parent company, the parent company is excluded from the search when parsing the domain. opw-5096437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The attendance auto-checkout process now correctly handles employees who checked in on a previous date. This prevents open attendance records from staying unclosed when the automated job runs after delays such as server downtime.
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
Creating a website focused only on events will no longer automatically install ecommerce features. This keeps the website setup aligned with the user’s selected purpose and avoids adding unnecessary online store functionality.
Original PR description
Steps to reproduce: 1. Install website module 2. Select events in configurator 3. Build website. => Ecommerce is installed, which should not as it does not make sense with only the events. After this commit: - Ecommerce will no longer be installed when the events is configured. task-4922600 Forward-Port-Of: odoo/odoo#221527
Invoice SEPA QR codes now consistently include the payment reference used for reconciliation when one is available. This prevents the QR code from falling back to a less precise customer reference, helping payments match invoices more reliably.
Original PR description
Issue: - While generating SEPA QR for invoices, we intended to use the payment reference (structured communication) to ease reconciliation. - A strict format validator caused structured refs to be invalid, and the QR fell back to the customer reference (unstructured comment). Fix: - Removed the strict validation for structured communication. - If a payment reference exists, put it in the structured field and clear the unstructured comment. - Only use the unstructured comment when no payment reference is provided. Impact: - QR codes consistently carry the intended payment reference. Task [link](https://www.odoo.com/odoo/project.task/5122875) task-5122875
The Shop Floor Add Operator list now uses public employee information instead of private employee profiles. This prevents access warnings for users who are not allowed to view private employee details, keeping operator selection smoother without exposing restricted data.
Original PR description
The task 4762527 added a warning for users that were not allowed to access private employee profiles. The "Add Operator" button in mrp_workorder (Shop Floor) was relying on it. I had to change their list model from hr.employee to hr.employee.public This issues was raised by Aerospacelab in the following PR: https://github.com/odoo/odoo/pull/228623 task-5156702
Product imports that include custom Studio file fields can now correctly upload related files such as PDFs from XLSX imports. This prevents import errors and ensures attached documents are saved as expected when updating product records.
Original PR description
## Versions 18.0 > 18.3 Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6 ## Issue Importing products (with file fields) from XLSX file triggers an error or does not update when…
## Versions
18.0 > 18.3
Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6
## Issue
Importing products (with file fields) from XLSX file triggers an error or does not update when uploading related PDF files.
## Steps to reproduce
https://github.com/user-attachments/assets/7f4c1faf-de8c-4923-a50e-cce77071679d
*Requires Studio app*
- Go to any product's backend page and open Studio customization:
- Add a "File" field to the product page and link it to a "PDF Viewer" widget;
- Keep the field name ("New File");
- Save and close.
- Go to the products' list view in debug mode and select a product (e.g. Acoustic Bloc Screens) to export (via "Actions"):
- Check the "import-compatible" checkbox;
- Remove all fields to export;
- Look for "file" in available fields:
- Add the "New File (x_studio_binary_field_xxx_xxxxxxxxx)" field;
- Add its related "Filename for x_studio_binary_field_xxx_xxxxxxxxx (x_studio_binary_field_xxx_xxxxxxxxx_filename)".
- Export in XLSX format.
- In your computer's file explorer:
- Download or create a PDF file and copy its name;
- Open the XLSX file and paste the PDF filename in the 2 empty columns;
- Save and close the file.
- In the products' main view click "Import records" action button:
- Click "Upload Data File" and select the XLSX product file.
- Click "Upload your files" in the "Files to import" section on the left and select the PDF file.
- Click "Test" or "Import"
## Cause
This upload feature has been described in task 4077715. This specific lines seems to be based on another one a bit further in the code: https://github.com/odoo/odoo/blob/e42f5bee59daa0e270ae4803cc827009974da232/addons/base_import/models/base_import.py#L1289
## Fix
Allow all files base 64 conversion by removing a restriction on images only.
opw-4931579This update removes a test assertion that could produce inconsistent results when checking mobile call behavior. It does not change the user experience, but helps keep automated validation more reliable for the Discuss app.
Original PR description
Before this commit ([1]), we were testing the absence of a button for mobile, but the test can lead to undeterministic behavior as `isMobileOS` is not reactive as we do not expect a live transition of userAgent, like from desktop to mobile, so testing for this behavior is not useful. A dedicated test for call mobile was introduced in v19 ([2]) https://runbot.odoo.com/odoo/runbot.build.error/233350 [1]: https://github.com/odoo/odoo/pull/177374 [2]: https://github.com/odoo/odoo/pull/218119
The Privacy Lookup action now checks for invalid email addresses before searching, preventing an unexpected error screen. Users are shown a clearer validation message instead, making the lookup process more reliable when contact data contains mistakes.
Original PR description
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address. **Steps to reproduce:** - Install CRM modules. - Create a new contact with an invalid email…
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address.
**Steps to reproduce:**
- Install CRM modules.
- Create a new contact with an invalid email address (missing @ - e.g; `demo`).
- In the contact form, click the gear icon and select "**Privacy Lookup**".
- Click on "**Lookup**" button.
**Error:**
```
UndefinedFunction
operator does not exist: character varying = boolean
LINE 55: WHERE email_normalized = false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
**Cause:**
Here, Execution of the query fails because `email_normalized` is set to a Boolean value, which is being computed at [1]. And method `tools.email_normalize` returns `False` for invalid email inputs - [2].
**Fix:**
This commit raises an error if the email address is invalid before executing the query.
A similar case is already handled in the mail blacklisting module. ([Ref](https://github.com/odoo/odoo/blob/c7f86c3250c59130ae0b95c6847050d3a6fc7a6d/addons/mail/models/mail_blacklist.py#L29-L31)):
[1] - https://github.com/odoo/odoo/blob/e6c0e963c5379ba7ad8da00ba4ea6c2bb259d95c/addons/privacy_lookup/wizard/privacy_lookup_wizard.py#L49
[2] - https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/odoo/tools/mail.py#L734-L735
sentry-6881416673This fix ensures that adding a lunch product to the cart only increases the quantity of the pending "To order" line, not items that were already ordered. It prevents accidental changes to completed lunch orders and keeps cart totals accurate.
Original PR description
**Issue**
When a user has two instances of the same product in their lunch cart, one with state "To order" and one with state "Ordered", and places a new order for that product, both the "To order" and "Ordered" records have their quantity incremented. Only the "To order" record should be updated.
**Steps to Reproduce**
- Add two lunch orders for the same product: one with state "To order" and one with state "Ordered".
- Place a new order for the same product.
- Observe that both records ("To order" and "Ordered") have their quantity incremented.
**Root Cause and Changes Made**
The _find_matching_lines method does not restrict the search to orders with state "new" ("To order"). As a result, it returns all matching records for the product, regardless of their state. When update_quantity is called, it updates the quantity for all these records.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a website layout issue where pages kept extra left spacing after a sidebar-style header was hidden. Business users and editors will see page content align correctly when the header is turned off, improving the visual consistency of edited websites.
Original PR description
Steps to reproduce the issue: - In edit mode, change the header template to use the "Sidebar" header (=> since it is a sidebar, the page content is shifted to the right) - Go to the theme tab and toggle the "Show Header" option so the header is removed => Bug: the page content is still shifted as if the sidebar were still present. This happens because the page still has padding-left for the header, although there's no header. task-5131064
Close buttons in pop-ups, side panels, and notifications now automatically use colors from the website's selected palette. This keeps these interface elements visually consistent with each website theme and improves readability across customized 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
Fiscal positions will no longer replace an active tax with an inactive one when preparing invoice lines. This prevents invoices from accidentally using taxes that have been disabled, improving tax accuracy and reducing manual corrections.
Original PR description
With this commit we exclude inactive taxes from the tax mapping of fiscal positions. Steps: - Create a fiscal position FP that maps an active tax to an inactive one - Create an invoice, set FP and create add an invoice line with a product having the active tax -> The tax mapping is applied and the inactive tax is set, it shoudln't opw-5117775
This fix prevents empty duplicate eCommerce mega menu options from appearing in the website editor when no product categories exist. It avoids confusion for editors and prevents an error when selecting those unusable menu options.
Original PR description
When `website_sale` is installed but there are no eCommerce categories, all mega menu options will be shown twice in the web editor. When you use the duplicated one it's empty and you'll also get an error.
This fixes the internal value used when neutralizing Nemhandel users. It helps ensure the right electronic invoicing proxy users are handled during data neutralization, avoiding mismatches caused by an outdated or incorrect identifier.
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
Changing text color in the HTML editor now affects only the selected content, even when an icon is nearby. This prevents unintended color changes to larger surrounding sections and keeps page formatting more predictable.
Original PR description
After this [commit], we'd have an issue when we tried to change a color and there was an `fa` icon next to our selection. Instead of changing the color of only the selection it would change it for the closest element with `color`, `background-color`, or `background-image` style properties. To reproduce the bug: - Set selection on an element that has a color style property on its parent, and the parent has .fa icon but not directly on our element - Try to change its color => Color of the whole parent changes task-5107147 [commit]: https://github.com/odoo/odoo/commit/927f4b973932d14961c148e13473017651a60dc0
Images in website card snippets now correctly follow the same rounded corners as the card itself. This improves visual consistency and prevents card images from appearing misaligned or unfinished.
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
Corrects Spanish e-invoice XML generation so product prices with extra decimal precision and globally rounded taxes match the actual invoice values. This helps avoid rounding discrepancies, rejected electronic invoices, and incorrect totals in submitted Facturae documents.
Original PR description
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded…
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere. 2. When the tax rounding was set to round_globally, the TotalTaxOutput in the XML might differ from the actual tax_amount from the invoice because of rounding errors occurring during uncessary re-computation while building the XML. While stable is not the place to change all functions related, we can isolate computed tax output and tax withheld values and transmit them without any intermediary. As this file was changed in 18.0 another PR was needed from 17.0: https://github.com/odoo/odoo/pull/209623 (unit price decimals) and https://github.com/odoo/odoo/pull/229017 (tax rounding issue, detected after 209623 was closed) task-4650439
1 change
Resolved issues and error corrections
This fixes an issue where some draft Point of Sale orders stayed saved on the server even after users deleted them. The change helps prevent blocked POS session closures caused by undeletable draft orders.
Original PR description
In certain conditions some draft orders could be saved on the server but you wouldn't be able to delete them. This prevented you to close the PoS. Steps to reproduce: ------------------- * Use a PoS…
In certain conditions some draft orders could be saved on the server but you wouldn't be able to delete them. This prevented you to close the PoS. Steps to reproduce: ------------------- * Use a PoS that is NOT a restaurant * Make sure the PoS has a preparation display * Open the PoS * Leave the first order empty and create a new one * In the second order add any items * Go back to the first order, add items and validate it * Delete the second order from the order list * Now try to close the session > Observation: You will get an error saying you still have draft order Why the fix: ------------ When you have a preparation display linked to the PoS, when you pay an order it will synchronize all the order of the PoS. So the draft order will be saved on the server. But when deleting it, it is not deleted from the server because the function `isOpenOrderShareable` would return false. To fix this we make sure to delete the order from the server if the order has a server_id. opw-4946204