Tuesday, April 28, 2026
172 changes
35 changes
New functionality added to Odoo
This pull request updates the translation files for the Odoo Enterprise SaaS version. Specifically, it adds the translation for the 'documents_project_sign' feature, ensuring consistent and accurate localization across all supported languages. This improves the user experience for international customers.
Original PR description
- Added `documents_project_sign` Forward-Port-Of: odoo/enterprise#115426
Enhancements to existing features
This update expands access to return type configuration settings within the Odoo Enterprise accounting reports module. Previously, these settings were limited to debug mode, hindering users' ability to properly manage return types. Now, these settings are available for authorized users, streamlining the reporting process.
Original PR description
Before, the menu return types in configuration was only available in debug mode. Now it is available for the group `account.group_account_readonly` task-5912751 Forward-Port-Of: odoo/enterprise#114830
Resolved issues and error corrections
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
Features or functions removed from Odoo
This pull request updates the .weblate.json files to reflect changes in the Vietnamese localization (I18N) for Odoo. Specifically, a new module, `l10n_vn_edi_viettel_pos`, has been added, and the `project_mrp_sale` module has been removed as all associated translations were deleted.
Original PR description
- Added `l10n_vn_edi_viettel_pos` - Removed `project_mrp_sale` (no terms left) Forward-Port-Of: odoo/odoo#261555
7 changes
New functionality added to Odoo
This pull request updates the localization files (.weblate.json) to support new features and languages. Specifically, it removes support for the 'l10n_account_withholding_tax_pos' module and adds translations for the 'l10n_vn_edi_viettel_pos' and 'pos_cashdro' modules, expanding our support for Vietnamese accounting and point-of-sale functionality.
Original PR description
- Removed `l10n_account_withholding_tax_pos` - Added `l10n_vn_edi_viettel_pos` - Added `pos_cashdro` Forward-Port-Of: odoo/odoo#261555
7 changes
New functionality added to Odoo
This pull request updates the localization files for Odoo, specifically adding support for Vietnamese accounting and point-of-sale (POS) features. The changes include the addition of new terms related to Viettel POS and a new 'pos_cashdro' module, ensuring accurate translations for Vietnamese users.
Original PR description
- Added `l10n_vn_edi_viettel_pos` - Removed `project_mrp_sale` (no terms left) Forward-Port-Of: odoo/odoo#261555
2 changes
New functionality added to Odoo
This update adds the ability to export General Ledger reports as CSV files. This allows users to easily download and analyze their financial data for reporting and record-keeping purposes. This enhancement improves data accessibility and simplifies the process of extracting financial information.
Original PR description
task-5734354 Forward-Port-Of: odoo/enterprise#111776 Forward-Port-Of: odoo/enterprise#107638
2 changes
Resolved issues and error corrections
This update resolves an issue where a misleading 'Message posted' notification appeared when users discarded the full composer after replying to messages. The change ensures notifications are now only triggered when a message is actually sent, improving the clarity and accuracy of message delivery notifications within the Discuss inbox.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When replying to messages from the History (Inbox) view, opening the full composer and…
5 changes
Resolved issues and error corrections
This update fixes a minor display issue in the Helpdesk dashboard, ensuring that the 7-day average customer rating is shown as a score out of 5 instead of a percentage. This provides a clearer and more intuitive understanding of agent performance for users.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#115176 Forward-Port-Of: odoo/enterprise#109804
8 changes
New functionality added to Odoo
This pull request adds new language translations for two Odoo modules: `documents_project_sign` and `l10n_eg_iot`. These updates improve the software's support for different languages, ensuring a better user experience for international customers and users.
Original PR description
- Added `documents_project_sign` - Added `l10n_eg_iot` Related: https://github.com/odoo/odoo/pull/261628
4 changes
Resolved issues and error corrections
This update stops unnecessary invitation emails from being sent when you add attendees to events that have already passed. Previously, the system would send invitations even for past events, which was a minor annoyance. This change ensures a cleaner and more efficient event management experience.
Original PR description
Backport of fix in 19.0 (https://github.com/odoo/odoo/pull/259844) Prevents invitations to be triggered when adding new attendees to an event in the past. OPW-6125052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261517 Forward-Port-Of: odoo/odoo#260050
2 changes
Resolved issues and error corrections
A technical update to the Odoo LDAP authentication system has been resolved. The original unit test was causing database issues and has been replaced with a simpler approach using an `HttpCase`. This fix prepares the unit test class for future improvements and bug fixes related to LDAP authentication.
Original PR description
The unit test is tagged `-standard` and `database_breaking` because it was leaving left overs in the database. Using an `HttpCase` over a `BaseCase` solves that issue in addition to make the code way simpler. We want to resurrect this unit test class because we plan to add another unit test in that class for a bug fix.
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
This pull request updates the Odoo Enterprise localization files to include support for the 'l10n_eg_iot' module. This addition expands Odoo's language capabilities to accommodate the specific needs of the Egyptian IoT market, ensuring accurate and localized translations.
Original PR description
- Added `l10n_eg_iot` Forward-Port-Of: odoo/enterprise#115425
Resolved issues and error corrections
A recent update caused newly added overtime lines on attendance records to disappear. This fix disables the ability to add new overtime lines, resolving the synchronization problem and preventing data loss. This ensures accurate work entry tracking.
Original PR description
Steps to reproduce: - On an attendance with overtime, click the "Add a line" button and add a new overtime line - Refresh the page - The newly added line has disappeared and navigating to work entries causes a traceback How it was fixed: Disabled the ability to add a new overtime line. Task ID: 5899657 Forward-Port-Of: odoo/odoo#261224 Forward-Port-Of: odoo/odoo#248431
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 and functional for all users.
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 resolves a potential error in the account reports module where clients with custom modules could experience conflicts when querying standard 'state' fields. By explicitly using column aliases in queries, this fix ensures data integrity and prevents ambiguous column references, improving report accuracy.
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 recent issue where users needed to manually pair their Bluetooth devices with the IoT Box. The fix resolves a technical problem where the device was forcibly disconnecting Bluetooth connections at startup. Now, supported devices should automatically connect when in range, improving the user experience.
Original PR description
According to the IoT Box documentation written in 10/2019, supported Bluetooth devices should connect automatically whenever they are in range of the IoT Box: https://github.com/odoo/documentation/commit/16f2f26f8ae6d9040195c854da337e0dcbbff955#diff-b5974750d9a7f12db80e4922399a7cacd26228dec979ca0fbb504faac386efc8R27 This behavior had broken at some point, requiring manual pairing via bluetoothctl on the IoT Box to establish a connection. Root causes identified and fixed: - The interface was forcibly disconnecting all already-connected BLE devices at startup, kicking them mid-GATT handshake - No BlueZ pairing agent was registered, causing AuthenticationFailed during the pairing negotiation Automatic connection on proximity is now restored. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the timesheet assistant view more user-friendly by implementing small adjustments for better clarity. These changes enhance the overall experience for users managing their timesheets within the Odoo Enterprise system. The update focuses on improving usability and streamlining workflows.
Original PR description
Improve the assistant view with small adjustments to enhance clarity and user‑friendliness. Forward-Port-Of: odoo/enterprise#114339
This pull request updates the .weblate.json files to include support for two new languages: ‘documents_project_sign’ and ‘l10n_eg_iot’. These additions expand Odoo Enterprise's localization capabilities, allowing us to serve a wider range of international customers and support new markets.
Original PR description
- Added `documents_project_sign` - Added `l10n_eg_iot` Forward-Port-Of: odoo/enterprise#115424
Resolved issues and error corrections
This update fixes a technical issue in the l10n_co_dian module that caused incorrect string comparisons. The change ensures accurate data processing within the Dian tax reporting system, preventing potential errors and ensuring compliance. This resolves a previously identified bug impacting the functionality of the module.
Original PR description
Issue: commit 780b12ca7e2525bfa86f00d232fa9f186c914a85 introduced incorrect string comparison opw-6077050 Forward-Port-Of: odoo/enterprise#115354
This update reverts changes made by Weblate to several Odoo modules, which were incorrectly applied. This ensures the correct functionality of these modules is restored. The reversion addresses an internal issue with Weblate's automated changes.
Original PR description
This reverts part of commit 685f39aa747097b3a2352ebe2935da77b340b52f. For some reason Weblate reverted changes to unrelated files. We revert them back here.
This update fixes an issue where power buttons in the Knowledge editor were being hidden due to incorrect boundary calculations. The change ensures that buttons remain visible even with margins applied to the editable area, improving the user experience.
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 corrects a potential error in the account reporting module that could occur when clients use custom fields with the same name as standard Odoo fields. The fix ensures that column references are clearly defined, preventing conflicts and ensuring accurate report generation. This improves data reliability for our clients.
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 an issue where payment methods weren't correctly displayed for branch companies within Odoo. Now, when working with a branch company, the 'Payment Method' field in the partner and account move forms will consistently show available methods from the parent company, ensuring accurate financial processing.
Original PR description
**Steps to reproduce:** - Install Contacts and Accounting - Create a branch company - Switch to the branch company **Issue:** In the partner form, "Payment Method" field doesn't propose the methods coming from the parent company. Same issue on the account move form. However, in the payment wizard opened from an invoice, the payment methods from the parent company are available. The behavior should be consistent. The payment methods from the parent company should be available from a branch company opw-6001573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260168
Resolved issues and error corrections
This update corrects a potential error in the account reports module where duplicate 'state' field names (from custom modules) could cause database conflicts. The fix ensures that column references are explicitly aliased, preventing ambiguous column errors and ensuring accurate report generation. This improves stability and reliability for our clients.
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
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When replying to messages from the History (Inbox) view, opening the full composer and discarding it could incorrectly trigger a toast notification indicating that a message was posted. This behavior is misleading, as no message is actually sent when the composer is discarded. **Current behavior before PR:** ---------------------------------------------- - Replying to a message from History opens the full composer - Discarding the full composer closes the dialog normally - A “Message posted” toast is shown even though no message was sent - Notification logic depends on dialog close behavior, leading to incorrect triggers **Desired behavior after PR is merged:** ---------------------------------------------- - Discarding the full composer does not show any notification - Notifications are only shown when a message is actually sent Task-5431682 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in how emission factors are converted within the ESG module. The previous process resulted in incorrect calculations, particularly when using kilograms as the unit. This change ensures accurate reporting of emissions based on the chosen factors.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, only in the Kanban view. The change ensures that contact types are consistently displayed in the user's preferred language across all views, improving user experience and data clarity. This was achieved by updating the field used to display contact information in the list view.
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 resolves an issue where testing custom Sign app configurations caused data conflicts. By creating unique role records for demo templates 2-6, the system now avoids overwriting configurations and provides a more accurate testing environment. This ensures consistent and reliable testing of Sign app features.
Original PR description
Before this commit, all demo templates in the Sign app shared the same global `sign.item.role` record (`sign_item_role_default`). When testing custom server actions or automations that attach configurations to a specific role, testing with demo data caused silent overrides. Modifying the automation for one demo template would overwrite the shared role record and break the automation for all other demo templates. This commit introduces unique `sign.item.role` records for demo templates 2 through 6. Template 1 retains the default role. This prevents data collisions during testing and better reflects a real-world database structure where different documents often utilize distinct roles. Task: 6128909
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 and more reliable 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#114927 Forward-Port-Of: odoo/enterprise#111957
Code cleanup and technical improvements
This update enhances the testing environment for Odoo's Web Studio module. Specifically, it allows for a dedicated 'registry test mode' context, enabling developers to more reliably test and debug features within this area. This change improves the stability and quality of Web Studio development.
Original PR description
https://github.com/odoo/odoo/pull/259832
Resolved issues and error corrections
This update fixes a bug that prevented users from changing the state of tax returns within the accounting dashboard. Previously, attempting to use an invalid state would cause the page to crash. This change ensures the system handles state transitions correctly, improving the reliability of tax return management.
Original PR description
Before this commit, if you were to change the states_workflow to from a some that had an option, such as submitted, to something that did not contain a state that an account_return does not have, you would crash when trying to load the page. To get to this page go to the accounting dashboard and click on the tax returns option. To change the states_workflow change go to accounting -> configuration -> return types and change the states variable. opw-6107995
This update resolves an issue where portal users were incorrectly seeing the 'View Timesheets' button, even when they lacked the necessary permissions. The fix utilizes a new helper method to accurately control button visibility, ensuring users only see options they are authorized to access. This improves the user experience and prevents confusion.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115193 Forward-Port-Of: odoo/enterprise#113481
This update corrects a potential error in the account reports module where custom modules could cause conflicts when referencing the 'state' column. By explicitly using column aliases, the system now correctly identifies and resolves ambiguous column references, ensuring reports run smoothly 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 ensures that when a company is quickly created through the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. The fix also includes a minor typo correction within the equity views.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343
This update corrects a technical issue where styling applied to a list view was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list view, improving the visual consistency of reports. This resolves a minor cosmetic problem.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685
This update resolves an issue where time off allocations couldn't be deleted after a payslip was validated. The fix adjusts the system to recognize that time off created *after* payslip validation can be safely deleted, removing a previous restriction. This improves usability for HR and payroll teams.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990This update resolves an issue where payroll document validation incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a company-dependent field with a stored employee flag, ensuring accurate validation during background tasks like payroll generation. This prevents errors and ensures proper document access.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti)
This update resolves an issue where a singleton error occurred when Peppol was enabled but then disabled in the settings. The change ensures the system correctly checks if a company is registered with Peppol before attempting to send invoices, improving stability and preventing unexpected errors.
Original PR description
Steps to reproduce: **Note: This does not occur in Peppol demo mode** 1. Install the Peppol module and enable it in Settings 2. Create a portal user, then go to the 'Accounting' tab in their contact…
Steps to reproduce: **Note: This does not occur in Peppol demo mode** 1. Install the Peppol module and enable it in Settings 2. Create a portal user, then go to the 'Accounting' tab in their contact record 3. Under Customer Invoices, set the following: a. Invoice Sending -> By Peppol b. eInvoice Format -> Peppol Bis 3.0 c. Belgian VAT -> A valid VAT 4. Click 'Verify' under 'Peppol Status' and this should change `peppol_verification_status` to `valid` 5. Disable Peppol in Settings 6. Log in as the created user and make a purchase on the web shop 7. Observe that no sale order confirmation email is sent, and a singleton error is logged. When Peppol is installed, but disabled, the `account_peppol_edi_user` field is not set (or gets unset) on the company, which can lead to a singleton error when trying to send an invoice via Peppol. This can occur if Peppol was previously enabled and there were `res.partner` records with Peppol information that was validated. The database checks this after E-Commerce transactions and, if there is no `invoice_sending_method` set on the `res.partner` record, it defaults to Peppol, even if it is disabled, which can cause the singleton error. This change will ensure that we check to see if the company has registered with Peppol before using it to send invoices. [Ticket link](https://www.odoo.com/odoo/project.task/5890740) opw-5890740
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that the total balance accurately reflects the sum of all invoices, resolving a discrepancy between the ledger's summary and individual transactions. This improves the accuracy of financial reporting.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305
This update fixes an issue where test tags containing special characters like brackets were not being parsed correctly, leading to errors. The changes enhance the parser's ability to handle complex tag structures, ensuring accurate test execution and stability.
Original PR description
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in…
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]` The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets This commits fixes this two ways: Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]` Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example `.test_method[test, with brackets\], and backslash\` will work the same way. So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced. Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests. A followup pr will introduce the params to the canonical tag, and escape it as needed
Documentation and clarification updates
This pull request addresses a legal requirement by signing a Contributor License Agreement (CLA) for contributions from BMyA and Blancomartin. This ensures compliance with Odoo's open-source licensing and allows these integrations to proceed. The changes reflect the formal acceptance of these contributions.
Original PR description
New contributors from BMyA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr