Daily updates from Odoo
Monday, March 23, 2026
155 changes
19 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 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 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
A technical issue preventing the generation of the Trial Balance report PDF has been resolved. The update corrects a formatting error in the report template, ensuring the PDF can now be successfully printed without errors. This improves the reliability of a key financial reporting tool.
Original PR description
Printing the PDF of the Trial Balance report raises a traceback. Steps to reproduce the error: - Install ``Accounting`` module - Go to Accounting > Reporting > Trial Balance > Click PDF Traceback: ```py AttributeError: 'AccountReportLineData' object has no attribute 'get' ``` https://github.com/odoo/enterprise/blob/ee5be988fd57b9b23265875fec7b42f2a761144f/account_reports/data/trial_balance_template.xml#L28 After Commit [1], line is ``AccountReportLineData`` object instead of disctionary. As a result, accessing line values using ``line.get(...)`` causes the traceback. [1]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420 sentry-7323693096
This update enhances the payroll system by expanding worker code searches to include DMFA and egov3 codes, in addition to display names. This ensures more accurate and complete worker code identification, improving payroll processing efficiency and data accuracy.
Original PR description
before when searching for worker code it only used display name. now it uses dmfa, egov3 codes. Task#6020172
This update resolves a technical issue that could cause errors when importing bank statements with multiple journals using different currencies. The fix prevents a redundant process from triggering a singleton error, ensuring smoother and more reliable CODA import for businesses operating with multiple currencies.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111361 Forward-Port-Of: odoo/enterprise#111101
This update clarifies potential errors (code 9004) that users might encounter when running the Odoo Instagram module. The change provides a helpful explanation to assist users in troubleshooting without needing to contact support. This improves the overall stability and usability of the Instagram integration.
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 resolves a problem where reports with annotations were failing to export correctly. The previous filtering process was redundant, and this change removes unnecessary date filtering, ensuring reports with annotations now export reliably. This improves the balance sheet report generation process.
Original PR description
[FIX] account_report: Unable to export Report with Annotations Following changes to the date filter in https://github.com/odoo/enterprise/pull/98695, the date options can be missing a date_from (For example, when using period type: "today"). The date were used to filter on the annotations to display during the period of the report. However, we already filter on those date when generating the annotations so this was redondant and can be safely removed. To reproduce: - Open the Balance sheet - Open the chatter of any account and post a message - Click on the "PDF" button to export the report
This update fixes a usability issue on mobile devices where a key button for loan calculations was hidden within a dropdown. The change ensures a smoother, more intuitive experience when creating new loans on smartphones and tablets, allowing users to easily access necessary features.
Original PR description
Forward-Port-Of: odoo/enterprise#110931 Forward-Port-Of: odoo/enterprise#110120
This update adjusts how Odoo refreshes its GST tokens, moving from automated scheduling to manual triggering. This change ensures compliance and reduces the risk associated with automatic token updates. The process is now controlled by specific actions within the system.
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 fixes an issue where portal users weren't able to view timesheets 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 portal users can access timesheets as intended.
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#111548
Forward-Port-Of: odoo/enterprise#107800This update ensures the 'To-Do' feature within Odoo Enterprise works reliably. Previously, uninstalling the 'To-Do' module could cause issues, as the feature remained active. This change guarantees that 'To-Do' is properly installed, resolving potential problems for users.
Original PR description
This commit backports the `project_enterprise_hr_todo` bridge module that ensures that `project-todo` is correctly installed in order to use the todo mail alias feature. Before, this requirement was not enforced so anyone uninstalling To-Do could experience some issue, as the feature would still be part the `project_enterprise_hr` module, even without `project_todo` installed. Forward-Port-Of: odoo/enterprise#109194
14 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 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 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 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
This update resolves issues related to how client IDs are formatted within the Odoo Enterprise payroll module (l10n_be_hr_payroll). Specifically, it adapts to a new naming convention for Client IDs, ensuring compatibility and preventing potential errors. The changes also include several bug fixes related to connection and configuration processes within the payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#111276
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 report accurately reflects the payment method selected during invoice creation, improving report accuracy for Mexican tax compliance.
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
7 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 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 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
This update resolves an issue where prompts within email templates weren't being evaluated correctly in version 18.4. The fix ensures that all prompt content is wrapped in a `<div>` tag, preventing errors and guaranteeing prompt evaluation during template previews. This improves the functionality of the AI composer feature.
Original PR description
Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element. Steps to…
Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element. Steps to reproduce: - Create a new email template. - Insert a prompt by using the '/prompt' command. - Type any prompt like 'Say Hello'. - Save the email template. - Click on preview. - The prompt isn't evaluated. The '_eval_ai_prompts' method creates a root element from the passed html content. When the passed content represents a single prompt container html element, the root will become that prompt container. The method will try to evaluate the prompt and replace the prompt container and then return the root. The returned root won't contain the evaluation of the prompt in this case because the whole root should be replaced by the evaluation given that there is no other elements. To fix this, the html content will always be wrapped in a `<div>` to avoid the need for replacing the whole root element.
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 payslip data, which was resolved by recalculating the data based on payslip 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 relaxes a restriction that previously prevented leave creation when payroll data was present for an employee. Now, leave can be created under specific conditions related to payroll impact and disability percentages, ensuring greater flexibility for HR teams. This change improves the usability of the leave management system.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
20 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 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 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 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
This update resolves an issue where cross-origin requests with the Range header were failing due to preflight checks. The change adds the necessary header to allow these requests to succeed, improving the reliability of external integrations. While future customization is considered, this fix addresses a specific, previously undetected problem.
Original PR description
Previously, specifying the Range header in a CORS request would result in a preflight failure even if cors was enabled on the route. It is sometimes desirable to allow querying ranges even in a CORS context. It may be desirable at some point in the future to allow controllers to customize their preflight responses more thoroughly, but considering this hasn't really be an issue before, it seems premature. Instead, this commit just adds the Range header to the Allow-Control-Allow-Headers response header to allow such requests to succeed. Forward-Port-Of: odoo/odoo#254805
This update fixes a technical error that prevented the generation of 281.10 reports for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payroll data, which was resolved by recalculating vehicle information using pay slip line IDs. 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 resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving invoice clarity for users. This impacts the Ke edition of Odoo Enterprise.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
This update resolves a recurring issue where the Italian POS printer would generate errors when the system was offline. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing errors and improving the user experience for Italian businesses using the POS module. This ensures reliable operation even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#110326 Forward-Port-Of: odoo/enterprise#105515
This update fixes a formatting issue in Odoo's XML files related to Danish VAT returns (OIOUBL21). The 'DK' prefix was missing, which is now added to the PartyIdentification text to ensure compliance with Danish tax regulations. This ensures accurate data transmission and avoids potential processing errors.
Original PR description
In this commit af94099c4d74e9c48251a1c1656e3ad11b9f8a70, we made a fix regarding OIOUBL21 XML files, but we forgot to add the 'DK' prefix for CVR nemhandel identifier. The format should be 'DK' + nemhandel_identifier_value. no-task Forward-Port-Of: odoo/odoo#254430
This update addresses a previous issue where exporting XML from bills resulted in incorrect customer and supplier information. The button has been removed for non-self-bill invoices to prevent customer confusion. This ensures data integrity during import processes.
Original PR description
Problem --------- Currently, in the bills list view, when you select bills > Print > Export XML; not-imported bills gets their customer and supplier party inverted. This is because the XML export of those trigger the XML computation which is not designed for bills but only for invoices or self-bills. For imported bills (coming from Peppols for example), we re-use the imported XML. Since XML export of created bills is not supported anymore. The button leaves customers confused as to why their partner are inverted in the XML. Solution --------- Don't show the "Export XML" if one or more move are selected for the import and don't compute the XML for bills that are not self-bills. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug in Odoo's testing framework was causing freezes due to an infinite loop. This has been resolved by switching from an array to a set data structure, preventing the framework from repeatedly accessing the same data and avoiding the loop. This ensures the stability of the Odoo system.
Original PR description
Problem: Triggering the `child_of` operator in the testing framework caused an infinite loop that froze Odoo. This occurred because the framework attempted to fetch all children of the root operand without accounting for already visited nodes, resulting in children being added indefinitely. Solution: Switched from using an `array` to `set` to prevent duplicate traversal. Task-6023290 Forward-Port-Of: odoo/odoo#255067 Forward-Port-Of: odoo/odoo#254857
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111439 Forward-Port-Of: odoo/enterprise#111290
This update ensures that all required address fields (street, city, zip, state, and country) are included when generating seller addresses on e-invoices for Viettel. This change is necessary to meet Viettel's EDI requirements and avoid potential invoice rejection issues, ensuring compliance and accurate reporting.
Original PR description
The seller address on e-invoices was missing some fields. This commit updates the logic to include street2, city, zip, state, and country when generating the seller address, ensuring full address details are provided in compliance with Viettel EDI requirements. task-6040875 Forward-Port-Of: odoo/odoo#254564
This update corrects a bug that was causing incorrect leave calculations within the holiday accrual process. The issue stemmed from an inconsistent field being used instead of the correct variable, which could lead to an infinite loop. This fix ensures accurate leave accruals and prevents potential errors.
Original PR description
## Issue Oblivion regarding community-239836 The field `leaves_taken` (which shouldn't be accessed from the `_process_accrual_plans` method because it is inconsistent/can lead to infinite loop, see the related PR explanation) is used instead of the variable `leaves_taken`. robodoo up to saas-18.4 included Forward-Port-Of: odoo/odoo#253076
3 changes
Resolved issues and error corrections
This update fixes a bug that prevented users from adding reactions to messages within the 'mail_group' module in Discuss. The fix ensures the 'add reaction' button isn't displayed for message types that don't inherit from the standard message structure, improving stability and usability.
Original PR description
Steps to reproduce: - Install the mail_group module - Open Discuss - Go to the History tab - Add a reaction on a message that has model mail.group - Throws an error The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`. community: https://github.com/odoo/odoo/pull/218615 Task-5098050
This update resolves an issue where the CFDI payment method '99' was incorrectly displayed as 'False' in reports. The fix ensures that '99 - Por definir' is shown accurately, aligning with Mexican tax regulations. This ensures correct reporting for invoices generated with the mx company.
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 ensures that changes to a subscription's salesperson are automatically reflected for all associated contacts. Previously, updates only applied to the company partner, leading to inconsistencies. This change improves data accuracy and reduces the need for manual updates, streamlining the portal experience.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271 Forward-Port-Of: odoo/enterprise#108339
14 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 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 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 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
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 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 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 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 corrects a technical issue in how Odoo processes top-up payments for UK accounts. The data structure for UK accounts differs from the EU, requiring a change to the system's location data retrieval. This ensures accurate payment processing for UK customers.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground
This update ensures the 'mark as complete' button is always visible when closing a return flow, regardless of whether the user is using the API or a manual upload. This resolves an issue where the button was hidden for certain localization setups and temporary API connection problems, allowing users to consistently finalize return processes.
Original PR description
When a flow is already started, the button "mark as complete" on returns was invisible. This is an issue for some localizations that don't handle the flow when the API connection is not desired by the user. Another use case, for example, is the API connection is down temporarily, the user manually uploads it on the website, then wants to close the started return.
This update relaxes a restriction that previously prevented leave creation when payroll data was active for an employee. Now, leave can be created under specific conditions – primarily when payroll impact is false, or when continued and disability payments are both 100% if payroll impact is true. This improves flexibility in managing employee time off.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
7 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
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 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 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 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
This update prevents the entire reports cron job from stopping if a single report export fails. Previously, an error would halt the entire process. Now, the cron will continue to attempt exporting other reports, ensuring a more reliable and complete report generation.
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 Forward-Port-Of: odoo/enterprise#105191
This update fixes a bug related to currency rate calculations for Bulgaria. After the country switched to the Euro, the system was incorrectly using reversed rates from the data source. The change adjusts the parsing process to use the correct 'RATE' value, ensuring accurate currency conversions.
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 Forward-Port-Of: odoo/enterprise#111275
3 changes
Resolved issues and error corrections
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
This update resolves a minor issue with a message displayed in the HR payroll documents. The fix ensures accurate and consistent reporting, preventing potential confusion or errors in payroll processing. This change improves the reliability of the documents generated for employees.
Original PR description
Task#5980045