Thursday, March 12, 2026
57 changes · saas-19.2
New functionality added to Odoo
This update incorporates support for Mexican asset accounting within the Odoo system. Specifically, new asset models and corresponding account codes have been added to the Mexican tax template, aligning with local regulations. This enhancement ensures accurate financial reporting for businesses operating in Mexico.
Original PR description
This commit do two things: - Add the asset models into the Mx template - Update CoA with new accounts and descriptions task-4920083 target: 19.0 -> master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249939
This update adds a new button to quickly move all outstanding orders to their next stage in the order workflow. When an order reaches the final stage, the preparation status is automatically marked as complete, simplifying the process for staff. This improves efficiency and reduces manual effort in managing orders.
Original PR description
In this commit: =============== - We added a `Clear All Orders` button in the sidebar. On clicking that, all the orders will be moved to their next respective stage. - If the order stage is already the last stage, then the order's preparation state is marked as done. Task: 5877460 Forward-Port-Of: odoo/enterprise#105847
Enhancements to existing features
This update adjusts the trial balance tests within the Mexican accounting reports (l10n_mx_reports) to reflect recent changes to the Mexican Chart of Accounts (CoA). These changes ensure accurate reporting for Mexican businesses using Odoo Enterprise. This is an important improvement for financial reporting compliance.
Original PR description
Adapted trial balance tests to consider update on MX CoA task-4920083 target: 19.0 -> master Forward-Port-Of: odoo/enterprise#108200
Resolved issues and error corrections
This update resolves a bug where typing in an empty HTML editor button would remove the button element entirely. The fix prevents the browser from replacing the link node during text input, ensuring the button remains visible and functional. This improves the user experience when editing content within the HTML editor.
Original PR description
Problem: On the website, typing inside an empty button removes the button element entirely. Cause: In `beforeinput` (when `ev.inputType === "insertText"`), we set the selection to `boundariesIn` of a link. When the browser then inserts the character, it replaces the link node, causing the button to be removed. Solution: In `FormatPlugin.onBeforeInput`, avoid setting the selection to `boundariesIn` of a link for `insertText` events. This prevents the browser from replacing the link element when typing. Steps to reproduce: - Open Website. - Drop a snippet containing a button. - Triple-click on the button content. - Press Backspace to empty it. - Type any character. - Observe that the button is removed. task-5949409 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
This update removes a restriction in the EC Sales List report that was causing issues for businesses using individual company configurations. The change allows the report to accurately reflect sales data for all company types, regardless of whether they are set up as a business or an individual. This ensures more reliable reporting for all users.
Original PR description
Removing as the prod has a lot of companies that are configured as individuals. no-task Forward-Port-Of: odoo/enterprise#109855 Forward-Port-Of: odoo/enterprise#99807
This update enhances the way Odoo retrieves API keys for the base_geolocalize module. The change moves key retrieval to a separate method, improving the system's organization and stability. This ensures a more reliable and efficient process for accessing geolocation services.
Original PR description
Move the api key retrieval to another method. Forward-Port-Of: odoo/odoo#252618 Forward-Port-Of: odoo/odoo#243496
This update resolves a problem that occurred when loading the demo data for the 'account_asset' module. The fix corrects an error related to incorrect field definitions during demo data setup, preventing a data loading failure. This ensures demo data can be reliably loaded without disrupting the system.
Original PR description
This error occurs while loading the demo data for the `account_asset` module. Steps to reproduce: - Install `account_asset` module without demo data - Active debugger > Settings > load Demo data Traceback: `ValueError: Invalid field 'depreciation_model_id' in 'account.asset'` - The error occurs because `depreciation_model_id` is a field of the `account.account` model, but while loading the demo data we are defining it on the `account.asset` model in the `_get_demo_data_asset` [method]. - Another error occurs in the `account.depreciation.model` model because it does not have a field named `name`, the correct field is `display_name`. [method]: https://github.com/odoo/enterprise/blob/9d4424088bfda7e89d454a8bd642715a9281913d/account_asset/demo/account_demo.py#L37-L47 sentry-7321811436
A minor technical issue was resolved where an incorrect field was being used in the account online payment process. This prevented a system error and ensures data is processed correctly. The change improves system stability and reliability.
Original PR description
Due to an oversight during https://github.com/odoo/enterprise/pull/109070, the old field `sanitized_acc_number` was used instead of the new one `sanitized_account_number` This causes a traceback. No task ID
This update prevents the deletion of email template attachments when they are removed from the mail composer. Previously, removing an attachment would permanently remove it from all future emails. The fix ensures attachments remain associated with templates, maintaining consistent email content.
Original PR description
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by…
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by Email". 5. In the mail composer, remove the template attachment **Issue:** - The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails. **Cause:** - The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment. **Solution:** 1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server. 2. In `onFileRemove`, check the `res_model` of the attachment. 3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink) and only remove it from the composer view. opw-5163679 Forward-Port-Of: odoo/odoo#250086 Forward-Port-Of: odoo/odoo#238692
A minor warning appearing on Odoo website pages related to URL hashes has been fixed. This change ensures a smoother user experience by eliminating a potential technical issue that wasn't impacting functionality. The fix improves website stability and reliability.
Original PR description
Since [34df6f8d], a warning `Empty string passed to getElementById().` appears on every website page when there is no hash in the URL. That's not the case anymore after this commit. [34df6f8d]: https://github.com/odoo/odoo/commit/34df6f8d6efc879bef00228b19df04db6c884089 Forward-Port-Of: odoo/odoo#252181
This update resolves a visual issue where list views with search panels (like Rental and Employees) would sometimes display a horizontal scrollbar. This change ensures that list views with search panels display content correctly on mobile devices, providing a consistent and user-friendly experience. It corrects a minor display problem that could have impacted usability.
Original PR description
This PR aims to fix the horizontal scroll overflow which only affects list views with a search panel (e.g. Rental, Employees, etc.). task-5888678 | Before | After | |--------|--------| | <img width="1125" height="2436" alt="Screen Shot 2026-02-19 at 15 29 15" src="https://github.com/user-attachments/assets/b89d2979-78a8-4c58-8f7f-7dedb6fc8fff" /> | <img width="1125" height="2436" alt="Screen Shot 2026-02-19 at 15 30 10" src="https://github.com/user-attachments/assets/0989b6e7-ef91-43b5-8df5-c27696d43f65" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252362 Forward-Port-Of: odoo/odoo#249506
This update corrects a bug where users were seeing all company documents instead of just their own employee documents when using the documents smart button. The fix restores the intended behavior for companies without HR document centralization enabled, ensuring employees only access their own files. This resolves a previous issue impacting document organization.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update reduces the visual prominence of reply notifications in conversations with many replies. Previously, overly visible 'reply' text made long threads feel overwhelming. Now, the text is less intrusive and the hover effect is enhanced for better usability.
Original PR description
Before this commit, conversations that had a lot of replies were quite exhausting. This comes from the visual of "reply" text that had its text that is too visible, contributing to having a feeling that there's too much text on the screen. This commit fixes the issue by reducing the visibility of reply to part, so that it's easier to read conversations with lots of reply-to. Opacity has been reduced to keep the reply-to content recognizable enough, and this reduced visibility is canceled on mouse-hover, also making the hover effect on reply-to more apparent. Before / After <img width="604" height="520" alt="Screenshot 2026-02-27 at 19 06 03" src="https://github.com/user-attachments/assets/04a118bc-5fc0-47d6-ad62-3b7e26f835da" /> <img width="604" height="525" alt="Screenshot 2026-02-27 at 19 05 50" src="https://github.com/user-attachments/assets/37974f2c-054c-44bc-bf9a-044825908abc" /> Forward-Port-Of: odoo/odoo#251295
This update resolves an issue where self-order tests were failing due to a product's 'available in pos' status not being correctly set. This prevented products from loading properly in the self-ordering frontend, causing test failures. The fix ensures accurate product availability information, improving test reliability and preventing potential issues in the self-order system.
Original PR description
In some self order tests, available in pos was not set to true which could cause some errors in the tests as some products were not loaded in the self frontend. runbot-error: 241086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252985
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixes a problem where dates like '2500/1222' were mistakenly identified as '%Y.%m.%d' format, causing import errors. This change ensures that import files are processed correctly, preventing data import failures.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
This update ensures that when users send multiple messages in a live chat, only one channel is created. Previously, sending multiple messages could result in duplicate channels being formed. This change prevents channel duplication, streamlining the live chat experience for users.
Original PR description
Before this commit, sending multiple messages before the channel creation can result in multiple channels being created. It occurs because the post function is overriden to first persist the channel. When the persist call is still in progress, we shouldn't issue a new one. task-4756758 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#251596 Forward-Port-Of: odoo/odoo#250374
This update corrects an issue where late hours calculations were incorrectly applied to employees outside of Saudi Arabia. The fix now ensures that late hours visibility is only processed for employees within Saudi Arabian companies, improving accuracy and reporting for our SA clients. A new test case confirms this country-specific functionality.
Original PR description
Before this fix, the `_compute_l10n_sa_late_hours_visible` method was processing all attendance records regardless of the employee's company country. This caused issues for non-Saudi companies. Changes: - Filter attendance records to only process employees from Saudi Arabian companies (country_code == 'SA') - Set `l10n_sa_late_hours_visible` to False for non-SA attendances - Add `employee_id.company_id.country_id` to the compute dependencies - Add `string` attribute to `l10n_sa_expected_check_in` field - Add test case to verify late hours visibility is country-specific task-5491785 Forward-Port-Of: odoo/enterprise#104563
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change ensures compliance with `DK-R-013` by skipping the inclusion of PartyIdentification, preventing errors and improving invoice processing for Danish businesses using Peppol.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update resolves an issue that occurred when users attempted to remove a company association from an expense record. The fix ensures the system handles company removal gracefully, preventing a technical error that could disrupt expense management. This improves the reliability of the expense tracking process.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update resolves a problem where Discuss Notifications sound settings weren't correctly applied after upgrading to version 19.1. The issue stemmed from a version comparison error related to the 'saas~' prefix. This change ensures notifications settings are properly updated during upgrades, maintaining expected functionality.
Original PR description
Before this commit, upgrade of local storage from 19.0 to 19.1 were not working. Steps to reproduce: - have DB in 19.0 with message sound "off" in Discuss Notifications settings - upgrade to 19.1 DB (or make a fresh 19.1 DB on same sub-domain) - log on this new DB => "message sound" settings is "on" when it should be "off". This happens because the server version is "saas~19.1" and the prefix `saas~` was not taken into account. As a result, the version `saas~19.1` was mistakenly considered as lower than `19.0`. This commit fixes the issue by omitting the prefix `saas~` in the utils function of version comparison, which is what is used by the local storage internal code to compare versions. Upgrade version has been bumped to `19.1.1` and upgrade scripts have their sub-version explicitly set to `19.1.0`, so that these scripts are run for versions equal or lower than `19.1.0`, meaning they re-run also for `19.1.0`. Task-6008166 Forward-Port-Of: odoo/odoo#252204
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now gracefully handles this attachment type by falling back to a standard format, ensuring all emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update prevents installation errors related to PostgreSQL permissions. Previously, the system would fail if the PostgreSQL user lacked the necessary rights to create extensions. Now, the system checks if the extension is already installed before attempting to install it, reducing the need for extensive PostgreSQL user permissions.
Original PR description
[FIX] ai: test if pg_vector is installed before launching the create extension command
The command `CREATE EXTENSION IF EXISTS ...` require the postgresql user to have rights to use the command `CREATE EXTENSION`.
If the extension is already installed it will fail with a stacktrace because of inssuficient rights. `psycopg2.errors.InsufficientPrivilege`
With this PR we want to be able to install the module without giving too many rights to the postgresql user.
Forward-Port-Of: odoo/enterprise#109650This update corrects a previous issue where users with limited inventory access rights couldn't save new delivery records. The change ensures that access controls are properly enforced when saving stock moves, preventing errors related to data writing. This improves usability for all users, regardless of their access level.
Original PR description
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld…
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module. Cause of the issue: Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53 Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error. runbot-240937 Forward-Port-Of: odoo/enterprise#109817
This update fixes a bug where the website's industry selection didn't correctly recognize capital letters or synonyms. The fix made the matching case-insensitive and simplified the synonym matching process, ensuring users can accurately select industries.
Original PR description
The industry highlighting to indicate what the user wrote match with the proposed industries was case sensitive, so the capital letters were not indicated as matching with lowercase letters. Fix: Added the flag "i" at the end of the regex to make it case-insensitive Also, in the case of the synonyms, the regex used was spliting on ",", "|" and space. The space spliting made matching a synonym sentence much more complicated. Fix: Deleted the space in the regex task-5066428 Forward-Port-Of: odoo/odoo#252447
This update resolves an issue preventing the activation of Point of Sale (POS) configurations when a POS session was already open. Previously, a session had to be closed before a new configuration could be applied. This change ensures smoother POS configuration management and avoids disruption for users.
Original PR description
Before this commit, it was not possible to activate a pos.config if there was an open session linked to it. This was a problem because it is only possible to close the session when the pos.config is active, and it was not possible to activate. opw-5964181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250591
This update fixes a problem where invoices were incorrectly marked as coming from the company when forwarded bills included the company's email address. This ensures invoices are accurately attributed to the correct vendor, improving billing accuracy and reporting. The change was a simple bug fix.
Original PR description
Prevent setting the company's partner as the vendor for a forwarded bill when the body contains the company's email. Forward-Port-Of: odoo/odoo#252815
This update fixes a technical error that prevented users from successfully printing payslips. The issue stemmed from incorrect data being passed to a key function, causing a traceback. The fix ensures payslips can be printed reliably, improving payroll processing.
Original PR description
Steps: - Install l10n_us_hr_payroll - Create an employee and contract - Create a leave allocation - Create a payslip and print it Issue: A datetime value was being passed to the generate_work_entries function, which caused a traceback. Fix: pass only the date to the generate_work_entries function.'
This update resolves a technical error that occurred when processing refunds in the Spanish Point of Sale (POS) module. Specifically, a 'singleton error' was triggered due to incorrect data being passed during refund operations. The fix ensures the correct order ID is used, preventing the error and ensuring refunds process smoothly.
Original PR description
Step to reproduce: - install l10n_es_pos - create a pos, open its setting and set its `Simplified Invoice` with a journal - start pos, create a order and refund it Observation: - we receive a singleton error for account.move Cause: - when calling `get_invoice_name` method, we pass `order_server_ids` which contains order and refund order id, hence two ids are passed Fix: - instead of using `order_server_ids` we use 'order.id' i.e. current order opw-5870707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251755 Forward-Port-Of: odoo/odoo#247986
This update optimizes the process of installing demo data in Odoo. It prevents unnecessary API calls and email notifications during this installation, resulting in faster and more efficient setup. This change improves the overall user experience and reduces server load.
Original PR description
Followup on https://github.com/odoo/odoo/pull/25086 to avoid making api calls, sending emails when installing demo data on an existing database Forward-Port-Of: odoo/odoo#252912
This update resolves a minor display issue in the account reports where the green comparison color was not consistently appearing. The fix corrects a conversion error introduced after the Dictalypse merge, ensuring the correct color is now displayed for comparison data.
Original PR description
With Dictalypse merged, there is a small mistake converting mode <=> comparison_mode since column_percent_comparison_data is now technically a column. The fix is to use comparison_mode instead of mode in the js view.
This update prevents a crash when multiple employees are selected and the 'End of Collaboration' action is initiated. The action was incorrectly designed to work with list views, leading to an error. Now, the action is only available when working with a single employee record in the form view.
Original PR description
## Steps to reproduce: - Go to Employees list view - Select multiple employees - Action menu > "End of Collaboration" - ValueError is raised: "Expected singleton: hr.employee(...)" ## Reason: - The server action `action_hr_employee_departure` had no explicit `binding_view_types`, so it defaulted to `list,form`. - When triggered from the list view with multiple records selected, it called `action_new_departure()` which enforces `ensure_one()`, causing a crash. - Multiple departures are no longer supported https://github.com/odoo/odoo/pull/245519/changes/774853c1e13a556edd61eea7f4bce65e8b7fc163 ## Fix: - Action is only surfaced in the form view, where the recordset is always a singleton. Task-3505331
This update corrects a technical issue where unused database records related to HR work entries were not being properly removed. The fix ensures the database remains clean and efficient, preventing potential performance impacts. This change is considered low impact.
Original PR description
The records `hr_work_entry.access_hr_work_entry_officer` and `hr_work_entry.access_hr_work_entry_system` no longer exist. They have been removed by https://github.com/odoo/odoo/pull/244436. runbot_build_error-240728
This update resolves a technical issue that prevented users from exporting data from the CRM forecast reports via the Kanban view. The problem occurred when the system processed empty month columns, leading to a division-by-zero error. This fix ensures data can now be reliably exported without errors.
Original PR description
Steps to reproduce: 1- Install CRM 2- Go to [CRM -> Reporting -> Forecast] 3- Export the data from Kanban view Description of issue: Traceback: ZeroDivisionError Expected behavior: Should export into excel sheet without error Why this happens: When exporting from a Kanban view, all month columns are processed even if they contain no records. In these cases: 1. `self.data` is empty, causing the logic to skip the if condition 2. Since `self.count` is 0, the final division fails with a ZeroDivisionError. opw-5962440 Forward-Port-Of: odoo/odoo#252262
A technical issue prevented the generation of customer statement reports. This fix ensures the necessary data is always provided to the report generation process, resolving an error that caused the preview and PDF generation to fail. This improves the reliability of a key reporting feature.
Original PR description
**Steps to reproduce:** * Install the **l10n_my_reports** module. * Go to `Accounting > Reporting > Partner Ledger`. * Change report to `Customer Statement`. * Add data in the report and click Send. * In the email template, set the `dynamic reports` as `statement of accounts` under the options tab. * Click Preview. **Observed behavior:** * Error: `TypeError: Domain() invalid argument type for domain: None` * Email preview fails and PDF cannot be generated. **Cause:** * The `statement_account_document` template uses `filtered_domain(domain)` but the domain variable was not being passed to the template context by the `_get_report_values` method, resulting in None being passed to `filtered_domain()`. **Fix:** * Ensure domain is always present in the report context, defaulting to an empty list when not provided. * Added safe handling for missing data and context parameters. opw-5880385 Forward-Port-Of: odoo/enterprise#107400
This update fixes a potential error in the Account PEPPOL module that could cause sync failures when a PEPPOL user isn't configured. The change simply skips the email proxy sync process in these situations, ensuring smoother and more reliable operation. This improves the overall stability of the PEPPOL integration.
Original PR description
**[FIX] account_peppol: skip contact email proxy sync when no peppol user exists.** Before this fix the sync would fail in certain scenarios when there is no proxy user preset in the database. The fix is to simply skip the proxy call if no user is present. opw-5980696 Forward-Port-Of: odoo/odoo#251719
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a visual bug where the 'group payment' button was incorrectly displayed has been resolved. This ensures accurate payment tracking and a better user experience.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#252870 Forward-Port-Of: odoo/odoo#247830
This update fixes an issue where the SEPA payment wizard incorrectly displayed the number of payments being skipped. The change ensures the warning message accurately reflects that only the first installment of each bill is being paid. Additionally, a visual bug related to the 'group payment' button has been resolved.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#110020 Forward-Port-Of: odoo/enterprise#106894
This update fixes an issue where average daily and weekly hours weren't calculated correctly when using the 'Define Amount of Hours per Day' option in employee schedules. The fix ensures that hours are accurately computed based on duration when this option is selected, leading to more reliable time tracking data.
Original PR description
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per…
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per week fields aren't computed correctly. ## Reproduction Steps 1. Go to Employee > configuration > Working Schedules. 2. Create a working schedule. Check the box Define Amount of Hours per day and in the Working Hours tab, remove all intendances. 3. Add a line for Monday, set the day period to Full Day and the duration in hours to 4. 4. Repeat the operation for tuesday and wednesday. ### Expected behavior As we have 3 days during which we work 4 hours, the average hours per day should be 4, and the total hours per week should be 12. ### Unexpected behavior The average hours per day and hours per week don't show the correct numbers. ## Origin of the issue We compute the hours per week with this method: https://github.com/odoo/odoo/blob/ae9fd7cc7d434d4b222c81aa58515c57d7426b65/addons/resource/models/resource_calendar.py#L690-L696 However, when we check the box `Define Amount of Hours per Day`, we don't set the attendances starting and ending hours. Instead, we work with duration hours. Therefore, when the box is checked, we have to compute the weekly hours with the field `duration_hours`, and not `hour_from` / `hour_to`. __ opw-5885571 Forward-Port-Of: odoo/odoo#248627
This update resolves an issue preventing remote calls to certain class methods within Odoo. Specifically, methods defined as `@classmethod` or `@staticmethod` were incorrectly accessible. This change enforces a stricter policy, ensuring only standard methods can be called remotely, improving overall system security and stability.
Original PR description
Access /doc, see that `is_transient` is listed, call it via JSON-2. Error 422 "Unprocessable Entity": too many positional arguments.
The `is_transient` method is defined as follow:
```py
@classmethod
def is_transient(cls) -> bool:
""" Return whether the model is transient.
See :class:`TransientModel`.
"""
return cls._transient
```
It is a `@classmethod` and take no argument. Only regular methods can be called remotely. The `@classmethod` and `@staticmethod` (actually, all methods that are defined on the class, and not on the instance) are now considered private.
Reported-by: Florent Xicluna <florent.xicluna@camptocamp.com>
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#253066
Forward-Port-Of: odoo/odoo#252739This update corrects a calculation error in the HRA (House Rent Allowance) rules for Indian employees. The change ensures that HRA percentages are accurately applied, aligning with standard India payroll practices. This improves the consistency and reliability of employee compensation calculations.
Original PR description
… fields - compute HRAMN from categories['BASIC'] with result_rate = l10n_in_hra_percentage * 100 - add python condition to skip the rule when HRA percentage is zero - keeps ind_emp behavior consistent with regular India payroll rules task-5964270 Forward-Port-Of: odoo/enterprise#108507
This update resolves a technical issue within the Odoo Enterprise payroll module (l10n_be_hr_payroll) that was causing errors. The fix corrects a mistake in how the system processed data, preventing a system failure and ensuring accurate payroll calculations. This ensures the payroll system continues to function correctly.
Original PR description
Use the correct var instead of self in the loop.
This solve the raise ValueError("Expected singleton: %s" % self) raised by the orm.This update fixes an issue where customers could set subscription start dates to 'False', leading to incorrect invoicing. The change prevents users from removing the start date, ensuring subscriptions are correctly billed moving forward. This maintains accurate subscription tracking and billing.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update fixes an issue where the Instagram API would return errors when trying to retrieve poll information before a post was fully published. The change now checks the post's status first and only requests the poll ID when the post is confirmed as published, preventing errors and ensuring smoother operation. This improves the reliability of Instagram polls within the system.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094
This update resolves an issue where the website blog would display an error when users tried to access URLs with invalid tag information. The fix ensures that the system correctly handles cases where tag IDs are missing, preventing the error and maintaining a stable browsing experience for website visitors. This change improves the overall reliability of the website blog feature.
Original PR description
Steps to reproduce: - Install `website_blog` module(with demo data) - Change URL (eg: /blog/tag/hotels) Traceback: `AssertionError: Invalid falsy real id` We are encountering this error because [active_tag_ids] contains `[None]`, and falsy IDs are no longer allowed in `browse()`. [active_tag_ids]: https://github.com/odoo/odoo/blob/4e4d1dba32ef45567eda004fc1a3584591508720/addons/website_blog/controllers/main.py#L83 sentry-7289765426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250647
This update fixes a minor typo in the name of a work entry type used in the Belgian version of Odoo. The change ensures accurate reporting and data consistency for overtime hours related to social security contributions. This update does not impact core functionality.
Original PR description
Version: saas-19.1 Fix typo in belgian work entry type name: - from "Overtime Hours not suject to social security contribution" to "Overtime Hours not subject to social security contribution" Task-5946323 Forward-Port-Of: odoo/odoo#249209
This update fixes a persistent issue where temporary files were left behind during browser testing. By using a more robust cleanup system with ExitStack, the code now ensures all temporary files are removed regardless of test success, improving test reliability and reducing potential data inconsistencies. This change enhances the stability of our automated tests.
Original PR description
Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the `atexit.callback(browser.stop)`:…
Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the `atexit.callback(browser.stop)`: the temporary directory for the user data dir is created as soon as the browser is instantiated, but the cleanup is only recorded after a successful `navigate_to`, so if that (or a previous step e.g. authentication) fails then the tempdir is never cleaned up. Rather than just move the call up the body and re-introduce conditionals to `stop` to handle more partial initializations though, use the magic of ~~buying two of them~~ `ExitStack` to record cleanup requirements dynamically as the `ChromeBrowser` initialises. This initially used a bunch of `ExitStack.callback` calls with ad-hoc cleanup, but turns out most of these cases are better as CMs: - replace `mkdtemp` / `rmtree` by `TemporaryDirectory`, which Just Works as a CM - add context-manager methods to the screencaster classes (also remove `stop` which is redundant with `__exit__`) so they Just Work as CMs - convert `_chrome_start` and `_open_websocket` to `@contextmanager`... for obvious reasons This makes the relation between setup and cleanup clearer, as well as more self-contained in case we want to move stuff to a submodule eventually. It also ensures cleanups run in the correct order, and avoids having to deal with partial initializations. Keep `ChromeBrowser.stop` because it seems unnecessary to edit those out for now, but have it just `close` the exitstack (which runs all the registered cleanups). NOTE: it might make sense for `browser_js` to just use `ChromeBrowser.cleanup` instead of having its own exitstack, not entirely sure... Alternatively it might make sense for ChromeBrowser to *take* a CM as parameter... and / or for ChromeBrowser to *be* a CM? Forward-Port-Of: odoo/odoo#253035
This update fixes a technical issue causing excessive, unwanted warnings within Odoo. The problem stemmed from an outdated version of Werkzeug being used, which incorrectly handled warning messages. This has been resolved by updating to a version with the necessary fixes, preventing duplicate warnings and improving system stability.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252427 Forward-Port-Of: odoo/odoo#252193
This update resolves an issue in the Nemhandel integration for Denmark (DK) by adding a required attribute to the XML format. Specifically, the 'schemeID' was missing, which is essential for correctly identifying the buyer according to OIOUBL 2.1 standards. This ensures accurate data exchange with Danish tax authorities.
Original PR description
Nemhandel follows the OIOUBL 2.1 XML format. To specify the Buyer identifier, we use the <cac:PartyIdentification> node. But we are missing the `schemeID` attribute, which should be for DK "DK:CVR". This commit adds this attribute. opw-5232123 Forward-Port-Of: odoo/odoo#253132 Forward-Port-Of: odoo/odoo#250942
This update fixes an issue where the Website Studio XML editor incorrectly displayed translations for all websites, regardless of the current website being used. The change ensures that translations are only applied when editing views within the Website Studio editor, improving the user experience and preventing incorrect translation display.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/odoo#252063 Forward-Port-Of: odoo/odoo#237000
This update ensures that Website Studio's translation terms are correctly applied only to views within the Website module, resolving an issue where the default website's language was being used. This change improves the accuracy of translations within the Studio editor, providing a more reliable experience for users working with Website-related views.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#109572 Forward-Port-Of: odoo/enterprise#107459
This update resolves a UI issue that occurred when changing wage intervals in the employee payroll settings. The problem stemmed from extra text being inserted into the employee form, causing errors. This fix removes the problematic text, ensuring correct wage interval handling.
Original PR description
Bug production steps: First, I created a new db with saas-19.1 db from runbot, from payroll->employee->Payroll tab in form view, when you change wage interval to another thing than 'month' error occurs Bug cause: There is another text like /2 months, /2 weeks are inserted from hr_employee_views in the hr_contract_salary_payroll to the XML of the employee form view. Bug solution: Removing the corresponding XML insertions. task - 5469378 Forward-Port-Of: odoo/enterprise#104116
This update clarifies the message displayed when a live chat conversation ends, replacing ambiguous ellipses with a clear statement. This change improves the user experience by removing potential confusion and ensuring users understand the conversation has concluded. The update was part of a larger maintenance effort.
Original PR description
This commit updates the chatbot completion message from 'Conversation ended...' to 'Conversation has ended.' The previous version used ellipses, which typically suggest an incomplete thought. Since the message is meant to clearly indicate that the conversation has concluded, the ellipses were unnecessary and potentially confusing. Forward-Port-Of: odoo/odoo#253167 Forward-Port-Of: odoo/odoo#251166
This update fixes a visual inconsistency in the mega menu on mobile devices. Changing the navbar font style (like 'Arvo') caused the back arrow to display with an incorrect font. The fix ensures the back arrow uses the standard Odoo UI icons, maintaining a consistent and professional appearance.
Original PR description
Steps to reproduce: =================== 1. Go to webstie and add a mega menu 2. Change Navbar font (e.g. to "Arvo") 3. Switch to mobile view and open the mega menu -> the back arrow will have unexpected style. Cause: ====== The selector `.navbar .nav-link` applies the custom navbar font-family (e.g., "Arvo") to all `.nav-link` elements inside the navbar. The mega menu back button has classes `btn nav-link oi oi-chevron-left`, so it matches this selector. Since `.navbar .nav-link` has higher specificity than the base `.oi` class, the custom font overrides `font-family: 'odoo_ui_icons'`. Solution: ========= force the .oi font-family. opw-5949405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251394
This update corrects a minor issue where the styling of popups wasn't always reflecting the most current state. The fix ensures that popup displays are consistently updated, preventing potential visual inconsistencies. This improves the overall user experience and reliability of the website.
Original PR description
The attribute change processor supposed to avoid changing the `display` property of the `style` attribute of the popup element when an history step is replayed (added in cce4527c85e3240ff50fa573b141bc5973a46c2e) was mistakenly using the old display value from the history instead of the current value of the target. This was usually not an issue because in the cases where those value differed, the popup was about to be revealed (or hidden) anyway to show the target at that history step. This commit keeps the value of the property `display` of the `style` attribute as it is currently on the target, instead of the value of what it should have been as registered by the history. task-5149984 Forward-Port-Of: odoo/odoo#253106
This update streamlines the search functionality within the sales timesheet module. A previous extension to the 'Services & Materials' search view was removed, eliminating unnecessary options based on data that wasn't consistently used. This improves search performance and clarity for users.
Original PR description
This commit disables an unnecessary search view extension in `sale_timesheet` for the *Services & Materials* view. The extension was adding *group by* and *filter* options based on the fields `project_id`, `employee_id`, and `task_id` which are never set on Services analytic lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a minor issue in the Belgian payroll module (l10n_be_hr_payroll) by using the correct loop variable instead of 'self'. This ensures accurate calculations and reporting related to employee payroll processing, improving data reliability.
Original PR description
Use loop variable instead of `self`.
This update corrects a minor issue in the account reports module, ensuring that comparisons are displayed accurately. Following the recent Dictalypse merge, a change was made to how data is processed, and this fix ensures the green comparison indicator functions correctly. This improves the clarity and reliability of financial reporting.
Original PR description
With Dictalypse merged, there is a small mistake converting mode <=> comparison_mode since column_percent_comparison_data is now technically a column. The fix is to use comparison_mode instead of mode in the js view.