Friday, March 20, 2026
24 changes · saas-19.2
New functionality added to Odoo
This update reflects recent changes in Belgian tax regulations regarding deductible expenses. The update modifies key accounting data (accounts 616580, 616541, 623610) to ensure compliance with the latest government rules. This ensures accurate financial reporting for businesses operating in Belgium.
Original PR description
Belgian Government changed some rules regarding the fiscal deductibility of some expenses, so we need to update that data accordingly for accounts 616580, 616541, 623610 Task-5973880 Forward-Port-Of: odoo/enterprise#110075
This update adds a new tax specifically for income related to work incapacity, aligning Odoo with Spanish tax regulations (AEAT Model 190). It ensures accurate reporting of withholdings for this income type, preventing errors and improving tax compliance for Spanish businesses.
Original PR description
### Description of the feature this PR addresses: **Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.** A new tax called…
### Description of the feature this PR addresses: **Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.** A new tax called "**100% WHI monies**" has been created with the aim of correctly reflecting the income derived from incapacity for work in the AEAT's Model 190. ### Current behavior before PR: Currently, Odoo does not allow automatic differentiation between monetary payments derived from work incapacity and those not derived from it. This creates a problem when generating Model 190, as the Spanish Tax Agency (AEAT) requires both types of payments to be reported separately (according to the codes and subcodes established in the model). **In practice, this separation is necessary because:** - Income derived from incapacity for work (e.g., sick leave) is considered employment income with differentiated tax treatment. - Withholdings made on these amounts must be declared in specific sections of Form 190. - If they are not separated correctly, the totals on the form may be incorrect or incomplete, affecting the accuracy of the tax information submitted. ### Desired behavior after PR is merged: A new tax has been added to represent “100% Withholding income tax (workers)”, allowing Odoo to: - Correctly identify and calculate the related amounts. - Report them separately in the AEAT Model 190. - A new tax group has also been created to distinguish these withholdings from regular ones. ### Benefits: - It allows you to correctly generate Form 190, separating income derived from and not derived from work disability. - It facilitates the accounting and tax traceability of this type of income. - It ensures consistency with the information structure required by the Spanish Tax Agency (AEAT), avoiding errors in the annual filing. - It improves the flexibility of the Odoo tax system, adapting it to actual tax needs. ### Technical summary: - A **new specific tax** has been created for withholdings associated with incapacity for work benefits. - This tax **allows the amounts corresponding to these benefits to be identified, accounted for, and reported independently.** - In addition, a **new tax group "Whitholdings IRPF Workers" has been added that groups these withholdings together**, allowing them to be clearly distinguished from other withholdings on earned income. The related issue: https://github.com/OCA/l10n-spain/issues/4416 ### Follow-up suggestion: adjust Odoo’s base tax “15% WHI monies” **Proposal:** Change the base tax “15% WHI monies” to 100% and move it to the new “Whitholdings IRPF Workers” tax group. **Why:** The current 15% rate is not aligned with how AEAT Model 190 requires amounts to be computed: the base should reflect 100% of the earnings derived from temporary incapacity, with the withholding rate applied on top of that base. Keeping 15% leads to misclassification and wrong totals in the "_percepciones_" and "_retenciones_" sections. These are variable withholdings, not fixed taxes — each worker’s rate can change monthly depending on their income and number of days worked. Therefore, having a fixed 15% rate is conceptually incorrect and causes misclassified amounts and inaccurate totals, forcing users to adjust values manually after payroll. Ideally, this tax should not have any fixed percentage defined. Since Odoo currently requires a rate, setting the base to 100% is a pragmatic workaround that ensures more accurate and flexible withholding calculations. **Outcome:** - Correct calculation and reporting of **_percepciones derivadas de incapacidad laboral_**. - Clean separation from other withholdings via the new tax group. - Consistency between accounting, payroll, and the 190 export. Would you accept this change? @moduon @rafaelbn @EmilioPascual @chklop @jco-odoo MT-11667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245553 Forward-Port-Of: odoo/odoo#232515
Resolved issues and error corrections
This update resolves an issue preventing new employee creation when generating BVG-LLP reports with duplicate monthly data. The fix addresses a technical problem related to how Odoo processes recordsets, ensuring accurate employee creation in Swiss companies using the LPP reporting functionality.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335This update resolves an issue preventing power buttons from appearing in Odoo Studio report editors. The fix ensures the necessary configuration for local overlay containers is correctly defined within the Studio wysiwyg instance, improving report customization capabilities. This ensures reports render correctly and consistently.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#110273 Forward-Port-Of: odoo/enterprise#109012
This update resolves a performance issue in the Followup Report, which was significantly slower in version 19.1. By reverting to a simpler filtering method, the report now opens much faster, preventing potential cron job timeouts on large databases. This improves the overall efficiency of the reporting process.
Original PR description
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1…
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1 than it used to in 19.0. This is a problem when processing the followup with the cron, as it can cause it to time out. This situation happens because we now use a subquery computing the partner from the account.partial.reconcile objects linked the the move lines (because the Partner Ledger needs to consider move lines made without any partner as well). in 19.0, a domain on the partner_id field was directly executed, taking hence advantage of the index existing for that field. While this makes sense for the Partner Ledger, it's not relevant for the Followup Report. Indeed, in that report, when filtering on a single partner, we only want to show the open invoices and unreconciled payments made for that partner, so we'll never need to consider the lines without partner. We can therefore use the standard domain on partner_id in that case, like before, solving the perf issue in the meantime. Forward-Port-Of: odoo/enterprise#110966
This update resolves a validation error occurring when invoices for 'Final Consumers' without VAT/CUIT numbers are submitted to ARCA. The system now correctly handles these transactions by classifying them as 'sigd', sending a null DocNro, and ensuring successful validation, avoiding blocked invoices.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers"…
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service. **Current behavior before PR:** When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice. **Desired behavior after PR is merged:** For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error. Forward-Port-Of: odoo/enterprise#106881
This update fixes an issue in the Spanish balance sheet reports where prior period earnings weren't accurately reflected, potentially leading to incorrect equity totals. The change ensures that all retained and unaffected earnings are included, maintaining consistent and reliable equity reporting.
Original PR description
Description of the issue this commit addresses: The ES balance sheet “prior periods” line only matched code 12, so retained/unaffected earnings posted on other codes were skipped, which could understate or skew equity totals. --- Desired behavior after this commit is merged: The line now includes both accounts with code 12% and accounts of type equity_unaffected, so carried-forward results are always included and equity totals stay consistent. --- task-6047627 Forward-Port-Of: odoo/enterprise#111249
This update resolves an error that occurred when creating payments for invoices using the Bacs Direct Debit method. The issue stemmed from a system check requiring a bank account, which wasn't present in certain scenarios. This fix ensures the system correctly flags missing bank account information, preventing payment failures.
Original PR description
Currently, an error occurs when user creates a payment for an invoice. **Steps to Reproduce:** - Install `l10n_uk_bacs` with demo data. - Switch to the `UK company`. - Go to `Journals`, select the…
Currently, an error occurs when user creates a payment for an invoice. **Steps to Reproduce:** - Install `l10n_uk_bacs` with demo data. - Switch to the `UK company`. - Go to `Journals`, select the `Bank Journal`, and remove the `Bank Account Number`. - Go to `Invoices` and create an invoice by adding an `invoice line` with price greater than zero. - `Confirm` the invoice. - Click `Pay`, select `Bacs Direct Debit` as the payment method, and click `Create Payment`. `ValueError: Expected singleton: res.partner.bank()` This error occurs when creating a payment for an invoice using the Bacs Direct Debit payment method. The constraint check bacs bank account trigger [1], but since the journal has no bank account number, it raises an error here [2]. Similar error also occurs when validating a batch payment [3]. This commit ensures that if the journal has no bank account, or if the bank account is invalid, the system raises the same validation error. In batch mode, it raises a UserError when the account is missing. [1]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_payment.py#L52-L58 [2]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/res_partner_bank.py#L18-L19 [3]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_batch_payment.py#L74 sentry-7259107152 Forward-Port-Of: odoo/enterprise#107235
This update resolves an issue where the bulk payments feature would crash if a bank account wasn't linked. The fix adds a user-friendly warning message to alert users that the journal needs to be connected to a bank before checking the status of a payment batch. This improves the user experience and prevents unexpected errors.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#111031 Forward-Port-Of: odoo/enterprise#109956
This update resolves an error that prevented users from filtering products by date on the rental shop page. The fix corrects a data structure change within the Odoo system, ensuring accurate date-based searches are now possible. This improves the user experience for browsing and selecting rental products.
Original PR description
Currently, an error occurs when searching by date on the shop page. **Steps to Reproduce:** - Install the `website_sale_renting_planning` module. - Go to `Products` and create a product with the…
Currently, an error occurs when searching by date on the shop page. **Steps to Reproduce:** - Install the `website_sale_renting_planning` module. - Go to `Products` and create a product with the following configuration: - `Type`: `Service` - Under the `Sales` tab, set the `Periodicity` value. - Go to `Planning` > `Configuration` > `Roles` and switch to `Kanban` view. - Create a record by adding a `Resource` and the `service` product. - Enable `Sync Shifts and Rental Orders` in this role. - Go to `Website` > `Shop`. - Click `Edit` > `Style` > enable `Rental` by selecting it in the `toolbar`, then `save`. - Set the `start date` and `end date` and `apply` the filter. **Error1:** `ValueError: Invalid field 'resource_id' on model 'planning.slot' for 'resource_id:recordset'.` **Error2:** ` File "/home/odoo/odoo18/community/addons/resource/models/resource_calendar.py", line 455, in _leave_intervals_batch for _, resources in resources_per_tz.items():` `AttributeError: 'resource.resource' object has no attribute 'items'` This error occurs because after this [recent commit], the field `resource_id` was replaced by `resource_ids` with a M2M relation. When the user searches by date, the system attempts to group planning slots by `resource_id`, which raises the error[1]. After this [new commit], _leave_intervals_batch expects resources grouped by timezone, but here only resources are passed [2], which raises the error [3]. This commit ensures that `search_fetch` is used to retrieve `resource_ids`, since `read_group` cannot group records by M2M fields. It also ensures that resources with their timezone are correctly passed to _leave_intervals_batch. [recent commit]: https://github.com/odoo/enterprise/commit/fbf8b2ac67c71ca0abfc75df543069696bd2d29b [new commit]: https://github.com/odoo/odoo/commit/2dff65ab8b5a9db21d5b476065a72755cc4625be#diff-11ecbc9f00711187e60b88f84c618046bb24ada8c39cb29037568c1aa46f06a5 [1]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L30 [2]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L50 [3]: https://github.com/odoo/odoo/blob/9e41753a14c7398927445d8dc8f69dc57047b0b6/addons/resource/models/resource_calendar.py#L453 sentry-7325252044
This update resolves an issue where default values weren't consistently applied when creating VoIP calls. The change reverts to using raw SQL queries to trigger Odoo's retry mechanism for unique constraint violations, ensuring calls are created correctly and reliably. This maintains the previous behavior while leveraging Odoo's built-in error handling.
Original PR description
Since 2d406b71cf17d91baa30070899515f22f5ec3222, voip.call records are created using a raw SQL query rather than the ORM. This has the side effect of not applying the default values. The main reason it was done with a raw SQL query was to be able to leverage Odoo default retry mechanism on unique constraint violation, since `UniqueViolation` exception doesn't normally trigger a retry. This commit reverts the approach to using the ORM, and raises a `ConcurrencyError` on `UniqueViolation`. The `ConcurrencyError` triggers the retry mechanism, allowing for the same behavior as the raw SQL query, while keeping the ORM features (e.g. default values). [Task-6036473](https://www.odoo.com/odoo/project/5778/tasks/6036473)
This update fixes an issue where the Field Service onboarding tour would stop prematurely after redirects. By adding tour information to the user's session, the tour now correctly resumes and persists across the portal, providing a smoother and more complete onboarding experience for users.
Original PR description
**Steps to reproduce:**
1. Go to Field Service app.
2. Check the worksheet template in settings and start the onboarding tour
of Field Service.
**Issue:**
The backend tour is not resuming on the frontend side.
**Fix:**
This commit ensures the tour is enabled and the current tour is added to the frontend session. When the tour resumes, it will fetch the tour enabled and current tour details from the session.
**Technical:**
In the tour service, the tour resumes only if the mode is set to "auto" or toursEnabled is present in the session. To handle this, we added the tour details to the session.
tour_service.js
``` js
if (tourState.getCurrentConfig().mode === "auto" || toursEnabled) {
resumeTour();
}
````
task-4489657
Forward-Port-Of: odoo/odoo#254600
Forward-Port-Of: odoo/odoo#202484This update fixes an issue where payslips were incorrectly archiving versions when employee data was updated. Now, payslips will only display unarchived versions, ensuring accurate and reliable payroll reporting. This prevents data inconsistencies and simplifies payroll management.
Original PR description
In this commit, the versions on payslips are restricted to only unarchived ones. This ensures that when changing dates/employee, the version selected is never archived. Task-6022151 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253348
This update resolves an issue where users with Manufacturing and Timesheet permissions couldn't complete Manufacturing Orders due to access restrictions on linked analytic lines. The change allows users to correctly link analytic lines to work orders, ensuring smooth order completion without requiring administrative privileges. This improves usability for a wider range of users.
Original PR description
Issue before this commit: ========================= Clicking Produce All on a Manufacturing Order as a user with Manufacturing and Timesheet rights raised an AccessError. During Manufacturing Order…
Issue before this commit: ========================= Clicking Produce All on a Manufacturing Order as a user with Manufacturing and Timesheet rights raised an AccessError. During Manufacturing Order completion, Odoo creates analytic lines for work center cost distribution and links them to the work order through the wc_analytic_account_line_ids Many2many field. With the stricter ORM security checks, linking records in a Many2many field requires read access to those records. Since analytic lines are created using sudo() but the relation update runs under the current user's permissions, the operation fails due to timesheet-related record rules. Steps to Reproduce: ========================= 1. Install mrp_account and hr_timesheet modules. 2. Create a Work Center with an analytic distribution. 3. Create a Product with a Bill of Materials (BoM) that includes a work order using the created Work Center. 4. Log in as a non-admin user with Manufacturing and Timesheet permissions. 5. Create and confirm a Manufacturing Order for that product. 6. Click Produce All. Cause of the Issue: ========================= Analytic lines are created with sudo(), but when linking them to the work order through the Many2many field wc_analytic_account_line_ids, the ORM checks whether the current user has read access to those records. Due to timesheet record rules restricting access to analytic lines, the linking operation raises an AccessError. With This Commit: ========================= This commit allows users to complete Manufacturing Orders without encountering access errors when analytic lines are linked to work orders, while preserving the existing analytic distribution and security logic. For Reference: [Security checks on Many2many](https://github.com/odoo/odoo/pull/217277/changes#diff-720a85988e5f3afc3b2596b9521964ef4a99e03e5b1ea8bea2e8ee476187526aR1467) Steps To Reporduce: [Video Link](https://drive.google.com/file/d/1HsZjpFSsnsYxZ4xwM8CBDeLhlcIHIP5t/view) opw-5971807 Forward-Port-Of: odoo/odoo#253496
This update optimizes how Odoo tests handle assets, speeding up processing and reducing memory usage. By caching assets across test suites and cleaning up temporary files, this change improves the reliability and efficiency of our testing process.
Original PR description
Preparation work for an upcoming [emoji loader](https://github.com/odoo/odoo/pull/253078) feature that will ease and centralize the loading and management of emoji data. This PR focuses on making assets caches work accross test suites, and to speed up the processing of some utils to increase performance or to reduce memory consumption. See commit messages for details. - Enterprise: https://github.com/odoo/enterprise/pull/110330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the POS Restaurant dashboard's pivot tables were not displaying the full dataset (15 rows) and failing to sort 'Top' values correctly. The changes ensure all rows are used, pivots are properly sorted, and column names accurately reflect the data, resulting in a more reliable and insightful dashboard.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - In the POS Restaurant dashboard, most pivot tables have 15 available rows, but only the first 10 rows are used. - Pivots meant to display 'Top' values were not properly sorted. - Some column names did not correctly represent the values they contain. Desired behavior after PR is merged: - Pivot tables now use all 15 available rows. - Pivots are sorted when required by the relevant columns. - Column names now correctly represent the values they contain. Task: [6019270](https://www.odoo.com/odoo/project/2328/tasks/6019270) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253256
This update fixes an issue where sales order margins were incorrectly calculated due to a misunderstanding of the company context. The fix ensures margins are accurately determined based on the company associated with the specific sales order line, regardless of the user's default company setting. This improves the reliability of margin reporting.
Original PR description
Steps to reproduce: - Have 2 companies: - Company A with a property_cost_method 'average' - Company B with a property_cost_method 'standard' - Create a sales order in B - Set the default company of the user to A. - Under certain scenarios, when we confirm the sales order, there will be a `flush_all`. - When that's the case, margins are recomputed with `line.product_id.categ_id.property_cost_method` as `average` instead of `standard`. In other words, it will take the property_cost_method from the `user.company_id` (A), instead of the property_cost_method from the `line.company_id` (B). This fix ensures the `property_cost_method` considered is the one related to the company of the sale order line. A similar issue was fixed on https://github.com/odoo/odoo/pull/192890 OPW-5939464 Forward-Port-Of: odoo/odoo#254489 Forward-Port-Of: odoo/odoo#252161
This update fixes an issue where overpayments made via bank payment in Point of Sale didn't create the necessary accounting records. Now, when a customer pays more than the order total with a bank payment, the system correctly generates a corresponding accounting line, ensuring accurate financial reporting. This prevents the system from incorrectly showing an outstanding balance.
Original PR description
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the…
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the order amount with bank pm * Validate * Close register * Check customer > Observation: It says we owe the customer money, although change was given. Why the fix: ------------ Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it. Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted. opw-5149700 Forward-Port-Of: odoo/odoo#254125 Forward-Port-Of: odoo/odoo#247621
This update prevents users from deleting tax groups that are currently in use, ensuring data integrity. Previously, deleting a tax group could lead to errors. Now, a validation error is displayed, safeguarding against potential data inconsistencies and improving the reliability of tax calculations.
Original PR description
Before this PR: - Group of taxes can be deleted by a user, even if they are used. After this PR: - If a user tries to delete a group of taxes in use, a validation error is raised. - Fixed a test case in POS and deactivated the tax instead of deleting the tax. Related PR: https://github.com/odoo/enterprise/pull/105174 task-5472834 Forward-Port-Of: odoo/odoo#254730 Forward-Port-Of: odoo/odoo#245243
This update fixes an issue where the table editor’s menus would overflow or not appear correctly when hovering over list items within table cells. The changes now ensure menus are displayed properly and prevent layout problems, enhancing the user experience when working with complex tables. This resolves a previous bug related to table menu positioning and visibility.
Original PR description
**Current behavior before PR:** - Table menu handlers could overflow into adjacent table areas when the targeted part of the table was only partially visible within the container. - When a table cell contained a list, hovering over the list element did not display the table UI menus, even though the mouse was inside the cell. **Desired behavior after PR is merged:** - Use a local overlay for the table menu to prevent overflow into adjacent cells. - Table UI menus are now correctly displayed when hovering over list elements inside a table cell. task-5353518 Forward-Port-Of: odoo/odoo#253278 Forward-Port-Of: odoo/odoo#240342
This update resolves an issue where the ProductScreen wasn't correctly displaying the current order when navigating from the ReceiptScreen. The fix ensures the correct order UUID is passed during navigation, preventing stale order data and improving the user experience. This ensures accurate order information is shown to the customer.
Original PR description
When navigating via `showDefault` from the ReceiptScreen to the ProductScreen, the route and URL update correctly but `selectedOrderUuid` remains pointing to the previous (receipt) order. Since ProductScreen resolves `currentOrder` through `pos.getOrder()` (which relies on `selectedOrderUuid`), it ends up displaying the stale order instead of the one specified in the route params. Update `selectedOrderUuid` from `routeParams.orderUuid` at the start of `navigate()` so that `getOrder()` and `setScreenData` both operate on the correct order. opw-6014753 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254622 Forward-Port-Of: odoo/odoo#253361
This pull request focuses on significant performance improvements within the HR module, specifically addressing slow data queries and inefficient processes. By optimizing searches, caching, and data retrieval, the changes reduce response times and enhance the overall stability of the employee management system. These improvements directly impact user experience and system efficiency.
Original PR description
task-6044049 Forward-Port-Of: odoo/odoo#254343
This update resolves an issue where e-invoices created from uploaded XML files (specifically PEPPOL BIS 4a invoices) were failing to correctly populate customer partner information. The fix adds a fallback mechanism to handle older invoice formats, ensuring accurate partner details are recorded for all invoices.
Original PR description
Currently, invoices created by uploading an e-invoice xml may not have the partner correctly filled in. Steps to reproduce: - Upload a customer invoice XML in format PEPPOL BIS 4a Issue: Partner is not set on the newly created record. On the chatter can be observed the message "Could not retrieve partner with details: Name: None, Vat: None, Phone: None, Email: None" Analysis: After https://github.com/odoo/odoo/commit/b4da4a77da3e0dc18707b935786b1924ca473796 we look for partner information under AccountingSupplierParty/Contact However older format may still be used to encode partner info under AccountingSupplierParty/Party opw-5970610 Forward-Port-Of: odoo/odoo#251808
This pull request updates the core spreadsheet component (o_spreadsheet) with several improvements and bug fixes. It includes enhancements to chart display, formula handling, and usability within the dark mode interface. These changes improve the overall spreadsheet experience and address reported issues.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0f517524fc [REL] 19.2.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0f517524fc [REL] 19.2.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6b16739895 [FIX] Formulas: fix missing debugger char in formula reconstruction [Task: 6019586](https://www.odoo.com/odoo/2328/tasks/6019586) https://github.com/odoo/o-spreadsheet/commit/8142c5d519 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382) https://github.com/odoo/o-spreadsheet/commit/c41164cb65 [FIX] Chart: Update geojson data [Task: 5224009](https://www.odoo.com/odoo/2328/tasks/5224009) https://github.com/odoo/o-spreadsheet/commit/217d38f026 [FIX] filters: allow criterion filter in dashboard [Task: 6017734](https://www.odoo.com/odoo/2328/tasks/6017734) https://github.com/odoo/o-spreadsheet/commit/646db21bc3 [FIX] charts: hierarchical charts should show formatted labels instead of raw [Task: 5913296](https://www.odoo.com/odoo/2328/tasks/5913296) https://github.com/odoo/o-spreadsheet/commit/ca666fcacc [FIX] composer: composer hover in dark mode [Task: 5928811](https://www.odoo.com/odoo/2328/tasks/5928811) https://github.com/odoo/o-spreadsheet/commit/458b3ecf97 [REV] composer: use opacity rather than color alpha [Task: 5928811](https://www.odoo.com/odoo/2328/tasks/5928811) https://github.com/odoo/o-spreadsheet/commit/51e20f8f81 [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522) https://github.com/odoo/o-spreadsheet/commit/dad958426b [FIX] standalone_composer: wrong composer content on start edition [Task: 6022743](https://www.odoo.com/odoo/2328/tasks/6022743) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>