Daily updates from Odoo
Monday, March 23, 2026
267 changes
13 changes
Resolved issues and error corrections
This update resolves a technical issue that prevented the demo data from correctly generating time off allocations when using a future date (2027-01-01) for faketime testing. Updating the demo data ensures the system accurately reflects leave allocation rules, particularly for contracts starting January 1st, and avoids errors during testing.
Original PR description
Issue: The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date. When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off. Fix: Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`. task-6026690 Forward-Port-Of: odoo/enterprise#110293
This update resolves a technical issue preventing the tour from correctly displaying the checkout address within the Brazilian localization (l10n_br) module. The fix addresses race conditions introduced by a recent community update to the select menu, ensuring the tour functions as expected.
Original PR description
Because of the community PR that changes the DOM of the select menu, the tour in this commit crashed. This commit adapts the tour and fixes it as races conditions were still present part-of-task-5935511 Forward-Port-Of: odoo/enterprise#111248
This update fixes an issue where the Report Editor in web_studio wouldn't automatically focus on the editable field after deleting a row or column. This change ensures a smoother user experience by immediately placing the user in the editable area, preventing frustration and improving efficiency. The fix was part of a larger community contribution.
Original PR description
PR [1] ensures that editable is focused after deleting row or column from table menu by preventing default while clicking on table menu button. This change causes test [2] to fail if a table menu test runs beforehand, due to browser’s native focus behavior. This commit ensures that editable is focused whenever clicking on t-field. [1]: https://github.com/odoo/odoo/pull/249256 [2]: https://github.com/odoo/enterprise/blob/19.0/web_studio/static/tests/client_action/report_editor/report_editor_dom_edition.test.js#L456-L478 Community PR: https://github.com/odoo/odoo/pull/249256 task-5725593 Forward-Port-Of: odoo/enterprise#111154 Forward-Port-Of: odoo/enterprise#109034
This update resolves an error that occurred when activating the 'hr_expense_stripe' module with unsupported currencies (like INR). The fix prevents the creation of a problematic journal, ensuring the invoicing dashboard can be opened without errors. It now defaults to the company's currency for new databases.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to reproduce: (19.0) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` - Create New company > Set `Country` and `Currency` (eg: India and INR) > Switch to New company > Open `Invoicing` you will get the error. Steps to reproduce: (saas-19.1) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` > Open `Invoicing` you will get the error. Traceback: `ValueError: Expected singleton: res.currency()` In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing". In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error. However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error. Solution: - The`Stripe Issuing` journal will no longer be created on installing the module. - For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied. [PR]: https://github.com/odoo/enterprise/pull/96271 [journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187 [commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd sentry-7284934493 Forward-Port-Of: odoo/enterprise#108436
This update resolves a technical issue related to how Odoo handles geographic data (topoJSON) within its spreadsheet charts. The fix ensures that these charts display correctly and reliably, improving the accuracy of visual reports. This change primarily impacts the Enterprise edition's chart functionality.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update resolves an issue where the topbar menu wasn't correctly updated when a menu was opened using the AI Agent. The fix ensures that the topbar menu accurately reflects the currently active menu after an AI Agent interaction, improving the user experience. This change was driven by a bug fix (Task-6017607).
Original PR description
Purpose: -------- When a menu (view) was opened through an AI Agent, the menu in the topbar was not updated. This commit fixes this behaviour by setting the menu when the menu's action has been loaded Task-6017607 Forward-Port-Of: odoo/enterprise#109929
This update automatically calculates and transmits the necessary commission deductions for Swiss payroll (ELM) based on employee data. This ensures accurate tax reporting and compliance with Swiss regulations, streamlining the payroll process. The change corrects a previous issue related to commission calculations.
Original PR description
task-6050810 Forward-Port-Of: odoo/enterprise#111143
This update resolves a problem where the website's tour process was delayed due to timing issues, specifically with loading translations. The change ensures the tour starts correctly, preventing delays and improving the user experience. This was caused by recent changes in Chrome versions.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update resolves a test issue where simultaneous data synchronization in the Point of Sale (POS) tax module caused errors. The fix ensures that backend processes complete before the test continues, improving test reliability and preventing disruptions. This enhances the overall stability of the POS tax functionality.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update resolves an issue where the map view in the "My Dashboard" sometimes collapsed due to conflicting height settings. The fix removes overly restrictive height rules and adds a minimum height to the map, ensuring it always displays correctly regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#111195 Forward-Port-Of: odoo/enterprise#110790
This update corrects a bug where changes to view ordering within the Documents module's studio interface weren't consistently applied. The fix involved updating the default order setting to be applied correctly through the designated attribute on the relational model, ensuring view ordering changes are now reliably saved and reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update fixes a visual inconsistency in accounting reports. Previously, the company header was grayed out in dark mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across all Odoo Enterprise environments.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111509 Forward-Port-Of: odoo/enterprise#110108
This update resolves an issue where long tax amounts in invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the numerical size, improving the clarity and accuracy of Ke revenue reports. This enhancement ensures consistent and reliable reporting for Kenyan businesses.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
17 changes
Resolved issues and error corrections
This update corrects a bug in the SendCloud delivery service that was preventing the system from correctly processing delivery requests. The issue stemmed from an incorrect use of Python slicing, which was causing a data retrieval error. The fix ensures reliable delivery processing.
Original PR description
Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error. This was not caught because the tests do not run in CI due to the tags on the class. Forward-Port-Of: odoo/enterprise#111254
This update fixes an issue where the Report Editor wouldn't automatically focus on the editable field after making changes like deleting rows or columns. This ensures a smoother user experience when working with report designs, preventing unnecessary clicks and improving efficiency. The change was made to address a test failure related to browser focus behavior.
Original PR description
PR [1] ensures that editable is focused after deleting row or column from table menu by preventing default while clicking on table menu button. This change causes test [2] to fail if a table menu test runs beforehand, due to browser’s native focus behavior. This commit ensures that editable is focused whenever clicking on t-field. [1]: https://github.com/odoo/odoo/pull/249256 [2]: https://github.com/odoo/enterprise/blob/19.0/web_studio/static/tests/client_action/report_editor/report_editor_dom_edition.test.js#L456-L478 Community PR: https://github.com/odoo/odoo/pull/249256 task-5725593 Forward-Port-Of: odoo/enterprise#109034
This update resolves an error that occurred when activating the 'hr_expense_stripe' module with unsupported currencies (like INR). The module will no longer attempt to create a specific journal, and existing company currencies will now be used as a fallback, ensuring the invoicing dashboard functions correctly.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to reproduce: (19.0) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` - Create New company > Set `Country` and `Currency` (eg: India and INR) > Switch to New company > Open `Invoicing` you will get the error. Steps to reproduce: (saas-19.1) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` > Open `Invoicing` you will get the error. Traceback: `ValueError: Expected singleton: res.currency()` In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing". In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error. However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error. Solution: - The`Stripe Issuing` journal will no longer be created on installing the module. - For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied. [PR]: https://github.com/odoo/enterprise/pull/96271 [journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187 [commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd sentry-7284934493 Forward-Port-Of: odoo/enterprise#108436
This update fixes an issue where the "Submit" button was hidden when creating return types in the account reports. The change removes an outdated field requirement, ensuring the button is always visible for users to complete the return type creation process. This improves usability for users generating return reports.
Original PR description
When a user creates a return_type, the submit button is not visible as there is no type_external_id. Since now, we have the states_workflow this is not useful anymore. This commit is basically a back port of https://github.com/odoo/enterprise/commit/305b0078e584487036d907d6e18b7911bc7ff1de Forward-Port-Of: odoo/enterprise#110328
This update corrects a previous error that occurred when the 'Payroll: Update Data' cron job ran, specifically within the Saudi Arabian payroll configuration. The issue stemmed from deleting salary rule categories, which caused a data mismatch during the update process. This fix ensures that the rule category data is updated before the salary rule data, preventing the error and maintaining accurate payroll processing.
Original PR description
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. -…
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. - Delete all records related to the Saudi Arabian company. - Go to `Scheduled Actions` and run `"Payroll: Update Data"`. `ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision` After [this commit], the category_id field becomes non-required, allowing users to delete a rule category record even if it is linked to a salary rule. When updating the data file [1], this causes an error due to the missing rule category [2]. This commit ensures that, when updating the salary rule data, the rule category data is updated beforehand, as shown here [3]. [this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e [1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165 [2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249 [3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18 sentry-7349905716
This update fixes an error in the reports generated for Ecuador (l10n_ec_reports_ats) by ensuring the correct 'tipoCliente' value is used for foreign partners. Previously, the system incorrectly identified company types, leading to inaccurate tax reporting. This change aligns with AFIP requirements and ensures compliance.
Original PR description
Since `tipoCliente` is now determined using the computed `is_company` field, the test data must reflect this logic. `partner_ext` represents a foreign partner and is considered a company, therefore its `tipoCliente` should be set to '02'. See: https://github.com/odoo/enterprise/commit/a779badac35cf4a8f483f490e8ae29eb6bf3d2c5 `l10n_ar_edi`: For foreign partners, AFIP requires the CUIT pais based on the partner’s country and document type, not on partner.is_company. In multi-localization databases, is_company may be influenced by local heuristics and lead to picking the wrong foreign tax identifier. Use the identification type instead: VAT documents map to the legal-entity CUIT pais, while non-VAT documents map to the natural-person one. See: https://github.com/odoo/enterprise/pull/86089#discussion_r2128977870 runbot-241126
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Odoo Enterprise spreadsheet reports. The fix ensures accurate display of maps and charts based on location data, improving the reliability of reports. This change primarily impacts users who rely on location-based data visualizations.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update fixes a bug preventing portal users from viewing timesheets on helpdesk tickets linked to projects with 'Invited internal and portal users' visibility. The change expanded the domain to include both 'portal' and 'invited_users' visibility options, ensuring correct timesheet display for all users.
Original PR description
Steps to reproduce: - Create Project A with visibility set to `Invited internal and portal users.` - Create a Helpdesk Team and assign Project A to it. - Create a helpdesk ticket. - Log a timesheet…
Steps to reproduce:
- Create Project A with visibility set to `Invited internal and portal users.`
- Create a Helpdesk Team and assign Project A to it.
- Create a helpdesk ticket.
- Log a timesheet on the ticket and share the ticket with the portal user.
- Log in as the portal user and check the timesheet.
- Observe that the timesheet is not visible to the portal user.
Cause:
- After introducing the `invited_users` option in `privacy_visibility`, the portal domain in `_timesheet_in_helpdesk_get_portal_domain` was not updated.
- The domain was still defined as: `('project_id.privacy_visibility', '=', 'portal')`
- As a result, timesheets linked to projects with visibility set to “Invited internal and portal users” were excluded from the portal user’s view.
Solution
Update the domain to include both visibility options: `('project_id.privacy_visibility', 'in', ['portal', 'invited_users'])`
- This ensures timesheets are visible to portal users when the project visibility is either portal or invited_users.
task-5924243
Forward-Port-Of: odoo/enterprise#107800This update resolves an issue where the topbar menu wasn't correctly updated after a user opened a menu using an AI Agent. The fix ensures the topbar accurately reflects the currently active menu, improving the user experience when interacting with AI-powered features. This enhances usability and consistency.
Original PR description
Purpose: -------- When a menu (view) was opened through an AI Agent, the menu in the topbar was not updated. This commit fixes this behaviour by setting the menu when the menu's action has been loaded Task-6017607 Forward-Port-Of: odoo/enterprise#109929
This update automatically calculates and transmits the required perception commission for Swiss employees through the Swissdec system. This ensures accurate and timely reporting for tax compliance, addressing a previous issue with manual calculations. The change impacts the l10n_ch_hr_payroll module.
Original PR description
task-6050810 Forward-Port-Of: odoo/enterprise#111143
This update resolves a problem where the website's tour process was failing due to timing issues, particularly with translation loading in recent Chrome versions. The fix adds a temporary step to ensure translations load before the tour continues, preventing interruptions and ensuring a smoother user experience.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update resolves a test issue where simultaneous data synchronization in the Point of Sale (POS) tax module caused errors. The fix ensures that backend calls complete before the test continues, improving test reliability and preventing disruptions. This enhances the overall stability of the POS tax functionality.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update corrects a bug where changes to view ordering within the Odoo Studio were not being applied correctly. The fix involved updating the default order setting to be applied through the designated `defaultOrderBy` attribute on the related model, ensuring consistent view ordering for users.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update resolves an issue with automatic GST token refreshes in the Odoo Enterprise system. The automatic refresh process has been disabled, and now the refresh is triggered manually when needed, ensuring compliance and reducing potential operational overhead. This change improves stability and control over token management.
Original PR description
With this PR, the GST token refresh cron interval is updated from 5 hours to 9999 months to effectively disable automatic execution. The cron will instead be triggered manually from `validate_otp` and `_cron_refresh_gst_token` based on the token expiration time. Forward-Port-Of: odoo/enterprise#109937
This update clarifies error messages related to Instagram integration (code 9004) within the Odoo Enterprise platform. The change provides users with more helpful guidance when encountering these issues, reducing the need to contact support. This improves the overall user experience and stability of the Instagram feature.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110571 Forward-Port-Of: odoo/enterprise#109319
This update corrects a visual issue in the accounting reports where the company header was grayed out in dark mode. The change ensures consistent branding and a better user experience by using a standard muted data color, aligning with the overall design of the application.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111509 Forward-Port-Of: odoo/enterprise#110108
This update resolves an issue where long tax amounts in Ke revenue reports were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the numerical size, improving the clarity and accuracy of financial reports. This enhancement impacts the user experience for Ke revenue reporting.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
6 changes
Resolved issues and error corrections
This update corrects a visual issue in the accounting reports where the company header was grayed out in dark mode. The change ensures the company header consistently uses the standard muted data color, providing a better and more consistent user experience across all Odoo environments.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111353 Forward-Port-Of: odoo/enterprise#110108
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition's spreadsheet reports. The fix ensures accurate display of geographical charts and maps, improving the reliability of data visualization for business users. This change was part of a larger adaptation to improve testing.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update corrects a bug where payslip dates were incorrectly using the employee's start date instead of their first contract date within the company. The system now uses the employee's initial contract date, ensuring accurate payroll reporting and compliance. This change was implemented as a fix to improve data consistency.
Original PR description
…irst contract date in payslips - `first_contract_in_company` is now a computed field instead of being manually populated in the departure notice wizard. - `first_contract_in_company` is now used for the first contract date in payslip reports instead of using the current version's start date. - in departure notice wizard fixed how `first_contract` is calculated by using the refactored `_get_first_version()` function. - removed manual update of `first_contract_in_company` in the departure wizard as it is now handled by the compute. Task: 5368029
This update resolves an issue where CFDI reports incorrectly displayed '99 - False' instead of '99 - Por definir' for payment method 99. The fix ensures that the correct payment method description is generated in the PDF reports, improving data accuracy for Mexican tax reporting.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update automatically calculates and transmits the required perception commission for Swiss employees' payrolls. This ensures accurate tax reporting to the Swiss tax authorities, addressing a previous reporting issue. The change improves compliance and reduces the risk of errors related to commission calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#111143
This update corrects a bug where changes to view ordering within the Documents module's studio interface weren't consistently applied. The fix involved updating the code to correctly utilize the `defaultOrderBy` attribute on the relational model, ensuring that view order settings are properly saved and reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
13 changes
Resolved issues and error corrections
This update fixes a visual inconsistency in the accounting reports. Previously, the company header was grayed out only in light mode. Now, it dynamically adjusts to the dark mode theme using a standard muted data color, ensuring a consistent and professional appearance across all viewing modes.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111353 Forward-Port-Of: odoo/enterprise#110108
This update corrects a map data issue where Russia was missing from the Asia map. It also includes a new map for Oceania, ensuring more accurate geographic representation. This improves the visual accuracy of location-based data within Odoo.
Original PR description
- Fix Asia map (russia was missing) - Added Oceania map Task-5224009 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248847
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Odoo Enterprise spreadsheet reports. The fix ensures accurate display of maps and charts based on location data, improving the reliability of reports that rely on geographic visualizations. This update primarily impacts the spreadsheet functionality.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update addresses a technical issue related to the validation of partner country information within the l10n_ec_edi module. The fix ensures that the identification type of a partner aligns with their registered country, resolving two failing tests. This improves the accuracy of EDI processing for Ecuadorian businesses.
Original PR description
In pr https://github.com/odoo/odoo/pull/248585 I added a check that verify if the l10n_latam_identification_type of a partner correspond to the partner country. It breaks two tests which are fixed here. opw-5801824
This update resolves an issue preventing invoices to Åland Island (AX) partners from being correctly sent via PEPPOL. Previously, invoices were generated but not transmitted, resulting in attachments but no chatter notifications. This change enables Peppol functionality for companies in Åland Island.
Original PR description
Before this commit, invoice to a partner in Åland Island can't be sent via Peppol. XML and PDF are generated, linked to the account.move, but are not sent and don't appear in the chatter. Steps to reproduce: - Create a partner in Åland Island - Create an invoice - Send to Peppol Current behavior: - Invoice is not sent, appear in the attachment, but doesn't appear in the chatter. Expected behavior: - invoice is sent and attachments are in the chatter This also allow activating Peppol for companies in Åland Island. Ticket [link](https://www.odoo.com/odoo/project.task/5949439) opw-5949439
This update optimizes how Odoo loads its registry, significantly reducing the time it takes to start up, especially for customers with large addon installations. By avoiding unnecessary file system scans, the change dramatically improves performance and responsiveness, leading to faster request processing.
Original PR description
In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving…
In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving static files. In the WSGI application entry point `__call__`, the threads will be going into `self.get_static_file` and up until this point, there's no locking whatsoever on these threads. Inside `get_static_file`, the `self.statics` lazy_property is evaluated which will walk the addons path. Before this PR, the order of the conditions in the or statement will always evaluate the lazy property regardless of the other parts of the condition. This means that every single request that comes in will do an unnecessary `os.listdir` on all addons paths. For customers with a very large and deeply nested addons path like in opw-5877522 (they had over 93K dirs), this is a tremendous load on the system when there are multiple threads doing that due to the amount of syscalls involved for no reason whatsoever. This is especially worse on SH because disks are not local, so an individual syscall is more expensive. This is slowing down all requests as well as the registry loading time which is a prerequisite for any non-static request. This PR simply reorders this check to only evaluate the self.statics property if all other parts of the condition are False. This means it'll only have to do this expensive `os.list` for a fewer number of requests which are much more unlikely to coincide at the startup of a worker. On top of that it's a better optimization to avoid doing this expensive check for every request. Benchmarks |No. files in addons path| No. concurrent threads | Registry loading time Before PR | Registry loading time After PR | |--------|--------|--------|--------| | 93447 | 5 | 53.23 s | 4 s | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254660
This update corrects a previous issue that prevented users from finding and adding a partner's bank account when creating a credit note. The system now correctly filters bank accounts based on the expected recipient, ensuring credit notes function as intended. This resolves a limitation that was impacting credit note processing.
Original PR description
Description of the issue this commit addresses: The Recipient Bank field in the Other Info tab of the Account Move form view refilters accounts to only show you company's ones. This is expected for invoices but is blocking when doing a credit note. You can't find a partner's bank account to fill that field. --- Steps to reproduce: 1. Install account. 2. Create an Invoice to a partner which has a bank account setup. 3. Create a Credit Note for that Invoice. 4. In the "Other Info" tab, remove the partner's bank account. 5. Try to search for his bank account to add it back. It won't show up. --- Desired behavior after this commit is merged: The Recipient Bank field prefilters bank accounts based on who is expected to be the recipient of the move. --- task-5976951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254850 Forward-Port-Of: odoo/odoo#252961
This update resolves an issue where CFDI reports incorrectly displayed '99 - False' instead of '99 - Por definir' for payment method 99. The fix ensures accurate reporting of this payment method, addressing a discrepancy in the Mexican tax invoice generation process. This ensures compliance and accurate financial reporting.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves an issue where PDF merging errors didn't consistently display user-friendly error messages. The fix ensures that a clear error message is always shown when PDF merging fails, regardless of the underlying cause. This improves the user experience and helps identify problems with generated reports.
Original PR description
When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to the handle_error function.
The aim here is to keep the same function signature and edit the signature of the local function used when a custom_handle_error was defined and edit the function itself.
The error message appeared when I was working on a task to change a
test and tested it on master and got the following stacktrace:
```
...
File "/home/odoo/Desktop/src/odoo/odoo/addons/base/models/ir_actions_report.py", line 788, in _merge_pdfs
handle_error(error=e, error_stream=stream)
TypeError: IrActionsReport._handle_merge_pdfs_error() missing 1 required positional argument: 'self'
```
Discovered during : task-3603619
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#211611This update automatically calculates and transmits the necessary commission information for Swiss payroll declarations (ELM). Previously, this calculation was manual, introducing potential errors and delays. This change ensures accurate and timely reporting to Swiss tax authorities, streamlining the payroll process.
Original PR description
Forward-Port-Of: odoo/enterprise#111143
This update corrects a display issue where the 'Pick Up in Store' option was incorrectly shown for products with excluded tags. The fix ensures that unavailable delivery methods aren't presented to customers, improving the user experience and maintaining consistent behavior across the website.
Original PR description
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page. Steps to produce: --- - Install…
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page.
Steps to produce:
---
- Install `website_sale` module.
- Enable `Click and Collect` in settings.
- Go to `website > ecommerce > products > product tags.`
- Create a new tag and add a product in product template.
- Go to` website > configuration > ecommerce > delivery method.`
- Open` pick up in store`:
- In the `Stores` tab, set your company warehouse.
- In the `Availability` tab, add the created tag to Excluded Tags.
- Publish the delivery method.
- Open the tagged product on the website.
Issue:
---
- The Pick Up in Store option is still displayed on the product page, even though the product has a tag listed in the carrier’s Excluded Tags.
Root cause:
---
- Here at [1], the method `_get_additional_combination_info ()` does not check whether the product has tags that are excluded by the delivery method.
- However, at [2], during checkout, the exclusion works correctly because `_match_excluded_tags` in `delivery.carrier` filters the carrier based on excluded tags.
Solution:
---
- Hide the Pick Up in Store option when the product has tags excluded
for that delivery method. This keeps the behavior consistent across
the website, avoids showing unavailable delivery options, does not
impact other flows and aligns with the existing behavior during
checkout.
[1]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/website_sale_collect/models/product_template.py#L17-L21
[2]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/delivery/models/delivery_carrier.py#L192-L194
opw-5921268
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255066
Forward-Port-Of: odoo/odoo#250837This update corrects a validation issue in the ZATCA XML generation for Saudi Arabia companies. Previously, the system didn't include cash rounding amounts in the payable calculation, leading to validation errors. This change ensures accurate payable amount calculations for invoice validation, aligning with ZATCA requirements.
Original PR description
Currently the generated ZATCA XML is not accounting for invoice cash rounding, leading to an invoice validation issue due to a mismatch in the calculation of PayableAmount. Steps to reproduce: - Have a SA Company setup - Create a [cash rounding] with strategy 'Add invoice line' and rounding 1.00 (UP) - Create an invoice for 99.55 + 15% Tax - Set Cash Rounding Method to [cash rounding] - Confirm and send xml for validation Issue: Validation will issue the following warning `[202] BR-CO-16 : Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Pre-Paid amount (BT-113) + Rounding amount (BT-114).` Analysis: The ZATCA implementation was calculating the payable amount strictly as (TaxInclusiveAmount - PrepaidAmount). This change ensures the rounding amount is fetched and added to the total payable calculation opw-5939550 Forward-Port-Of: odoo/odoo#254450 Forward-Port-Of: odoo/odoo#253555
This update corrects a visual issue where menu items on the website didn't align properly when using mobile view or hamburger menus. The fix adjusts how the menu items are styled, ensuring they align to the right or center based on the user's selection. This improves the overall user experience on mobile devices.
Original PR description
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop",…
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop", "Forum") stay left-aligned regardless of the chosen alignment. This can also be seen on desktop by switching to the sidebar header template. Cause: ====== The class .accordion-button uses `display:flex` and `text-align:left` and that class is used for the menu groups labels. this prevents the alignment from working. Solution: ========= When right-aligned (`text-end`), reverse the flex direction so the arrow moves to the left and the text stays on the right. When centered (`text-center`), let the text span fill the remaining space and center its content via `text-align: center`, keeping the arrow on its position. The default left-aligned case is unchanged. opw-5494765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244565
23 changes
Resolved issues and error corrections
This update enhances the Odoo Enterprise Web Studio interface by ensuring the 'reset' button is only displayed when a logo is uploaded. This simplifies the user experience by preventing unnecessary options and focusing on the core functionality. It's a small but important refinement for usability.
Original PR description
SPECIFICATION: The reset button should only be visible when a logo has been uploaded. If no logo is uploaded, the reset button should remain hidden. Task-4010875
This update fixes a problem in the demo data for our time off system. Specifically, it ensures that leave allocations start correctly when using future dates (like 2027-01-01) to avoid errors and ensure the system functions properly for real-world 'time off to defer' scenarios.
Original PR description
Issue: The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date. When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off. Fix: Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`. task-6026690 Forward-Port-Of: odoo/enterprise#111435 Forward-Port-Of: odoo/enterprise#110293
This update resolves an issue where the bulk payments feature would crash if a bank journal wasn't properly connected. A new user message will now appear, guiding users to ensure their bank account is linked before attempting to check the status of a payment batch. This improves the user experience and prevents unexpected errors.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#111327 Forward-Port-Of: odoo/enterprise#109956
This update resolves an error that occurred when using the 'hr_expense_stripe' module with unsupported currencies like INR. The module will no longer attempt to create a 'Stripe Issuing' journal, preventing the error and allowing users to access the invoicing dashboard. The fix ensures a stable experience when using specific currency configurations.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to reproduce: (19.0) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` - Create New company > Set `Country` and `Currency` (eg: India and INR) > Switch to New company > Open `Invoicing` you will get the error. Steps to reproduce: (saas-19.1) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` > Open `Invoicing` you will get the error. Traceback: `ValueError: Expected singleton: res.currency()` In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing". In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error. However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error. Solution: - The`Stripe Issuing` journal will no longer be created on installing the module. - For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied. [PR]: https://github.com/odoo/enterprise/pull/96271 [journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187 [commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd sentry-7284934493 Forward-Port-Of: odoo/enterprise#108436
This update resolves a technical problem related to how Odoo handles data serialization in its localization modules (Arabic, Belgian, and Mexican editions). The fix ensures that data is correctly formatted, preventing potential errors and improving the stability of these important regional versions of Odoo. This change primarily impacts the functionality of these localized modules.
Original PR description
runbot-241772 https://github.com/odoo/odoo/pull/254995
This update ensures that Knowledge articles appear in the standard activity filters (My Activities, Today Activities, and Late Activities) when viewed from the systray. Previously, Knowledge was missing these filters, leading to inconsistent activity views. This change improves user experience and ensures all relevant articles are easily accessible.
Original PR description
Activity redirections from systray apply the default filters My Activities, Today Activities, and Late Activities. However, Knowledge was missing these filters. This commit fixes this so that the default activity filters are set in all models in the activity systray. task-5424661
This update enhances product pricing by now sending unit of measure information (price per unit and quantity) to the system. It also resolves a previous issue where product tag updates weren't automatically triggered by changes to product barcodes or linked products, ensuring accurate pricing and tag synchronization.
Original PR description
If units of measure is configured, we now send the price per unit and the amount of unit for the current product. This commit also fixes an issue where we didn't call pricer API to update tags if we updated the tag barcode, or if we updated the product linked to it. Task-5129442
This update ensures the topbar menu accurately reflects the menu selected through Odoo's AI Agent. Previously, the topbar didn't update when an AI Agent opened a menu, leading to a disjointed user experience. This fix corrects this behavior, providing a more consistent and intuitive interface for users.
Original PR description
Purpose: -------- When a menu (view) was opened through an AI Agent, the menu in the topbar was not updated. This commit fixes this behaviour by setting the menu when the menu's action has been loaded Task-6017607 Forward-Port-Of: odoo/enterprise#109929
This update corrects a bug in the refund processing for multi-line orders. Previously, the system incorrectly summed line amounts, leading to inaccurate comparisons and potential refund failures due to rounding discrepancies. This change ensures refunds are calculated correctly, preventing order discrepancies and improving financial accuracy.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201 Forward-Port-Of: odoo/enterprise#109124 Forward-Port-Of: odoo/enterprise#105301
This update automatically calculates and transmits the necessary commission payments related to employee compensation for Swiss payroll (ELM). Previously, this calculation was manual, and this change streamlines the process, ensuring accurate and timely reporting to Swiss tax authorities. This improves compliance and reduces the risk of errors.
Original PR description
task-6050810 Forward-Port-Of: odoo/enterprise#111143
This update resolves a bug that prevented invoices with the ICBPER tax code from being processed correctly. The issue stemmed from a technical detail in how the system handles fixed taxes, specifically when splitting them into separate base lines. By setting a configuration flag to false, the system now generates invoices with this tax without errors.
Original PR description
**Steps to reproduce:** 1. Install module `l10n_pe_edi`. 2. Switch company to PE. 3. Create a tax: - Name: ICBPER - Amount type: Fixed - Code: ICBPER - Amount: 0.5(e.g.) - Set the tax group to ICBPER…
**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
- Name: ICBPER
- Amount type: Fixed
- Code: ICBPER
- Amount: 0.5(e.g.)
- Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).
**Issue:**
Processing the invoice raises:
AttributeError: 'dict' object has no attribute '_get_downpayment_lines'
**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.
During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
- With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
- With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.
**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error
**opw-5809939**
Forward-Port-Of: odoo/enterprise#108638This update resolves an issue where the payroll module wouldn't function correctly if only the core payroll components were installed. The `l10n_mx_min_wage_zone` field has been moved from a separate module to the main payroll module, ensuring compatibility and proper operation for all users.
Original PR description
The `l10n_mx_min_wage_zone` field is used in `l10n_mx_hr_payroll`, but it was originally defined in `l10n_mx_hr_payroll_account_edi`. This causes errors when a user only installs the `l10n_mx_hr_payroll` module, as the field is missing. Related commit: 11bb6db4884083b3f48582b749c01ae75a09cf66 target: master task-6047772
This update fixes an issue with the account reports where messages were displayed on multiple lines, making them difficult to read. Additionally, the VIES check hyperlink was corrected to ensure proper formatting. This improves the user experience and clarity of key account reporting information.
Original PR description
The company data check message was on multiple line. <img width="555" height="99" alt="image" src="https://github.com/user-attachments/assets/3916a794-57b7-4abb-9e76-0b39e63b8dd6" /> The VIES check hyperlink wasn't Markup. <img width="685" height="73" alt="image" src="https://github.com/user-attachments/assets/0d05d15e-7155-4435-9738-5e77263f6638" />
This update resolves a test issue caused by simultaneous data synchronization attempts within the Point of Sale Tax module. The fix ensures that backend processes complete before subsequent test steps are executed, preventing errors and improving test reliability. This enhances the overall stability of the Odoo Enterprise system.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update resolves an issue where the interactive POS tours wouldn't load correctly on databases without demo data, causing a crash. The fix ensures the tours are correctly loaded for the POS environment and prevents errors when steps are missing. This improves the user experience for new POS installations.
Original PR description
With the new interactive tour handling, an issue occurred when loading the POS on a database without demo data. The tour steps were fetched from the "web_tour.tours" registry, but those tours were…
With the new interactive tour handling, an issue occurred when loading the POS on a database without demo data. The tour steps were fetched from the "web_tour.tours" registry, but those tours were only loaded in the "web.assets_backend" bundle, while the tour service can also run in the frontend (POS). As a result, no tour was found in the registry when loading the POS, leading to empty steps. Since no steps were available, the tour tried to access the current action, which was undefined, causing a crash. To fix this, a guard was added to ensure that steps exist before accessing the current action. If no steps are found, the tour test is put on hold, as it means the tour is not part of the currently loaded bundle and should not run. Additionally, the "point_of_sale_tour" was improved to execute actions when the POS is loaded, instead of relying only on the backend. This required loading "web_tour.assets_frontend" into the "point_of_sale._assets_pos" bundle. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6050295
This update corrects a bug where changes to view ordering within the Odoo Studio interface weren't consistently applied. The fix involved updating the system to correctly utilize the `defaultOrderBy` attribute on the related models, ensuring that view order settings are properly saved and reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update streamlines how emojis are loaded and managed within Odoo, making it faster and more reliable. The changes improve performance in testing and reduce the overall memory footprint of the system. This enhancement contributes to a smoother user experience and more efficient test environments.
Original PR description
Feature that is aimed to ease and centralize the loading and management of emoji data. Follow-up of https://github.com/odoo/odoo/pull/253344 in the same effort to reduce overall memory consumption and increase performance in tests to restore (some) nightly builds. - Community: https://github.com/odoo/odoo/pull/253078 Forward-Port-Of: odoo/enterprise#110146
This update resolves a technical issue within the Point of Sale (POS) testing process. The previous test was incorrectly simulating order refunds, leading to errors and preventing proper refund processing. This fix ensures the test accurately reflects the backend refund workflow, improving reliability.
Original PR description
The test l10n_pe_edi_pos.RefundWithReasonTour was badly written at some steps. It was paying an order but not waiting it to be fully processed by the backend to try to refund it leading to some information missing and thus some future step failing. This commit is adding the necessary waiting steps. runbot-error: 237981 Forward-Port-Of: odoo/enterprise#110484
Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was delivered. This update corrects this issue by preventing the sending of multiple attachments, ensuring all files are successfully transmitted to the recipient. This improves the reliability of WhatsApp communication within Odoo.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#111001 Forward-Port-Of: odoo/enterprise#107424
This update resolves an issue where long tax amounts on invoices caused display problems. The fix ensures tax totals are correctly shown, regardless of the number of digits, improving invoice clarity for users. This change impacts the l10n_ke_edi_oscu module.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
This update fixes a visual inconsistency in the accounting reports. Previously, the company header was grayed out only in light mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across both light and dark modes.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111509 Forward-Port-Of: odoo/enterprise#110108
This update enhances security within Odoo's spreadsheet modules by ensuring that users only have access to data based on their permissions. The changes align search filters with access controls, preventing unauthorized data viewing. This improves data security and protects sensitive information within spreadsheet applications.
This update resolves an issue where deleting large numbers of contract salary records could lead to incomplete deletions. By implementing a commit/rollback mechanism within the scheduled task, the system now ensures all records are fully processed, preventing data inconsistencies. This improves data integrity and reliability.
Original PR description
The CRON needs savepoints when deleting records to avoid partial deletes from happening when catching ValueError. Instead of savepoints, that are heavy in terms of recources, we can commit/rollback in this cron.
13 changes
Resolved issues and error corrections
This update corrects a visual inconsistency in accounting reports. Previously, the company header was grayed out only in light mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across both light and dark modes.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111353 Forward-Port-Of: odoo/enterprise#110108
This update removes the outdated 'short' option from the `format_datetime` and `format_time` functions. This change is necessary for the Odoo 19.0 release as the `short_time_format` and `short_date_format` fields have been deprecated. It ensures consistent date and time formatting across the appointment, data cleaning, planning, and sale-renting modules.
Original PR description
modules: appointment, data_cleaning, planning, sale_renting From this [commit], the methods `format_datetime` and `format_time` no longer handle `short` because the fields `short_time_format` and `short_date_format` are no longer available in 19.0. [commit]: https://github.com/odoo/odoo/commit/062b14097033afc19252cf3b8bb1fc541f8c868d#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208 opw-6030342
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition's spreadsheet functionality. The fix ensures accurate display of maps and charts generated from spreadsheet data, improving the user experience for business reporting. This change primarily impacts users relying on geographic visualizations within the Enterprise module.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update resolves an issue preventing invoices with the ICBPER tax code from generating correctly. The fix addresses a technical problem related to how the system handles fixed taxes, ensuring invoices with this tax now process without errors. This improves the reliability of invoice generation for Peru customers.
Original PR description
**Steps to reproduce:** 1. Install module `l10n_pe_edi`. 2. Switch company to PE. 3. Create a tax: - Name: ICBPER - Amount type: Fixed - Code: ICBPER - Amount: 0.5(e.g.) - Set the tax group to ICBPER…
**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
- Name: ICBPER
- Amount type: Fixed
- Code: ICBPER
- Amount: 0.5(e.g.)
- Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).
**Issue:**
Processing the invoice raises:
AttributeError: 'dict' object has no attribute '_get_downpayment_lines'
**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.
During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
- With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
- With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.
**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error
**opw-5809939**This update fixes an issue where the 281.50 PDF report occasionally generated an extra page with header and footer content. The change optimizes the report layout to ensure it consistently appears on a single page for standard reports, improving readability and reducing unnecessary PDF sizes.
Original PR description
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and…
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number. The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner. **Steps to reproduce:** - Log to a Belgian company - Create a contact that is a person - Add the 281.50 tag to them - Create a credit note for any positive amount for that person and set the date to the previous year - Make sure the account used in the credit note has any 281.50 x tag assigned - Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note - When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact opw-5930339
This update fixes a technical error that occurred when users tried to take a picture without an IoT device connected to a quality control point. The fix prevents a system error and guides users to properly set up the device, ensuring a smoother workflow for quality checks.
Original PR description
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality >…
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality > Quality Control > Control points - Create a new Control point with - Type: Take A Picture - Operations: My Company: Receipts - Create and confirm a purchase order for a test product - Receipts > Quality Checks > Take A picture ## Observed behavior: TypeError: Cannot read properties of undefined (reading '0') ## Root cause: This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined. These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined. [1]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 [2]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 [3]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 [4]: https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32 ## Solution: Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4] opw-6010095
This update resolves an issue where the CFDI payment method '99' incorrectly displayed as '99 - False' on reports. The fix ensures that '99 - Por definir' is shown accurately, aligning with Mexican tax regulations. This improves report accuracy for invoices with payment method 99.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves a test issue caused by simultaneous requests for order tax details, which previously triggered errors. The fix ensures that backend processes complete before subsequent test steps are executed, improving the reliability of the POS tax test. This enhances the overall stability of the Odoo Enterprise Point of Sale module.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update fixes an issue where users weren't receiving email notifications for signature requests when their notification preferences were set to 'inbox'. Now, all signature requests will trigger email notifications, ensuring signers are promptly informed. This change maintains in-app visibility for users who track requests within Odoo.
Original PR description
When a user's notification preference is set to "inbox", no email is sent, which may prevent signers from being notified of signature requests. This commit enforces sending email notifications for signature requests regardless of user notification settings. Notifications are still created in Odoo, preserving in-app visibility for users who rely on it. task-6041834
This update corrects a bug where changes to view order within the Odoo Studio interface weren't consistently applied. The fix involved updating the code to properly set the default order for views using the designated attribute on the relational model. This ensures that view order changes made through the Studio are now correctly reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update resolves an issue where long tax amounts in Ke EDI reports were causing display problems. The fix ensures that tax totals are accurately and clearly presented, regardless of the numerical size. This improves the readability and usability of invoices generated using the l10n_ke_edi_oscu module.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
This update resolves an issue where the calculation of employee appraisal dates was inconsistent. The fix ensures test employees are created *after* company appraisal settings are configured, leading to accurate appraisal date calculations. This improves the reliability of appraisal scheduling within the system.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111265
This update automatically calculates and transmits the necessary commission payments related to employee earnings for Swiss payroll (l10n_ch_hr_payroll). Previously, this calculation was manual, and this change streamlines the process, ensuring accurate and timely reporting to Swiss tax authorities. This improves compliance and reduces the risk of errors.
Original PR description
Forward-Port-Of: odoo/enterprise#111143
12 changes
Resolved issues and error corrections
This update resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from hourly wage and multiplier, mirroring a previous solution for Australia, ensuring accurate overtime pay is displayed. This improves payroll accuracy for employees with very short overtime periods.
Original PR description
The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier instead, inspired by edc4ed3c21b which did the same for Australia. task-6052711
This update addresses a security vulnerability where automated email scanners could unintentionally cancel appointments through a simple link. By changing the appointment cancellation link to a POST form, we now require a deliberate user action to cancel, mitigating this risk and improving security.
Original PR description
Mail link scanners often follow GET links in emails to check for malicious content. If the appointment cancelation link is a simple GET link, these scanners can inadvertently cancel the appointment. This commit converts the link into a POST form to ensure that cancellation requires a deliberate user action and is not triggered by automated scanners. opw-5722533
A bug was causing updates to Studio Approval Rules to inadvertently delete those rules from the database. This issue, identified during an upgrade, has been fixed by ensuring new records created by the system have a flag to prevent automatic deletion. This prevents data loss and ensures the stability of approval workflows.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records.
This update resolves a bug in Odoo's Web Studio where invisible fields would lose their visibility settings when toggling the 'Show Invisible Elements' option. The fix ensures that invisible field attributes are correctly retained and applied within the studio editor, improving user experience and data consistency.
Original PR description
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the…
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the "Show invisible Elements" checkbox - Click on the same field => The field is marked as invisible - Add an invisible condition => The invisible condition is lost (but still applied on the view) Cause of the issue ================== In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups). The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled. But this causes the actual value of the invisible attribute to be lost. Note that this also applies to the column_invisible attribute. Solution ======== If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute. We then use that value in the editor, when present. opw-6026971
This update automatically calculates and includes the necessary commission deductions for Swiss payroll reports (ELM) based on employee data. This ensures accurate reporting to tax authorities, addressing a previous reporting issue and improving compliance with Swiss regulations. The change impacts the Swiss payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#111143
This update corrects a bug in the MX CFDI invoice generation process. Previously, the required 'NumeroPedimento' information was missing, leading to invoice rejection. The fix ensures that the correct pedimento number is included in the generated CFDI documents, complying with Mexican tax regulations.
Original PR description
The numero pediemento is missing in invoices CFDI Step to reproduce: - in MX company with l10n_mx_edi_landing - create an invoice - add product with a custom number (with 2 spaces between number ranges) - Confirm and send The generated CFDI is missing the `InformacionAduanera` node and its `NumeroPedimento` attribute. Cause: Node and attribute are filled in the CFDI from the 'complementos_list'. Which is a copy of each base_line 'l10n_mx_cfdi_values'. The list was missing the `informacion_aduanera_list`. opw-5949684
This update resolves an issue where non-sales users were encountering an error when viewing product information. The fix allows all users to access product pricing details by bypassing access restrictions within the product view calculation. This ensures a smoother experience for all users.
Original PR description
Steps to reproduce: - Install sale_subscription. - Create a user with access to products but no access to Sales (e.g., base.group_user). - Log in as that user and open the Products Kanban or Form view. Observation: An Access Error is raised preventing the user from viewing the products. Cause: The UI evaluates fields and view modifiers (like invisible attributes) referencing restricted data. Since product_subscription_pricing_ids is restricted to Sales groups, non-sales users trigger an Access Error when the view or the compute method attempts to read it. Solution: n the _compute_display_subscription_pricing method, use .sudo() when accessing product_subscription_pricing_ids. This ensures that the display string can be computed for all users (including those without Sales access) by bypassing the access restrictions on the underlying pricing records. opw-5934036
This update resolves an issue where dropship orders between companies were not accurately reflecting delivered quantities. The fix adjusts how the system tracks moves during dropship transactions, ensuring the correct quantity is displayed on the sale order line. This ensures accurate order fulfillment and reporting across inter-company sales.
Original PR description
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check…
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check 'generate Sale Orders', 'generate purchase orders' and 'synchronize Deliveries to your receipts' then select a warehouse and a receipt operation type From company A - create a storable product - in the Purchase tab, set the company B as a vendor From company B - in the Purchase tab of the product, set company C as a vendor From company C - set a positive on hand quantity From Company A - create a SO for 1 quantity of your product - on the sale order line, unhide de route_id column and set it to dropship - confirm the SO and the linked PO From company B - on the SO created with company A as customer (you might need to remove the 'my quotations filter to find it), set the dropship route in the route_id column of the sale order line - confirm the SO and the linked PO From company C - confirm SO created with company B as customer - validate the delivery From company B - validate the dropship **Current behavior:** the quantity delivered on the sale order line is 0 **Expected behavior:** it should be 1 **Cause of the issue:** inside _compute_qty_delivered, we fetch the incoming and outgoing moves using _get_outgoing_incoming_moves() https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200 There, for the move of the dropship picking, inside the if condition, move._is_dropshipped_returned() will be True https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354 That's because the move is going from transit to transit https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195 So it will not be added to the outgoing moves and qty_delivered will stay 0. **fix** is_dropshipped_returned should not prevent the move to be added to the outgoing moves if is_dropshipped() is aslo true (i.e. it's a transit to transit move) opw-5023215
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report only includes partners with total invoices and credit notes exceeding 1,000 EUR, ensuring more accurate financial reporting. The calculation considers both invoices and credit notes, and also accounts for Part B transactions.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#101333
This update fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payroll data, which was resolved by recalculating vehicle information based on payroll line items. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update fixes an issue where repositioning PDF signs would cause multiple resize events, leading to unpredictable behavior. The change ensures only one resize listener is attached per sign, resulting in a more stable and reliable resizing experience for users. This improves the overall usability of the PDF sign functionality.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111146
This update fixes a misunderstanding regarding the date a W4 form is filed with an employer. The previous field incorrectly tracked when the form was filled out, rather than the actual filing date. This correction ensures accurate payroll processing for US HR payroll.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111213
3 changes
Resolved issues and error corrections
This update automatically calculates and transmits the necessary commission payments for Swiss payroll (ELM) declarations. Previously, this calculation was manual, and this change streamlines the process, ensuring accurate and timely reporting to tax authorities. This improves compliance and reduces the risk of errors related to commission calculations.
Original PR description
task-6050810
This update prevents the entire report cron process from stopping if a single report export fails. Now, the cron will continue to attempt exporting other reports, ensuring timely delivery of all necessary reports. This improves reliability and reduces potential data delays.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038
This update fixes an issue where currency rates were incorrectly calculated after Bulgaria transitioned to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. The fix ensures accurate currency calculations by using the correct 'RATE' value from the XML.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519