Daily updates from Odoo
Friday, March 20, 2026
39 changes · saas-19.2
Resolved issues and error corrections
This update resolves a technical issue within Odoo's Studio where view editing sometimes caused errors. The fix ensures that Studio correctly handles inherited views, preventing crashes and improving the stability of the view creation process. This change enhances the reliability of the Studio tool for users.
Original PR description
This commit is a followup to odoo/enterprise#94747 which was made incomplete by odoo/enterprise@52f27c4. Sometimes actions set one of their view to an inherited view rather than the primary. This created traceback because the to-be-created studio arch was normalized against the inheritance tree without the given inherited view, which is wrong. After this commit, there is no crash. opw-5955734 Forward-Port-Of: odoo/enterprise#110835
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 streamlines how Odoo tests handle emoji assets, leading to faster test execution and reduced resource usage. The change allows assets to be cached across test suites, improving overall development efficiency. This work prepares for a future feature that will centralize emoji data management.
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. - Community: https://github.com/odoo/odoo/pull/253344
This update resolves a technical issue that caused tracebacks in the timesheet assistant when a user lacked an assigned employee within the company. This ensures the timesheet assistant functions correctly for all users, preventing disruptions to time tracking processes. The fix improves stability and usability.
Original PR description
This PR fixes two tracebacks when the current user has no employee in the current company and tries to open either the timesheets assistant or systray Task-6041462
This update corrects a numbering issue in the Vietnamese balance sheet report. Specifically, the order of lines within the 'I. Short-term liabilities' section was adjusted to ensure accurate reporting. This ensures financial reports are presented correctly for Vietnamese businesses using Odoo Enterprise.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update corrects a problem in the GSTR report testing process. Previously, tests were incorrectly deleting tax amounts. Now, the system removes taxes from the account move line, ensuring more accurate report calculations and compliance. This resolves a technical issue impacting reporting accuracy.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834 Forward-Port-Of: odoo/enterprise#111198 Forward-Port-Of: odoo/enterprise#105174
This update fixes a technical issue where Odoo would sometimes encounter an error when requesting shipping prices from Sendcloud. Specifically, if Sendcloud didn't respond, Odoo would throw an error. This change prevents these errors, ensuring smoother delivery processing and reducing potential disruptions to order fulfillment.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#111057 Forward-Port-Of: odoo/enterprise#109252
This 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 streamlines the new user sign-up experience by removing unnecessary steps in the onboarding tour. This change improves the initial user experience, making it faster and easier for new customers to get started with Odoo Enterprise. The simplification focuses on efficiency and reduces friction for new users.
Original PR description
runbot-238363
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 removes unnecessary code related to skipping model generation during worksheet creation. Following recent changes to the worksheet functionality, this specific context key is no longer needed. This cleanup improves the efficiency and stability of the web studio module.
Original PR description
Since the worksheet rework, the context key `worksheet_no_generation` that used to skip the model generation has now become useless. This commit removes last lines of code using it. *https://github.com/odoo/enterprise/commit/49a84d3ffea49cf8f7fea904e7082b101158bbe9
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 corrects a bug in the point-of-sale report generation process. Previously, the system incorrectly identified refund orders due to how it sorted order data by date. This change ensures that refund orders are always prioritized, guaranteeing accurate reporting of transactions.
Original PR description
The test test_refund_multiple_products_amounts_compliance was doing a search on 'report.pos.order' and was wrongly assuming that the first order in the recordset returned was the refund one and the other one was the original order. This was because the search is ordered by date descending and the refund order is created after the original order. However, in some cases, the date of the refund order can be the same as the date of the original order cause the dates are precise to the second which can lead to a the records returned by id ascending which would give the original order first. This commit adds an explicit order by id descending as second choice to ensure that the refund order is always returned first. runbot-error: 238454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253360
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 a problem where header border widths were incorrectly set to full widths due to a design flaw in the input field. The change ensures consistent border widths for standard headers while still allowing full borders for specific header templates, improving website appearance and stability.
Original PR description
Previously, the border width input for headers allowed multiple values. This was required for specific header templates (e.g. rounded box) that use a full border. However, most headers only apply a border on the bottom. When the input had multiple values, the scss would break, resulting in full border. This change ensures that, for headers without the .o_full_border class, only the first value of the saved border width is used. As a result, the input behaves like a single-value field (similar to font size inputs) for standard headers, while still supporting multiple values for templates that require a full border. Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the Border option, enter "1 2" and leave the input to validate => The input display "3" and the header has a full border. task-5500516 Forward-Port-Of: odoo/odoo#254483 Forward-Port-Of: odoo/odoo#244415
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 a bug in how the system calculates scrap quantities. Previously, if a product lacked a related BOM, the calculation would stop, leading to inaccurate scrap totals. Now, all products in a recordset are correctly processed, ensuring accurate scrap reporting.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253368 Forward-Port-Of: odoo/odoo#252149
This update fixes a bug where hover overlays on website builder sections weren't appearing when hovering over parent elements. The fix ensures the overlay is correctly positioned by explicitly triggering a refresh after the overlay is created, resolving a visual issue for users.
Original PR description
Commit 53ae0a9f646808632ca1ca396466e1c0bb5a73c7 adds a temporary overlay on hover of elements with options. But the overlay was not shown on over of an ancestor of the target. This is because it relied on the resize observer to call the `refreshPosition`, which does not happen if the element on which the hover overlay should appear was already observed. This commit adds an explicit call to `refreshPosition` after the creation of the hover overlay. Steps to reproduce: - Open website builder - Click on a column in a section - Hover the section outside of the column - Bug: no hover overlay is shown on the section element task-6013371
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 invoice previews in the portal displayed text in the wrong direction (LTR) for Arabic-speaking users. The fix ensures that invoice layouts correctly reflect the user's language setting, improving the user experience for international customers. Additionally, the subtotal layout for Saudi invoices has been adjusted to prevent visual clipping of tax totals.
Original PR description
When opening invoice HTML preview in the portal, the layout was displayed in LTR even if the invoice partner language was RTL (e.g. Arabic). This happened when the portal user language was LTR. PDF…
When opening invoice HTML preview in the portal, the layout was displayed in LTR even if the invoice partner language was RTL (e.g. Arabic). This happened when the portal user language was LTR. PDF structure was correct, but HTML preview had wrong text flow and alignment. Root cause was that RTL asset processing depends on `env.lang`, not on `t-lang` in templates. Since the ORM context language remained the portal user’s language, CSS was compiled in LTR and hardcoded `direction: ltr;` rules from `report.scss` were overriding the `<html dir="rtl">`. To fix this, the portal controller now checks the partner language and, if it is RTL, updates the request context before rendering. This ensures `_render_qweb_html` runs with the correct `env.lang`, triggering proper RTL CSS conversion via rtlcss. Additionally, the subtotal section in the Saudi invoice report could have its values visually cut due to insufficient width allocated to the tax totals column. The column width has been slightly increased to ensure totals are properly displayed. task-5878719 Forward-Port-Of: odoo/odoo#248822
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
A recent update to the website's job application form processing caused a technical error (KeyError) when users added a file field. This commit corrects the issue by reintroducing a necessary attribute that was unintentionally removed during a recent code change. This ensures the form submission process now functions correctly for all users.
Original PR description
Currently an exception is generated when the user tries to submit a job application through the form. Steps to produce an error: - Install the `web_studio` and `website_hr_recruitment` modules - Add…
Currently an exception is generated when the user tries to submit a job application through the form. Steps to produce an error: - Install the `web_studio` and `website_hr_recruitment` modules - Add a new File field to the `hr.applicant` module with the studio. - Go to the website editor and add the form `Apply for a Job` and add the recently created field into the form and save it - An error will occur when submitting the form with the added field Error: `KeyError: 'manual'` This issue occurs because the `manual` key(attribute) is not included in the `authorized_fields` variable, which is generated by the `get_authorized_fields` method. After the recent refactoring introduced in commit [1], the code was changed to fetch only a limited set of attributes instead of all attributes, and the manual attribute was not added to this list. This commit resolves the above issue by including the `manual` attribute when retrieving model fields, which was not added in commit [1]. [1]: https://github.com/odoo/odoo/commit/bfae7140d3951bec93fb7f2e49018649045edd40 Sentry-7271118700 opw-5933992 Forward-Port-Of: odoo/odoo#249240
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 update resolves a technical issue where tracking changes to signature fields within Odoo caused errors. The system was attempting to track signature updates, which isn't supported, leading to a crash. Now, signature fields are automatically excluded from tracking to ensure stability.
Original PR description
With https://github.com/odoo/odoo/pull/232814, the signature type was introduced as a valid property in properties field type. When a property field of type signature is marked as tracked and its parent field changes, the system attempts to track the signature update. Since tracking image or binary content is not supported and is not implemented, this leads to a NotImplementedError. To prevent this crash, signature property fields are now excluded from tracking. task-5966544 Forward-Port-Of: odoo/odoo#250923
This update resolves a bug where the 'is typing' indicator incorrectly appeared when users were editing messages in Odoo. The fix prevents this indicator from triggering, aligning with the intended use of the indicator – to signal new messages, not ongoing edits. This ensures a smoother and more accurate experience for users receiving updates.
Original PR description
Before this commit, when editing a message, this was triggering the "is typing" on this member. This "is typing" was only stopped after the long timeout of 1 min. Typing indicator is meant to expect other others to receive a new message, so this is misleading to show the "is typing" when editing the message. Usually editing message is to fix small typo in a very short time, so it's quite expected for other people to see the new changes without requiring UI indicator other than the "(edited)" label on message textual content. This commit fixes the issue by not notifying is typing on composer of message edition. Task-6045905 Forward-Port-Of: odoo/odoo#254747 Forward-Port-Of: odoo/odoo#254453
This update ensures invoices submitted to the Italian Public Administration receive correctly formatted XML responses. Previously, a misinterpretation of the IAP response format caused errors. This fix converts the XML to base64, resolving the issue and ensuring smooth invoice submission.
Original PR description
When submitting invoices to the Italian Public Administration, we receive an updated XML response from IAP with the document including a signature. The response is a raw XML string, not base64. Previously, we tried to encode it incorrectly, causing errors because `l10n_it_edi_attachment_file` direct assignment expects a base64 string. This fix converts the raw XML received from IAP to base64 before assigning it to the `l10n_it_edi_attachment_file` field. It also updates the test to use a correct mock IAP response. Forward-Port-Of: odoo/odoo#254800
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>