Daily updates from Odoo
Monday, April 27, 2026
247 changes
13 changes
Resolved issues and error corrections
This update fixes an issue where invoices in the l10n_mx module were incorrectly rounding tax amounts. The change reverts to the standard mixed rounding mode, ensuring accurate tax calculations on invoices with both 16% and 53% taxes. This improves financial reporting accuracy for Mexican businesses using the Odoo system.
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_mx. 2. Change the included in price settings to 'Tax included' for a 16% tax and a 53% tax. 3. Create a invoice with a product with a unit price of 360, add the 53% tax and then the 16% tax. 4. Notice the total of the invoice is 360.01 instead of 360. The issue was discussed with (las), l10n_mx_edi should no longer require to override the rounding mode for taxes. opw-5963855 Forward-Port-Of: odoo/odoo#255574
This update corrects a bug that was disrupting tests within the l10n_mx_edi module, specifically related to rounding calculations for Mexican tax invoices. The change reverted the rounding mode to 'mixed,' resolving the test failure and ensuring accurate tax reporting. This fix maintains the functionality of the Mexican tax processing features.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114321 Forward-Port-Of: odoo/enterprise#114081
This update fixes a minor display issue in the Helpdesk app's performance dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, the rating is displayed as a score out of 5, providing a clearer and more intuitive understanding of performance.
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#109804
This update corrects a bug where users received duplicate notifications when submitting the email reminder form for event talks. The fix ensures that notifications are displayed correctly and prevents unwanted redirects to talk pages, improving the user experience for event registration.
Original PR description
This PR fixes the email reminder form with multiple commits: - Commit 1 fixes the notifications displayed when the email form is submitted as the messages of those notifications are redundant. - Commit 2 inserts the form inside the HTML body instead of the interaction's HTML since the surrounding HTML of this last one may cause display issues as with the <a> tag redirecting the users on the talks page when they click on the form which should not happen. Task-5347538 Forward-Port-Of: odoo/odoo#251468
This update resolves a crash that occurred when assigning recruiters in the Odoo Recruitment Kanban view. The issue stemmed from an unnecessary cache parameter in avatar image URLs, which caused errors due to missing data. Removing this parameter ensures stable operation and correct avatar display.
Original PR description
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The…
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The ?unique= cache related parameter was added to the avatar image URL in the autoCompleteItem slot of KanbanMany2OneAvatarEmployeeField. This parameter relies on write_date being available on the autocomplete suggestion record. However, web_name_search only returns id and display_name, so write_date is undefined on autocomplete suggestion records, causing a crash when accessing autoCompleteItemScope.record.data.write_date.ts. **Bug Solution:** Remove the ?unique= parameter from the avatar image URL in the autoCompleteItem slot, reverting it to its original form. Cache is unnecessary for autocomplete suggestion avatars as they are only visible for the duration of the dropdown interaction. **Task:** 6092768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261040
This update resolves an issue where CFDI (Mexican tax) generation for payslips failed due to discrepancies in decimal precision. The fix ensures payroll calculations are rounded to the required 2 decimal places, aligning with CFDI formatting standards and preventing errors. This improves the reliability of payroll reporting for Mexican businesses.
Original PR description
Currently, if the company is configured with a 4-decimal currency, the CFDI generation for payslips might fail with NOM111 and CFDI40119 errors. This occurs because the calculation of totals and subtotals uses the raw unrounded floats, which can cause penny differences when the XML template formats the individual lines to 2 decimal places. This commit forces all payroll concept amounts to be explicitly rounded to 2 decimal places before accumulating the totals. This ensures that the sum of the formatted XML nodes precisely matches the total and subtotal values reported in the CFDI. Accounting might require a higher decimal precision for the company's currency (e.g., 4 decimals for inventory). However, payroll CFDI stamping strictly requires 2 decimal precision. This fix isolates the payroll CFDI calculations from the company's currency settings. Forward-Port-Of: odoo/enterprise#114936
This update resolves a scrollbar flickering issue in the Gantt chart, ensuring a smoother and more reliable user experience. The fix corrects a calculation error that caused grid elements to intermittently disappear, and now utilizes a more robust approach to accommodate progress bars and adjust row heights for different screen sizes.
Original PR description
This commit fixes an issue where the scrollbar would flicker uncontrollably at certain scroll positions. This occurred because grid elements were constantly appearing and disappearing at the edge of the viewport on every animation frame. The root cause was a discrepancy in row height computations introduced in https://github.com/odoo/enterprise/pull/101732. The virtual grid was receiving row heights 8px smaller than the actually rendered rows, leading to miscalculations in visibility. To fix this, the problematic 8px change is reverted. The original design requirement (fitting the progress bar) is instead fulfilled by explicitly adding height to group rows, and providing additional space to regular rows on smaller screens.
A minor fix was implemented to correct a naming inconsistency within the Odoo website code. The resource name was updated, but a subsequent addition to the website functionality didn't reflect this change. This ensures consistent resource naming for improved website stability.
Original PR description
The resource `on_replaced_media_handlers` was renamed `on_media_replaced_handlers` with [b966432], but commit [909341c] added a use case without updating the name. [b966432]: https://github.com/odoo/odoo/commit/b966432e85a7e19c0e4e4bfbb34f673b64fc84e6 [909341c]: https://github.com/odoo/odoo/commit/909341c3ae601a83358a4ed4a0a4b6965bfef332
This update corrects a previous issue where certain users without attendance access were unable to view attendance records with overtime. The fix involved adding specific user groups to the 'Overtime Details' section, ensuring only authorized personnel can access this data. This improves data security and usability for all users.
Original PR description
Steps to Reproduce: - Log in as user which has no access of attendance - Try to open attendance record with overtime Issue: - As users below Self Attendance edit and hr administrator does not have access to rule_ids Fix: - Added groups on 'Overtime Details' section as other user does not have access to read. task-5886324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250567
This update resolves an issue where the holiday selection process was inaccurate. The change corrects a domain filter used to retrieve holiday data, ensuring employees are correctly identified for holiday entitlements. This improves the reliability of holiday calculations and reporting.
Original PR description
Forward-Port-Of: odoo/odoo#261250
This update fixes a missing field in the Czech Republic (CZ) version of Odoo. The 'City' field was absent from contact forms, preventing accurate address data entry for CZ customers. This change ensures compliance with Czech tax regulations and improves the accuracy of customer information.
Original PR description
Steps to reproduce: 1- Install Contacts and l10n_cz 2- Switch to CZ company 3- Open any contact Issue: `City` field is missing in address section Expected behavior: Should have the `City` field opw-6123084 Forward-Port-Of: odoo/odoo#259433
This update fixes an issue where increasing the quantity of a service product on a sales order incorrectly generated a purchase order with an inflated quantity. The fix ensures the quantity is consistently calculated in the sales order's unit of measure, preventing double-counting and inaccurate purchase order generation. This improves the reliability of sales order processing for service products.
Original PR description
Steps to reproduce the bug: - Create a service product "P1": - In the Purchase tab: - Vendor: Azure Interior - Subcontract Service: True - UoM: dozen - Purchase UoM: unit - Create a sales order with…
Steps to reproduce the bug:
- Create a service product "P1":
- In the Purchase tab:
- Vendor: Azure Interior
- Subcontract Service: True
- UoM: dozen
- Purchase UoM: unit
- Create a sales order with 1 dozen of P1
- Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
- Update the quantity from 1 to 2 dozen
Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186
Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178
opw-6049106
Forward-Port-Of: odoo/odoo#261199
Forward-Port-Of: odoo/odoo#255478This update resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause errors and data inconsistencies. The fix ensures accurate account updates by properly managing analytic line links during editing, preventing orphaned analytic lines and improving the bank reconciliation process.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
14 changes
Resolved issues and error corrections
This update resolves a problem where portal users creating tickets via email triggered a system crash due to incorrect access permissions to employee calendars. The fix ensures that the system correctly handles multi-company user scenarios, preventing access errors and allowing ticket creation to proceed smoothly. This improves the reliability of the Helpdesk portal.
Original PR description
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the…
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment. This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read. If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated. The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation. Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there. Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender. A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds. Steps to Reproduce: 1. Install Helpdesk, Employees, and enable multi-company 2. Create two companies (e.g., Company A and Company B) 3. Create one internal user (User X) with access to both companies 4. Create two employees linked to the same user: - Employee 1 in Company A - Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee. 5. Create a Helpdesk team in Company A 6. Add Agent X as a team member 7. Enable automatic assignment 8. Configure an email alias for the helpdesk team 9. Create a portal user 10. Send an email from the portal user to the alias Related Ticket: opw-6035099 Forward-Port-Of: odoo/odoo#257720
This update resolves an issue where portal email auto-assignment was failing due to permission problems accessing employee calendars across different companies. The fix ensures the system correctly accesses calendar data, allowing ticket assignments to proceed smoothly. This improves the reliability of the helpdesk system for portal users.
Original PR description
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the…
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment. This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read. If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated. The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation. Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there. Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender. A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds. Steps to Reproduce: 1. Install Helpdesk, Employees, and enable multi-company 2. Create two companies (e.g., Company A and Company B) 3. Create one internal user (User X) with access to both companies 4. Create two employees linked to the same user: - Employee 1 in Company A - Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee. 5. Create a Helpdesk team in Company A 6. Add Agent X as a team member 7. Enable automatic assignment 8. Configure an email alias for the helpdesk team 9. Create a portal user 10. Send an email from the portal user to the alias Related Ticket: opw-6035099 Forward-Port-Of: odoo/enterprise#114699 Forward-Port-Of: odoo/enterprise#113047
This update fixes an issue where the 'Configuration' menu was hidden for users with 'All Timesheets' access, preventing them from managing billing targets. The fix ensures that menu visibility updates correctly after changes to billing settings, providing consistent access for all approvers. This improves usability and accuracy of timesheet reporting.
Original PR description
Steps to reproduce Bug 1: 1. Login as a user with "All Timesheets" (Approver) access. 2. Disable the "Timesheet Assistant" feature for this user. 3. Ensure "Billing Rate Indicators" is enabled in…
Steps to reproduce Bug 1:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Timesheet Assistant" feature for this user.
3. Ensure "Billing Rate Indicators" is enabled in settings.
Steps to reproduce Bug 2:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Billing Rate Indicators" setting in company settings.
3. Ensure "Timesheet Assistant" is enabled in settings.
Steps to reproduce Bug 3:
1. Only install 'sale_timesheet_enterprise'.
2. Go to Timesheets > Configuration > Settings.
3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.
Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.
Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.
Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
- Hide all billing-related menus for all users when the feature is disabled.
- Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.
task-5428010
Forward-Port-Of: odoo/enterprise#106464This update fixes inaccuracies in tax calculations for Argentina (l10n_ar) by modernizing the underlying tax calculation methods. The changes ensure more accurate VAT calculations and prepare the system for future adjustments to Argentina's specific tax regulations. This improves the reliability of financial reporting for Argentinian businesses.
Original PR description
This commit refactors the tax amount calculations on the `_get_vat` and `_l10n_ar_get_amounts` method so that it uses the tax computation engine helpers properly, to prepare for any future fixes done on how Argentina tax calculations differs from all other localizations. This replaces all move line queries with the proper `base_line` calculation, with the proper aggregating methods. related-enterprise-PR: https://github.com/odoo/enterprise/pull/92639 task-4891206 Forward-Port-Of: odoo/odoo#260171 Forward-Port-Of: odoo/odoo#223393
This update fixes inaccuracies in how tax amounts are calculated for Arabic VAT transactions within the Odoo Enterprise system. By utilizing the system's tax computation engine, the changes ensure more precise and reliable tax calculations, particularly for sales and invoices. This improves financial reporting accuracy.
Original PR description
- Rewrite all tax amounts calculations on `_get_tributes` and `_get_line_details` to properly use the tax computation engine helpers (`base_line`, and aggregating methods) - Ensure that all final amounts from the calculation are formatted with `float_repr` with appropriate precision. related-community-PR: https://github.com/odoo/odoo/pull/223393 task-4891206 Forward-Port-Of: odoo/enterprise#114379 Forward-Port-Of: odoo/enterprise#92639
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, appearing only in English. The change ensures that contact types are correctly translated to the user's preferred language, matching the translation seen 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/odoo#261206 Forward-Port-Of: odoo/odoo#257539
This update fixes an issue where the contact type associated with 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 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#115027 Forward-Port-Of: odoo/enterprise#114786
This update corrects a minor issue where holiday approvals were sometimes processed multiple times when using multi-allocation settings. The fix removes a redundant approval step and streamlines the process, ensuring holiday requests are handled correctly and efficiently. This improves the reliability of the holiday management feature.
Original PR description
Cause: In this commit https://github.com/odoo/odoo/pull/258520/changes/1b6f3a1335302ca029ab62a25c7bcff0953b99be we accidently added a line to approve allocation which might already be approved. Fix: Remove this line and move the accrual filter right before the first action approve opw-5888023 Forward-Port-Of: odoo/odoo#261074 Forward-Port-Of: odoo/odoo#260158
This update resolves an issue where the 'is_company' field in several Latin American localization modules (AR, BR, EC) was incorrectly calculated. The change ensures accurate identification of companies, improving data integrity and functionality for users in these regions. This fix primarily impacts the l10n_latam_base module and related localization modules.
Original PR description
*: l10n_{ar,br,ec}
In 19.1 we changed the `is_company` field to a computed
stored field.
This change needs to be reflected correctly in many localisations
where the default computed value is too naive.
This commit is introducing a generic fix for most l10n that depends
on the module `l10n_latam_base`.
Improve the test coverage for the computation.
Note: This is not strictly necessary for this fix
on Enterprise side, since we removed the invisibility
condition but in case of some customization relying
on it it's safer if we can deduce it correctly.
Enterprise: https://github.com/odoo/enterprise/pull/114403
Related: https://github.com/odoo/odoo/pull/211043
task-6141307
Forward-Port-Of: odoo/odoo#260224This update corrects a visibility problem with Peruvian identifiers (like driver licenses) that arose after a change in the Odoo 19.1 system. The fix removes a restrictive condition, ensuring these identifiers are always displayed correctly. This ensures accurate reporting and data management for Peruvian businesses.
Original PR description
In 19.1 we changed the `is_company` field to a computed stored field. That change broke the visibility for some Peruvian identifiers (driver license, etc). This commit removes the visibility condition on those fields to be displayed all the time. Note: we still add the correct compute on related Community commit for sake of correctness and completeness. Community: https://github.com/odoo/odoo/pull/260224 Related: https://github.com/odoo/odoo/pull/211043 task-6141307 Forward-Port-Of: odoo/enterprise#114403
This pull request addresses a small 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 a routine maintenance update.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
This update fixes a problem where Wise payments were failing due to slight differences in recipient information (like spacing or capitalization) between Odoo and Wise. The change now uses only financial details like account numbers and routing numbers for matching, ensuring accurate payments and preventing duplicate recipient creation. This improves the reliability of direct deposit payments.
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#113234
This update fixes a bug that prevented links within 'Button' snippets in the website builder from being translated. Previously, these links were not properly tagged for translation, making them inaccessible. Now, dropped button links are correctly marked 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 preventing AI chat functionality on Safari iOS devices. The fix addresses a compatibility problem with older Safari versions that don't fully support a key streaming technology. By switching to a more basic reading method, the AI chat now works reliably on Safari, ensuring a smooth user experience for all customers.
Original PR description
Steps: - Install ai - Open ai chat - Try to send a message - Traceback The AI chat was failing on iOS with a traceback when trying to process the stream response. Even though MDN suggests…
Steps: - Install ai - Open ai chat - Try to send a message - Traceback The AI chat was failing on iOS with a traceback when trying to process the stream response. Even though MDN suggests compatibility, Safari (WebKit) versions prior to 26.4 do not implement the AsyncIterator protocol on ReadableStream. This makes `for await (const chunk of response.body)` throw a TypeError as `[Symbol.asyncIterator]` is undefined. https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream This commit replaces the async iteration with a manual reader loop (`getReader().read()`). This is the low-level primitive supported by all versions of Safari and ensures the stream is properly consumed and unlocked even if the connection is interrupted. Steps to reproduce: 1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4). 2. Send a message. 3. The response triggers a JS error. ```js Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...') ``` opw-6054307 Forward-Port-Of: odoo/enterprise#113926
1 change
Resolved issues and error corrections
This update corrects a bug where purchase order quantities were incorrectly calculated when products had different unit measurements. The fix ensures that quantities are accurately reflected in the purchase order, preventing invoicing errors. Additionally, a related issue with error messages has been resolved for improved reliability.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45 Steps to reproduce: - Create a new database with only the Purchase module installed - Enable the "Units…
Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45 Steps to reproduce: - Create a new database with only the Purchase module installed - Enable the "Units of Measure & Packagings" option - Create a storable product "P1" with the following vendor pricelist: - Vendor: Azure Interior (1 pack of 6 for $10) - Create a purchase order: - Vendor: Azure Interior - Quantity: 3 packs of 6 of P1 - Confirm the PO - Click the Receive button (available without the Stock module since v19.1) Problem: 1:/ Expected behavior: qty_received = 3 (in purchase UoM: packs of 6) Actual behavior: qty_received = 18 (product UoM: units) `product_uom_qty` (expressed in the product's UoM) was used instead of `product_qty` (expressed in the purchase line's UoM) when computing `qty_received`. Since `qty_received` feeds into `quantity_to_invoice`, this caused the invoicing autocomplete to suggest 18 packs of 6 instead of the correct 3 packs of 6. 2:/ The parameter `invalid_targets` was not properly passed to the translation function in the error message, causing a traceback when trying to receive a PO in an invalid state. opw-6080527
1 change
Resolved issues and error corrections
This pull request addresses a minor typographical error within the marketing automation test suite. The fix ensures the tests run smoothly and accurately, maintaining the stability of the system. This change does not impact any business functionality.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
3 changes
Resolved issues and error corrections
This update prevents portal users from seeing the 'View Timesheets' button on invoices when they lack the necessary permissions. Previously, the button appeared based on the presence of timesheets linked to the sale order, even if the user didn't have access. This change ensures users only see timesheets they are authorized to view, improving data security and user experience.
Original PR description
sale: add sale order specific hook to extend page values ------ Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values sale_timesheet: hide 'View Timesheets'…
sale: add sale order specific hook to extend page values
------
Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values
sale_timesheet: hide 'View Timesheets' button for users without access
-------
Steps to Reproduce:
-----------------
- Create a product with the invoice policy set to Based on Timesheets
- Enable Project and Tasks on the order.
- Create and confirm a sale order using a portal user.
- Log timesheets on the related task.
- Create an invoice from the sale order.
- Log in as the portal user and open the invoice.
- Click the 'View Timesheets' button.
Issue:
-------------
The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.
Root Cause:
------------
The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
Fix:
-----------
We replaced the timesheet_count check with a check that verifies whether the user actually has access to any of the related timesheets.
task-4745519
Forward-Port-Of: odoo/odoo#261079
Forward-Port-Of: odoo/odoo#209552This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix utilizes a new helper method to accurately control button visibility based on user access, ensuring a better user experience.
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#114915 Forward-Port-Of: odoo/enterprise#113481
This update corrects a typographical error within the marketing automation test suite. The fix ensures the tests run smoothly and reliably, maintaining the quality of the Odoo Enterprise platform. This is a routine maintenance task to improve the stability of our software.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
1 change
Resolved issues and error corrections
This update fixes a minor display issue in the Helpdesk app's performance dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, it's displayed as a score out of 5, providing a clearer and more intuitive understanding of performance.
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#109804
1 change
Resolved issues and error corrections
This update fixes a technical error that previously caused a traceback when a sale order's invoice date was not specified. The fix ensures that stock moves are correctly filtered, regardless of whether an invoice date is present, improving the reliability of subscription order processing. This resolves a potential disruption to order fulfillment.
Original PR description
The Issue: Prior to this commit, When the sale order last_invoice_date is False, a traceback is thrown The Fix: To resolve this, We get the last_invoice_date or todays date opw-4403557 Forward-Port-Of: odoo/enterprise#75717
4 changes
Resolved issues and error corrections
This update fixes an issue where profit and loss accounts were incorrectly appearing on balance sheet reports. The change prevents grouped reporting from miscategorizing accounts, ensuring balance sheets accurately reflect assets, liabilities, and equity. This improves the reliability of financial reporting.
Original PR description
…er unfolded Since the groupby at report level, lines such as "Current Year Unallocated Earnings" were displaying profit and loss accounts in the balance sheet, which is not a desired behavior. task-6152675 Forward-Port-Of: odoo/enterprise#114885
This pull request corrects a typographical error in a test file within the marketing automation module. These tests ensure the functionality of automated marketing campaigns. The fix improves the reliability of the testing process and prevents potential issues with campaign execution.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
This update fixes a problem where Wise recipient matching failed due to differences in data like spacing or casing. Now, the system uses only financial details (account numbers, routing numbers, IBANs) for matching, ensuring accurate recipient identification. This improves the reliability of direct deposit payments.
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
This update fixes an issue where the 'Hide lines at 0' feature was removing the report-level total line from printed reports like the Trial Balance. This commit ensures that total lines, even those without a parent, are always included when printing, providing a more complete and accurate report view. This improves the usability of our financial reporting tools.
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
3 changes
Resolved issues and error corrections
This update corrects a bug in the expense card that prevented payments from being processed for certain merchant categories like airlines, car rentals, and hotels. The fix adds the necessary Merchant Category Codes (MCCs) to the system, ensuring these expenses can now be approved. This improves the user experience and expands the types of expenses that can be tracked.
Original PR description
In the expense card, when a payment is made. The card can be filtered to only allow certains category of merchant. However, the 3 ranges of MCC we not added: - Airlines, air carriers: MCC's from 3000 to 3350 - Car Rental Agencies: MCC's from 3351 to 3500 - Lodging, hotels, motels and resorts: MCC's from 3501 to 3999 And since the MCC are not present in the list, they are rejected by default even the card is set to accept all MCCs. task-5486945
This pull request addresses a minor typo within the marketing automation test suite. The fix ensures the tests run correctly and prevents potential issues with the automated testing process. This is a routine maintenance update to improve the reliability of our marketing automation tools.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
This update corrects a problem where the Account ID used in Odoo's FAIA XML export didn't always match the corresponding account defined in the company's ledger. This ensures accurate financial reporting by aligning data across systems. The fix updates a key element in the export process, improving data consistency.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113455
6 changes
Resolved issues and error corrections
This update strengthens the security of Xendit payments by requiring a valid transaction token alongside the transaction reference. Previously, payments could be processed without this verification, creating a potential risk. Now, payments are restricted to the correct transaction, improving security and preventing unauthorized payments.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue preventing the posting of vendor bills in LATAM purchase journals. The system's hashing logic requires sequential document numbers, which conflicts with vendor-assigned numbers. By hiding the 'Secure Posted Entries with Hash' option for these journals, we ensure data integrity and avoid misleading security indicators.
Original PR description
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure…
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure Posted Entries with Hash". 4. Create and post a vendor bill with a high document number (e.g. 00001-00009999). 5. Create another vendor bill with a lower document number (e.g. 00001-00000100) and try to post it. Issue Posting the second vendor bill fails with: "This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it." The hashing logic in account_journal.py enforces a strict continuous sequential chain per journal: https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678 In LATAM countries, vendor bill document numbers are assigned by the vendor, not by Odoo. A bill with a lower number can legitimately be entered after one with a higher number, which breaks the sequential assumption the hash chain relies on. Allowing it would produce a hash that no longer represents a proper chain, giving users a false sense of security. Sales journals are unaffected because Odoo controls their sequence. Solution Hide the "Secure Posted Entries with Hash" field on purchase journals that have "Use Documents?" enabled, preventing users from enabling an option that cannot work correctly for vendor-assigned document numbers. Sales journals keep the option available since Odoo controls their sequence. opw-6076673
This update fixes an issue where incorrect test tags were being used in Odoo 18, potentially causing the entire Hoost suite to fail. It backports a fix from a previous release to ensure the correct tag is applied, guaranteeing consistent test results across supported versions. This improves stability and reliability of the testing process.
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.
This update fixes a critical issue where gift cards and e-wallets could be repeatedly refunded, leading to potential misuse. It also prevents the merging of order lines when products are linked to multiple loyalty programs, ensuring accurate tracking and reporting. This improves the reliability and integrity of our point-of-sale loyalty programs.
Original PR description
Previously, it was possible to refund a gift card or e-wallet after creation. However, the associated code remained usable, allowing the gift card or e-wallet to be reused, which is not the expected behavior. To address this, refunds for gift cards and e-wallets are now prevented. Additionally, when a product is part of the trigger products for multiple gift card or e-wallet programs, it was not possible to create separate order lines for the same product with different programs selected. The second line was merged into the first. A condition has been added to prevent merging when different programs are selected. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6052281
This update prevents the state of tasks from being reset when their project is changed, specifically when the task is in a 'done' or 'canceled' state. This ensures that tasks are not unnecessarily re-evaluated after completion or cancellation, improving efficiency and reducing potential processing delays. It corrects a previous behavior where project changes would reset task states, even when the task was already marked as finished.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864
This update fixes a discrepancy in the sale details report by accurately reflecting cash rounding adjustments. Now, the report displays the total cash rounding applied during a session, aligning the displayed total with actual payment amounts. This ensures greater accuracy and transparency in sales reporting.
Original PR description
The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled. Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values. opw-5253018 Forward-Port-Of: odoo/odoo#254401