Daily updates from Odoo
Navigate
Branch
Tuesday, October 14, 2025
254 changes
18 changes
Enhancements to existing features
The Peru localization now includes the required withholding tax and tax group by default. This helps identify customers who are withholding agents and supports upcoming invoice XML compliance updates.
Original PR description
Withholding taxes are required to indentify if a customer is a withholding agent. This PR introduces the tax and tax group for the enterprise PR that will generate the changes for the Invoice XML. task-4989463
Peruvian invoices can now include the required withholding reference when the customer is a withholding agent. This helps companies meet local electronic invoicing requirements for these customers while keeping the withholding amounts out of invoice totals as required.
Original PR description
Some customers in Peru are considered "agentes de retención", and as such have special considerations that are necessary. We must perform specific actions when working with these customers, when selling to them we must: - recieve a specific document from the customer (A followup task will add this support for companies to generate this document) - Include a retention reference in our XML. This is represented as a specific `AllowanceCharge` node that is the sum of all of the Withholding taxes on the lines with the specific code of 62. We know an invoice is to a withholding customer because all lines must have a tax that is a part of the withholding tax group. This withholding tax is not included in the monetarytotals, tax totals, or invoice line values. And there can be only one AllowanceCharge node per invoice, not one per line. task-4989463
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
36 changes
New functionality added to Odoo
A new Romanian Intrastat module adds support for tax return periods used in Intrastat tax reporting. This helps Romanian companies prepare the required Intrastat declarations in Odoo using the newer tax return framework.
Original PR description
Tax return feature was introduced in 18.3, and as a part of that, tax return period for different localisation needs to be introduced. This PR introduces a new module that adds support for tax return periods in Romanian Intrastat Tax Reporting. task-4987885 Forward-Port-Of: odoo/enterprise#93202
A new Databases application lets users oversee multiple Odoo databases from one place. It treats each database like a project, making it easier to track related work, timesheets, and key business indicators such as pending documents, draft entries, and tax returns.
Original PR description
The new Databases application allows you to manage a list of other Odoo databases from a single interface. Each database is treated as a Project, enabling features such as task and timesheet management within this context. The list view displays a variety of KPIs retrieved from each database - for example, the number of documents in the Inbox folder, the number of draft journal entries, or the tax returns that need to be submitted. Task-id: 5062431 Forward-Port-Of: odoo/enterprise#94207
The Point of Sale delivery integration now supports Keeta as an additional food delivery provider through UrbanPiper. This gives businesses more delivery channel options from within their existing POS workflow.
Original PR description
In this commit : - Integrated Keeta as a new food delivery provider in `pos_urban_piper`. Task - 5128817 Forward-Port-Of: odoo/enterprise#96599
Enhancements to existing features
Users can now decide whether nil-rated tax entries in India GSTR-1 reporting are included with invoice or credit note categories, or in the nil-rated section. This prevents the same entries from appearing in multiple summary tables and gives businesses more control over statutory report presentation.
Original PR description
**Current behavior in gstr1 report:** For invoices and credit notes, if there are nil rated tax grid journal items then these tax lines are considered in both GSTR summary tables, i.e self category (b2b/b2c) table and nil category table. With this PR, the journal items are considered for their respective GSTR summary tables only, and also adds an option for users to choose whether nil rated tax grid journal items should go to b2b/b2cs (if invoice) or cdnr/cdnur (if reverse) or nil rated. **task**-3873970
The attendance overtime rule form now prevents users from editing the rate when the Work Entry module is installed. This keeps overtime configuration consistent with payroll work entry rules and reduces the chance of accidental changes.
Original PR description
If Work Entry module is installed --> Make the rate readonly within the form view of the attendance overtime rule. Task-5107738 Forward-Port-Of: odoo/enterprise#95352
Point of Sale payment terminals now use the same IoT communication service as other IoT Box actions. This enables more connection methods, such as WebRTC and WebSocket, which can make terminal communication more flexible and reliable.
Original PR description
As for any other actions sent from the db to the IoT Box, we updated payments terminals logic to use the `iot_http` service in order to allow them using webrtc and websocket in addition to longpolling. odoo/odoo#230970 Forward-Port-Of: odoo/enterprise#96634
The AI live chat has been updated to use the same conversation structure as Odoo Discuss channels. This should make chat handling more consistent and easier to maintain, with minimal visible change for end users.
The update prevents users from saving negative values in wage-related fields such as signature wages and hourly wages. This helps keep employee contract and payroll data accurate across standard and country-specific payroll configurations.
Original PR description
task-5129791 See odoo/odoo#229638 See odoo/upgrade#8536
Report warnings in accounting and Intrastat reports now use a unified actionable error display, making issues easier to understand and resolve. This reduces duplicate warning screens and improves consistency when users need to fix export or reporting problems.
Original PR description
Removing the `warnings` block in `account_report`, porting everything to the new `actionable_errors` widget. Related PR: odoo/enterprise#59363
The spreadsheet selector grid now automatically receives focus when opened, so users can start interacting with it right away. This reduces an extra click and makes spreadsheet editing feel smoother and faster.
Original PR description
Task: 5106371 Forward-Port-Of: odoo/enterprise#95254
The quality team overview now excludes checks tied to manufacturing operations, so the count focuses only on regular pending quality checks. This helps users see the items they can act on directly and avoids confusion with manufacturing steps handled elsewhere.
Original PR description
*: quality_{control, mrp_workorder}
This commit updates the `_compute_check_count` method to exclude
quality checks linked to manufacturing operations from the count
shown on the quality team overview.
Additionally, the filter used when clicking on the count has been
updated to display only normal (non-manufacturing) quality checks
that are still pending.
This change ensures users see only relevant, actionable quality checks
in the overview and avoids confusion caused by including manufacturing
related steps, which are handled separately in the manufacturing process.
TaskId :- 4949551This update adds shared automated checks for localized point-of-sale flows across several countries. It helps reduce the risk of country-specific compliance or invoicing issues reaching customers by making these scenarios easier to test consistently.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788 Forward-Port-Of: odoo/enterprise#96447 Forward-Port-Of: odoo/enterprise#91928
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
25 changes
New functionality added to Odoo
A new Databases app lets users monitor and manage multiple Odoo databases from one place. Each database can be handled like a project, with business KPIs such as pending inbox documents, draft journal entries, and tax returns visible in a shared overview.
Original PR description
The new Databases application allows you to manage a list of other Odoo databases from a single interface. Each database is treated as a Project, enabling features such as task and timesheet management within this context. The list view displays a variety of KPIs retrieved from each database - for example, the number of documents in the Inbox folder, the number of draft journal entries, or the tax returns that need to be submitted. Task-id: 5062431
Enhancements to existing features
Website editors setting up AI live chat can now more easily choose existing internal pages when adding links. This improves usability by showing relevant page suggestions instead of requiring manual URL entry.
Original PR description
Before this commit, the website URL picker used `autocompleteWithPages` to suggest internal links. This commit removes the WebsiteUrlPicker and patches the BuilderUrlPicker to use the autocomplete component, enabling internal link suggestions for existing pages.
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
Code cleanup and technical improvements
A reusable checkbox display component has been moved into the core web area so more Odoo apps can use it without extra dependencies. It also gains an option to show checkboxes in a vertical list, improving flexibility for future screens such as database-related features.
Original PR description
### [REF] account,web: move widget json_checkboxes to web The `json_checkboxes` widget could be used in other modules than `account` and its descendants. With this commit, we move it to `analytic`, which is shared by a lot more modules, which will make it available to them. In particular, we will use it in the new enterprise `databases` module. We keep the name account_json_checkboxes for the stable backward compatibility. Task-id: 5062431 ### [IMP] web: add stacked mode to widget json_checkboxes With this commit, the json_checkboxes widget, which displays inlined checkboxes by default, now has a `stacked` option that allows displaying the checkboxes in a column. Task-id: 5062431
6 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-49315791 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