Tuesday, April 28, 2026
49 changes · saas-19.3
Resolved issues and error corrections
This update ensures the o_spreadsheet component used within Odoo 19.3 is running the latest version. This improves the functionality and stability of the spreadsheet feature, which is used for various reporting and data management tasks. The update was developed by a team of Odoo engineers.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/be0ca17fdc [REL] 19.3.0 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) 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>
This update fixes a technical issue that caused a traceback error when viewing restaurant bookings with no bookings scheduled. The problem stemmed from an automatic change introduced during a migration, which incorrectly targeted a variable. This commit corrects the variable access, ensuring the booking list displays correctly even when empty.
Original PR description
Inside the custom list renderer for booking for pos_restaurant we access `this.list.records` which doesn't exist and throws a traceback when no there are no bookings. The `this.` was added automatically by a migration script for OWL3 to force this usage to target component variables. But in this case `list` is set inside the web.ListRenderer template with `t-set`. This commit will revert the automatic change for the access to and replace `this.list.records`, with `list.records` Task-[6147678](https://www.odoo.com/odoo/project/1737/tasks/6147678)
This update corrects a technical issue related to how binary data is handled within the l10n_uk_reports_cis module. A recent change in Odoo required a specific format ('BinaryBytes') for binary fields, which was previously causing errors. This fix ensures the module functions correctly and avoids data processing problems.
Original PR description
Since https://github.com/odoo/odoo/pull/244421, binary field does not accept 'bytes' but to be wrapped explicitly as 'BinaryBytes' task-5481774
This update resolves a problem where activity updates weren't reliably shared between tabs in Odoo. The issue stemmed from interference with a specific internal route (`/mail/data`) during testing. This fix ensures that activity updates are consistently reflected across all relevant tabs, improving user experience.
Original PR description
The `@mail/activity/activity/activity updates are shared between tabs` fails in a non-deterministic fashion. It occurs because the `/mail/data` route can interfere with the test. runbot-242616 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#260862 Forward-Port-Of: odoo/odoo#260265
This update ensures consistent test tagging across Odoo versions 18 and 19, preventing disruptions to the nightly test suite. Previously, an error during test parsing could lead to the entire suite being disabled. This change backports a key fix to ensure reliable test execution.
Original PR description
When an error is parsed during the nightly, the default test tag is not correct in 18 and 19, what could lead to disabling the complete hoot suite if not taking enough care when disabling a test. This backports part of #234937 to ensure with have the correct tag in all version supporting hoot tests. Forward-Port-Of: odoo/odoo#261618 Forward-Port-Of: odoo/odoo#261526
This update ensures that the unit of measure (UoM) specified for a supplier's information related to a specific product variant remains consistent across all other variants of the same product. Previously, this could lead to inconsistencies in pricing and ordering. This fix improves data accuracy and reduces potential errors in purchase order processing.
Original PR description
Make sure any UoM defined on a supplierinfo having a specific variant cannot be used by other variant of the same product template Task: 6042382 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#260490 Forward-Port-Of: odoo/odoo#259213
This update corrects a warning message that incorrectly flagged transactions using the Cash Basis accounting method as having an inactive Construction Industry Scheme. The fix ensures that CABA entries are properly excluded from this check, preventing unnecessary alerts and streamlining reporting. This improves the accuracy of CIS-related data.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
A minor bug preventing the generation of EC sales returns was resolved. This issue stemmed from a typographical error introduced during a recent update to the ec sales list report. This fix ensures accurate reporting of returned sales transactions.
Original PR description
With the rework of the ec sales list report(https://github.com/odoo/enterprise/commit/4096c1fcbd7f31f70153058d2e3f9eab6d82e356#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29), the return generation of this type became generic but a small bug appeared. It was not generating anymore because of a typo. Forward-Port-Of: odoo/enterprise#114815
This update ensures that adding a new car or bike automatically makes all vehicles of the same type available in the system. Previously, adding a new vehicle could incorrectly make vehicles of a different type visible. This change maintains consistent vehicle availability for better reporting and management.
Original PR description
When you are getting a new car or a new bike, it'll make available all the your vehicle whatever is the type of vechicle. To keep consistent behaviour, we are only make available vahicle of same type Bug introduced in refactoring: https://github.com/odoo/odoo/pull/220160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261002
This update resolves an issue where invoice settlement could fail if the commercial partner information wasn't fully loaded. The fix now directly uses the partner ID from the invoice data, streamlining the process and preventing errors. This ensures smoother invoice settlement operations.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#114110 Forward-Port-Of: odoo/enterprise#111957
This update corrects a minor issue where payslips were incorrectly marked as 'paid' during report generation for the ISO20022 payroll accounting module. This ensures that reports accurately reflect the status of payroll transactions, improving data reliability for financial reporting. The change was a simple fix to prevent an unintended action during the report generation process.
Original PR description
…t generation Forward-Port-Of: odoo/enterprise#115273
This pull request corrects a minor typo within the marketing automation test suite. The fix ensures the tests run smoothly and accurately, maintaining the quality and reliability of the marketing automation functionality. This is an internal technical update.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
This update fixes an issue where the 'Hide lines at 0' feature was removing the report-level total line from reports like the Trial Balance when printed. This commit ensures that total lines, including those without a parent, are always displayed, improving report accuracy and clarity for users. This change was implemented to maintain consistent and complete reporting.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#115011 Forward-Port-Of: odoo/enterprise#114084
This update fixes a bug that prevented links within 'Button' snippets added to the website builder from being translated. Previously, these links were excluded from the translation process. Now, dropped button links are correctly tagged for translation, ensuring all website content can be localized.
Original PR description
Before this commit, links on `Button` inner snippets dropped from the sidebar (not through powerbox) were never translatable. `o_translate_inline` was only added in link insert flows or when already present in snippet template, not when dropping inner button snippets. As a result, dropped button anchors were missing `o_translate_inline` and were filtered out from translatable inline links. Steps to reproduce: - Enter edit mode. - Drag and drop a `Button` inner snippet. - Save. - Switch to translation mode. - Try to edit the button link: it cannot be edited. This commit adds handling on snippet drop to tag dropped anchors with `o_translate_inline`. task-5943645 Forward-Port-Of: odoo/odoo#261433 Forward-Port-Of: odoo/odoo#249019
This update resolves an issue where repeatedly deleting images in an Image Wall snippet caused a technical error (traceback). The fix adds a check to ensure the element still exists in the webpage before attempting to delete it, preventing the error and ensuring smooth operation.
Original PR description
Error: Cannot read properties of null (reading 'children') Steps to reproduce: 1.Go to Website -> Edit mode. 2.Add an Image Wall snippet. 3.Click on an image, then repeatedly click the Delete button. 4.Traceback occurs. Before this commit: The first delete click correctly removes the target element from the DOM, including its parent. On subsequent rapid clicks, the handler runs again on the same already-removed element. At that point, parentElement is null, so accessing children throws a traceback. After this commit: Added a safety check using `isConnected` in the delete handler to ensure the element is still part of the DOM. If not, the handler returns early. Repeated delete clicks no longer cause a traceback. task-6033622 Forward-Port-Of: odoo/odoo#261341 Forward-Port-Of: odoo/odoo#255733
This update ensures that the Slovak VAT tax reports generated by Odoo comply with the official Slovak XML format. Specifically, it enforces the required 2 decimal place precision for editable tax report cells, aligning with the latest VAT XSD schema. This improves data accuracy and avoids potential issues with VAT reporting.
Original PR description
As per the Slovak VAT XSD schema, editable fields must use a precision of 2 decimal places. So updating here to ensure compliance with the official XML format. Reference: https://ekr.financnasprava.sk/Formulare/XSD/dph2025.xsd Forward-Port-Of: odoo/odoo#261459
This change corrects a bug where archived email templates were incorrectly displayed in the applicant refusal wizard. The fix ensures that only active email templates are suggested, preventing confusion and ensuring accurate email communication during the application refusal process. This improves the user experience and data consistency.
Original PR description
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to…
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to reproduce: ------------------------- 1. Install hr_recruitment. 4. Go to Recruitment > Applications > All Applications and open an applicant. 5. Click on the "Refuse" button to open the refuse wizard. 6. Click on the "Email Template" and click on 'Search More' 7. Observe available templates Issue: ------- If a refuse reason is linked to an archived email template, the wizard automatically pre-fills that archived template Cause: ---------- The `_compute_template_id` method automatically assigns the template from the refuse reason without checking whether the template is active, which allows archived templates to be pre-filled in the wizard. https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96 Solution: ----------- - Update `_compute_template_id` to ensure only active templates are automatically assigned. opw-5974244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260853 Forward-Port-Of: odoo/odoo#251186
This update changes the email address used for automated IAP communications from iap@odoo.com to noreply@odoo.com. This change improves email deliverability and reduces the likelihood of incorrect responses to automated messages from Odoo.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/odoo#260794 Forward-Port-Of: odoo/odoo#259691
This change updates the email address used for automated support notifications from iap@odoo.com to noreply@odoo.com. This improves email deliverability and reduces the risk of clients responding to outdated support addresses.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097
This update removes inactive reports from appearing in search results, enhancing the user experience. It also resolves a minor bug impacting VAT Return reports for Czech customers, ensuring accurate reporting. This improves the reliability of the reporting system.
Original PR description
When searching for reports through the search panel inactive reports still show up in the result, this change hide the inactive variant reports from the search result. Also, fixes a minor bug related the l10n_cz, When search for VAT Return (CZ) it would cause a bug due to missing the target report to look into. task: 6149101
This pull request reverts recent cosmetic updates to the Mercado Pago payment module. These changes were previously introduced and are now being rolled back to maintain the stability and consistency of the payment processing system. This ensures a reliable experience for our users.
Original PR description
Revert the cosmetic changes that I introduced in commit 48709bb7be4b008b4f890577be06b64bb559d486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures vehicle license plates are included in invoice exports when the enterprise 'account_accountant_fleet' module is used. It also corrects a bug related to tax calculations within the 'hr_expense' module, preventing incorrect repartition line splitting. This improves data accuracy and consistency for invoicing.
Original PR description
[FIX] account_fleet,hr_expense: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs Also fix a bug when expense is installed: super was not called in a method about tax lines, causing side effects (splitting repartition lines when it shouldn't) runbot-242562
This update ensures that vehicle license plates are included in the invoice export XML file when the Enterprise module (`account_accountant_fleet`) is active. Previously, community databases lacked this information. Additionally, a bug causing incorrect tax line splitting has been resolved, improving data accuracy.
Original PR description
[FIX] account_accountant_fleet: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs Also fix a bug when expense is installed: super was not called in a method about tax lines, causing side effects (splitting repartition lines when it shouldn't) runbot-242562
This update fixes a problem where Wise payments were failing due to slight differences in recipient information (like spacing or casing). Now, the system uses only bank account details (like account number and routing number) to match recipients, ensuring accurate and reliable payments. This also consolidates IBAN and SWIFT recipients for broader compatibility.
Original PR description
Previously, _generate_wise_key included partner name and email in the matching key. If these differed between Odoo and Wise (e.g. trailing spaces, casing), the match would fail and a duplicate recipient was created. Use only financial identifiers (account type, routing number, account number) which are the actual unique identifiers for bank accounts. This is for example important with IBAN accounts as the won't have an email stored in Wise. From this we combine IBAN and SWIFT recipients into one non-US group. Forward-Port-Of: odoo/enterprise#115209 Forward-Port-Of: odoo/enterprise#113234
A minor visual issue in the loyalty wizard has been resolved. The 'Discard' button was missing its label, making it difficult for users to identify. This commit restores the label, ensuring clarity and ease of use for this feature.
Original PR description
The label on the Discard button was accidentally removed in forward-port commit 344661bb057bec1415651dadbd6069a1a543f208. Without the label, the button is not visible/identifiable in the popup. This commit restores the missing label. Before: <img width="1002" height="259" alt="image" src="https://github.com/user-attachments/assets/0651d5f8-379e-4084-ad42-5d5931eaeb52" /> After: <img width="1003" height="270" alt="image" src="https://github.com/user-attachments/assets/0d98b7d0-06e1-4d7f-be1f-9fd3e5a87f07" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor issue where query counts weren't accurately reflected during post-installation testing of the demo data. The fix ensures that performance tests run correctly, providing more reliable results for the demo environment. This improves the overall stability and predictability of the Odoo demo.
Original PR description
Query counts were updated for demo data. Missed a query update in post install test in #260655. runbot-242325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update introduced a search function on the Indian Company homepage, which triggered a technical error. This fix addresses a problem where the search functionality would fail due to an incorrect handling of report data. The update ensures a stable search experience for users on the Indian Company version.
Original PR description
Steps to reproduce: 1. Install l10n_in_reports and switch to Indian Company. 2. Go to homepage and try to type something and search on the search box. A traceback will appear. Cause: In recent updates, it is now possible to search report varients through the search menu, so while fetching varients while preparing search results, this leads us to `_is_available_for` method. The cause lies in how `.get()` is being used. `_get_external_ids` returns `id: []` if no external id is linked to it, and here we do `external_ids.get(report.id, [None])[0]` and this will always give us [] if no external id is there. hence trying to access the 0th element causes traceback. This commit fixes that by safely evaluating to `[None]`.
This update resolves an issue where the SBR tax report wizard would crash if an SBR certificate wasn't configured. The fix checks for the certificate's existence and displays a helpful message to the user, guiding them to the Accounting Settings. This ensures the report generation process remains stable and reliable.
Original PR description
In the SBR tax report wizard, the code previously attempted to access the `pem_certificate` attribute on a potentially empty recordset if no certificate was configured (see [here](https://github.com/odoo-dev/enterprise/commit/0b50021bdae54779396d75d3cddbd9eb42571553)). This resulted in an AttributeError before the validation check could trigger the intended RedirectWarning. This commit fixes the logic by: * Checking for the existence of the `cert_sudo` recordset immediately after retrieval. * Raising the RedirectWarning if the certificate record is missing, guiding the user to the Accounting Settings. * Accessing the certificate and private key content only after confirming the record exists. no-task
This update addresses a minor issue in the account reports module, specifically correcting a sign error for the 'cta' value. The change simplifies existing queries and functions, ensuring accurate reporting and data processing. This ensures consistent and reliable financial reporting.
Original PR description
Followup PR of odoo/enterprise#103529 * Simplification of some queries * Simplification of functions * Sign correction for cta value
This update addresses an issue where Coda bank statement files sometimes lacked transaction details, leading to empty payment reference fields in Odoo. This resulted in a 'No description' default being added to the statement line, which has now been corrected. This ensures accurate financial reporting.
Original PR description
It can happens that coda file with transaction have no communication or structure communication. This can cause problem since we will have an empty payment_ref for the statement line. This will add "No description" as a default value. task-6045138 Forward-Port-Of: odoo/enterprise#111300
This update resolves an issue preventing account return tours from functioning correctly across all Odoo localization modules. The fix addresses a missing tag that caused errors, specifically related to submitting actions, ensuring consistent functionality for users with different language settings.
Original PR description
Before, the account return tour was not running with every l10n installed du to a missing tags. This leads to errors that were not catched like missing super call on a submit action. Forward-Port-Of: odoo/enterprise#115290
This update resolves an issue where copying and pasting content from the blog post editor unexpectedly modified the original field. The fix adds a setting to the editor to prevent copying outside of the editable area, ensuring data integrity and preventing unwanted changes to the source records.
Original PR description
Problem: When copying the blog post title and pasting it elsewhere, editing the pasted content unexpectedly modifies the original field source. Cause: The copied HTML retains `data-oe-*` attributes, causing the editor to treat the pasted content as a field binding and propagate changes back to the original record. Solution: `contenteditable="true"` should be added on fields (`o_savable`) to prevent copying outside of savable area. Steps to Reproduce: - Copy title of blog post. - Paste it elsewhere in editable. - Edit the pasted text. - Observe the original field source also changes. opw-6105714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258880
This update resolves an issue where invoice transaction IDs in financial reports (FAIA export) didn't consistently match those in the general ledger. The fix ensures all transaction IDs are synchronized, improving the accuracy and reliability of financial data exports. This prevents potential discrepancies in reporting.
Original PR description
The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846
A bug in a test for the restaurant point-of-sale module caused order data to be incorrectly updated, leading to potential data inconsistencies. This fix addresses a timing issue within the test process, ensuring order information is accurately recorded and synchronized.
Original PR description
In the tour test_customer_alone_saved, the test was creating an order, then go on the ticket screen and then come back on the product screen to change the customer to go again on the ticket screen and come back on product screen to check that the customer did not changed. The problem was that when going to the ticket screen the first time, the order was synced with the server but the answer might come after the test changed the customer. When going the second time on the ticket screen, the order was changed with the information of the backend and the user was lost. This is all due to the test that are too fast. runbot-error: 238467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253587
This update simplifies the setup of financial accounts by reducing the complexity of Balance Sheet formulas. New equity and liability accounts have been added to the Balance Sheet, providing a more accurate and flexible reporting structure for Sri Lankan businesses. This change enhances the overall financial reporting capabilities within the Odoo Enterprise system.
Original PR description
Reduces Balance Sheet account code formulas from 3-digit to 2-digit prefixes to make the COA setup more flexible. New equity and liability lines are also added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/260920 task-6141758 Forward-Port-Of: odoo/enterprise#114768
This update resolves an issue where duplicating an employee would incorrectly copy their bank account information, leading to salary payments being routed to the same account for both employees. The fix ensures that the bank account is cleared during duplication, preventing this duplication and maintaining accurate payroll processing.
Original PR description
Steps: - Duplicate an employee. - Check that the bank account is copied. - Modify the bank account on the duplicated employee. - Verify the original employee’s bank account. Issue: - When duplicating an employee, the bank account was copied as well, causing both employees to use the same account. Updating it for one also changed it for the other, leading to both salaries being paid to the same account. Fix: - Set the 'bank_account_id' field to not be copied during duplication, ensuring the field is cleared for the duplicated employee. task-6093406 Forward-Port-Of: odoo/odoo#261505 Forward-Port-Of: odoo/odoo#259405
This update resolves a failing test related to WorldLine integration within our self-order point-of-sale system. The fix ensures that the test only runs if both necessary modules (`pos_self_order_iot` and `pos_iot_worldline`) are installed, preventing errors and improving test reliability.
Original PR description
To test WorldLine in self order, we need both `pos_self_order_iot` and `pos_iot_worldline`. We then skip the test if `pos_iot_worldline` isn't installed. Forward-Port-Of: odoo/enterprise#115282
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view. It now correctly displays the contact type in the user's preferred language, mirroring the translation seen in the Kanban view. This improves the user experience and ensures consistent data presentation.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/odoo#261592 Forward-Port-Of: odoo/odoo#257539
This update fixes an issue where contact types for related contacts were displayed in English within the contact list view, regardless of the user's language setting. The change ensures that contact types are now correctly translated to the user's preferred language, matching the behavior in the Kanban view. This improves the user experience for international users.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/enterprise#115331 Forward-Port-Of: odoo/enterprise#114786
This update fixes an issue where product URLs in multilingual websites incorrectly included the category path. Previously, the canonical URL wasn't properly handling language codes, leading to incorrect links. This change ensures that product URLs are correctly generated regardless of the website's language, improving SEO and user experience.
Original PR description
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to…
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to the shop in fr. 4- Open the category, then open the product. 5- Open console, and search for canonical. As you see, in the second language, the canonical address includes the category address which is wrong. If you visit in the default lang, the canonical correctly refers to the url without category. Cause: --- This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself. opw-6086206 Forward-Port-Of: odoo/odoo#258834
A minor bug preventing users from clocking in with the Blackbox POS was resolved. The fix corrects a typo that caused an error when generating receipt data, ensuring proper functionality for this key POS feature. This resolves a technical issue impacting POS operations.
Original PR description
There is a typo trying to assign the server version to `this` instead of the `data` object which is used for the receipt. This causes a `cannot set properties of undefined` error when trying to clock in with a blackbox Forward-Port-Of: odoo/enterprise#115098
This update fixes a minor visual issue where the IM status icon in the user menu was slightly misaligned. The change ensures the icon is centered within its container, creating a cleaner and more professional user interface. This improves the overall user experience.
Original PR description
**Current behavior before PR:** Since this https://github.com/odoo/odoo/pull/246182, the IM status icon in the user menu appears misaligned with its surrounding context, causing a slight visual offset. **Desired behavior after PR is merged:** This commit ensures that the IM status icon is properly aligned by centering it within its container. task-[6012657](https://www.odoo.com/odoo/project/1519/tasks/6012657) | Before | After | |--------|--------| | <img width="308" height="46" alt="image" src="https://github.com/user-attachments/assets/214083b2-5013-41ab-a02f-8f8d510b1ac5" /> | <img width="311" height="43" alt="image" src="https://github.com/user-attachments/assets/9a77718c-84d4-4be8-8cc4-a65516e957cd" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261503
This update fixes a technical issue that could cause the Odoo application to unexpectedly crash when multiple drag sequences were initiated. The fix ensures that the cancellation callback is available before the variable is assigned, preventing the crash in these specific, rare scenarios. This improves overall application stability.
Original PR description
### [FIX] web: fix crash when cancelling drag sequence Before this commit: drag sequences could be aborted by new drag sequences; the way this worked is that a new sequence would register its "cancel" callback in a global variable, and when another sequence is started, it calls that variable to cancel the previous one. The issue was that the variable was assigned too early; before the actual "cancel" callback was available. This means that in edge cases where 2 sequences would be triggered in less than (effectively) a resolved promise, the callback would not be available and a crash would occur. This commit moves the variable assignment *after* the "cancel" callback is made available, ensuring there is no crash. Runbot [243113](https://runbot.odoo.com/odoo/error/243113) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261345 Forward-Port-Of: odoo/odoo#260594
This update resolves a technical issue preventing invoices sent to Poland's KSeF system from being properly processed. The fix ensures that email and phone number fields are only included in the invoice XML if the buyer actually has that information, avoiding errors that caused rejection by the KSeF system. This improves invoice compatibility and reduces processing delays.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Create and send an invoice to KSeF where the buyer has no email or no phone number 3. KSeF rejects the invoice with error code 450 (semantic verification error) This happens because `Email` and `Telefon` elements are always rendered inside `DaneKontaktowe`, even when their values are empty, producing invalid empty tags. After this commit: Add `t-if="buyer.email"` and `t-if="buyer.phone"` guards on each field so that `Email` and `Telefon` are only rendered when a value is present. opw-6124187 Forward-Port-Of: odoo/odoo#259646
This update fixes an issue where power buttons within the Knowledge editor were being hidden due to incorrect boundary calculations. The change ensures the editor accurately accounts for margins, guaranteeing that power buttons remain visible for all users. This improves the user experience and functionality of the Knowledge editor.
Original PR description
**Current behavior before PR:** - Power buttons in Knowledge were hidden incorrectly because `editableRect.width` was used as the boundary. Since the editable area has margins applied, this width no longer reflects the actual boundary, causing buttons to be hidden. **Desired behavior after PR is merged:** - Use `editableRect.right + referenceRect.left` instead of `editableRect.width` to determine the correct boundary, ensuring power buttons remain visible in when editable area has margin applied to it. task-6102944 Forward-Port-Of: odoo/odoo#259532
This update ensures that IoT boxes send the correct data to the Odoo database. A missing field was corrected in the 'subscribe' message, allowing the database to properly process information from the IoT devices. This improves the reliability of data updates from our IoT integrations.
Original PR description
In odoo/odoo#260380, a new required field was added to the websocket `subscribe` message, `check_outdated`. This commit adds this field to the subscribe message sent from the IoT box so that the DB can process it successfully. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261687
This update corrects a potential error in the account reports module where custom modules could cause conflicts when querying for the 'state' field. By using aliases for column references, the system now correctly identifies and resolves ambiguous column names, ensuring accurate reporting across all client configurations.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341
This update fixes a problem where payment reminder emails for subscriptions were missing the subscription's end date. The change ensures that all payment reminder emails, regardless of how they're generated (automated or manually through the email composer), accurately display the subscription's closing date. This improves the clarity and accuracy of communication with customers.
Original PR description
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In…
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing. ### Steps to reproduce the issue: 1. Install subscription and go to that app 2. Open one subscription 3. Send message > Load template: "Subscription: Payment Reminder" 4. Sentence is incomplete: missing end date of the subscription ### Cause of the issue: The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template. ### Reason to introduce the fix: The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer. opw-6031613 Forward-Port-Of: odoo/enterprise#114839 Forward-Port-Of: odoo/enterprise#111801
A minor technical issue was resolved where the wrong function was being utilized within the VoIP sales module. This fix ensures accurate processing of VoIP calls related to sales transactions. The change improves the stability and reliability of the sales process.
Original PR description
Shh! We used the wrong function. Forward-Port-Of: odoo/enterprise#114869