Daily updates from Odoo
Tuesday, March 24, 2026
144 changes
11 changes
Resolved issues and error corrections
This update fixes a bug where right-clicking on keypad buttons incorrectly triggered a long-press action. This issue stemmed from the way the context menu was handled, leading to unintended behavior. The fix ensures that only left-button actions are recognized, improving the overall user experience.
Original PR description
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were…
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1". In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed. Solution: we should never have considered anything else than left-button actions anyways. [1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb [2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185 [3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28 [4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3 task-6055182 Forward-Port-Of: odoo/enterprise#111490
This update fixes a technical error that occurred when users tried to take pictures without an IoT device connected to a quality control point. The fix adds a check to ensure a device is set, preventing a system error and guiding the user to properly configure the control point.
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 Forward-Port-Of: odoo/enterprise#110615
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page due to formatting. The change optimizes the report layout to ensure it consistently uses only one page for standard reports, improving readability and reducing unnecessary PDF sizes. This primarily impacts reports for Belgian companies.
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 Forward-Port-Of: odoo/enterprise#111310
This update ensures the 'Mark as Complete' button is always visible when a return flow has been started, regardless of the user's connection preferences or temporary API issues. This resolves a previous issue where the button was hidden, preventing users from finalizing returns, particularly in localized versions or during API downtime.
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. Forward-Port-Of: odoo/enterprise#111600
A technical issue causing a tour to fail has been resolved. This change adjusted the company referenced within the tour, addressing a previously unreplicable access rights problem. The fix ensures the tour now runs correctly, improving the user experience.
Original PR description
Before this commit, the tour `hr_referral_utm_campaign_tour` was failing because of some weird access rights issues. The issue did not seem to be reproducible in local with similar condition. This commit changes the company used in that tour runbot issue 239152
This update fixes a situation where the Gemini AI feature would sometimes fail to respond to users, appearing as a system error. The fix automatically retries the request with a slightly increased processing limit and, after three attempts, informs the user of the failure. This ensures a smoother and more reliable experience with the AI functionality.
Original PR description
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a…
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a function call or a message to the user by the LLM. Prior to this commit, when this occured, we didn't perform any explicit handling. We would always just return what the LLM responded with, which when empty would be nothing. UX wise, it would seem like something broke because the user would basically get no reply. In this commit, we add a retry mechanism in `_request_llm_google` of `llm_api_service.py`, where if we get no response, we increase the thinking budget of the next request to 512 and try again. 512 tokens were chosen completely arbitrarily - anecdotally, the model should use around 300 thinking tokens for its tasks so 512 should be enough. After 3 unsuccessful tries, we send a failure response to the user. Task-5959805 Forward-Port-Of: odoo/enterprise#111228 Forward-Port-Of: odoo/enterprise#108755
This update fixes an issue where subscription quotations weren't displaying correctly in the portal. Recent changes caused orders to always redirect to a general subscription page, which wasn't suitable for draft or sent orders. Now, draft and sent orders are correctly directed to the specific order details page, improving the user experience.
Original PR description
Version: - saas~19.2 Steps to reproduce: - Create a subscription quotation. - Open it from the portal. Issue: - The portal view of the subscription quotation is not displayed correctly. Cause: - After recent changes, subscription orders were always redirected to `/my/subscriptions/` route. - This route renders the `subscription_portal_template`, which is not suitable when the order is still in draft or sent state. Solution: - If the subscription order is in draft or sent state, redirect the user to `/my/orders/<order_id>` instead. task-5966871
This update corrects a small, unintended message appearing in the documents generated for employee payroll. This ensures that all payroll documents are clear and accurate, providing employees with the correct information. The change is a simple fix to improve document clarity.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update corrects a bug where archived employee versions were incorrectly included in pay run reports. The fix filters out archived employees from the pay run domain, ensuring accurate payroll calculations. This prevents potential errors and ensures data integrity for employee compensation.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437 Forward-Port-Of: odoo/enterprise#110527 Forward-Port-Of: odoo/enterprise#110073
This update resolves an issue where users were directed to the wrong document form view when configuring PEPPOL document syncing settings. The change adds a dedicated Kanban view for PEPPOL documents within the settings, ensuring users can easily manage their PEPPOL documents. This improves the user experience and streamlines the configuration process.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111765 Forward-Port-Of: odoo/enterprise#111341
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were inaccessible through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users. This improves the usability of the Documents app.
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#111715 Forward-Port-Of: odoo/enterprise#111290
11 changes
Resolved issues and error corrections
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 crash and now guides users to add a device before attempting to capture an image, ensuring a smoother user experience.
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 Forward-Port-Of: odoo/enterprise#110615
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page due to formatting. The change optimizes the report layout to ensure it consistently appears on a single page for standard reports, improving readability and reducing unnecessary printing.
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 Forward-Port-Of: odoo/enterprise#111310
This update ensures the 'Mark as Complete' button is always visible when closing a return flow in Odoo, regardless of whether the API connection is active. This resolves an issue where the button was hidden for users relying on manual uploads, improving usability for all 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. Forward-Port-Of: odoo/enterprise#111600
This update corrects a technical issue impacting UK users' top-up payments via Stripe. The system previously relied on outdated data location information, which has now been updated to align with the current UK account payload structure. This ensures accurate processing of UK top-up transactions.
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 Forward-Port-Of: odoo/enterprise#111588
This update corrects a bug where text fields in Odoo Sign PDFs were incorrectly displayed as checkmarks instead of the entered text. The issue stemmed from an incorrect interpretation of Appearance State tags within standard text fields. This change ensures text fields accurately reflect the user's input when generating signable PDFs.
Original PR description
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often…
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field). - Upload this PDF to the Sign app. **Current behavior:** The text field's string value is ignored and replaced with a checkmark (✓). **Expected behavior:** The text field should correctly render the string value that the user entered. **Cause of the issue:** In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713). However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons. **Solution:** This PR fixes the issue safely for stable versions across two commits: [REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit. [FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. Task: 6018260 Forward-Port-Of: odoo/enterprise#110292
This update corrects a minor typo in the industry_fsm_report module's view definitions. The change ensures accurate reporting functionality related to project tasks. This fix prevents potential inconsistencies in data displayed within the reporting system.
Original PR description
the view name is incorrect and already used for this view https://github.com/odoo/enterprise/blob/60e9e0f3232c9cd1e9675cb2e5c4b054dc57bbda/industry_fsm_sale/views/project_task_views.xml#L358 Forward-Port-Of: odoo/enterprise#108862
This update resolves a bug where users accessing the Enterprise version of Odoo through a specific domain were incorrectly redirected to another domain, preventing them from viewing their documents. This change ensures that the documents smart button correctly directs users to the appropriate domain for accessing their files, improving usability for all users.
Original PR description
Steps to reproduce:
- Have two domains for your database (".odoo.com" and ".example.com")
- set the ".example.com" domain as your web base url
- login on the ".odoo.com" domain, go on an employee and click the documents smart button
-> you cannot see any documents because you are redirected on the ".example.com" domain on which you are not connected
opw-5857914
Forward-Port-Of: odoo/enterprise#107384This update corrects a small, non-critical message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting for HR and payroll processes. This change does not impact functionality or user experience.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update resolves a technical issue within the Odoo Enterprise system by updating how currency rates are accessed. The change replaces an older method with the recommended approach, ensuring more reliable and consistent configuration. This improves the stability and performance of the currency rate functionality.
Original PR description
https://github.com/odoo/odoo/pull/223180 removes the `get_param` method from `res.config_parameter`, which was used in the `currency_rate_live` module. This commit replaces it with the `get_str` method, which is the recommended way to retrieve configuration parameters in Odoo. No task ID
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 BNB XML data, leading to inaccurate unit conversions. The fix ensures the correct currency rates are used, maintaining accurate financial reporting.
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
This update resolves a bug where custom snippets created in the website builder wouldn't display their dynamic content in the preview. The fix ensures that dynamic content is correctly reflected when previewing custom snippets, addressing a visual inconsistency and improving the user experience. This change was necessary following a recent website builder refactor.
Original PR description
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are…
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet. This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview. Steps to reproduce: - Open website builder - Add a dynamic snippet (for example "Events") - Save the snippet as a custom snippet - Click on "Custom" snippet category - Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5427353 Forward-Port-Of: odoo/enterprise#110696 Forward-Port-Of: odoo/enterprise#108912
6 changes
Resolved issues and error corrections
This update prevents the entire report export cron job from stopping if an error occurs during a single report generation. Previously, a single failure would halt the entire process. Now, the cron will continue to attempt to export other reports, improving reliability and ensuring timely report delivery.
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#111602 Forward-Port-Of: odoo/enterprise#105191
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. This change ensures correct currency calculations for Bulgarian transactions.
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
This update resolves an issue where users were directed to the wrong document form view when configuring Peppol document synchronization settings. The change adds a dedicated Kanban view within the settings, ensuring users can easily manage their Peppol documents. This improves the user experience and streamlines the document synchronization process.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111712 Forward-Port-Of: odoo/enterprise#111341
This update fixes a misunderstanding regarding the W4 form filing date in the US payroll system. The change clarifies that the field represents the date the W4 is submitted to the employer, not the date it's initially completed by the employee. This ensures accurate payroll processing and compliance.
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 corrects a small, non-critical message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting for HR and payroll processes. This change does not impact functionality or user experience.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update resolves an issue where users could inadvertently create 'Requested Documents' instead of folders when syncing Peppol documents through the accounting settings. To avoid a confusing folder location in My Drive, the ability to create or edit documents within the settings has been disabled, ensuring the correct document type is created.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736 Forward-Port-Of: odoo/enterprise#111761
17 changes
Resolved issues and error corrections
This update prevents the entire reports cron job from stopping if an individual report export fails. Previously, a single error would halt the entire process. Now, the cron will continue to attempt exporting other reports, improving reliability and ensuring all reports are eventually generated.
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#111602 Forward-Port-Of: odoo/enterprise#105191
This update resolves an issue where removed fields from the website contact form were still appearing in the associated project tasks. The change ensures that unset data is no longer displayed, providing a cleaner and more consistent task view for users. This was caused by a recent update to how partner data was added to task descriptions.
Original PR description
# How to reproduce - Add a contact form to your website - Make it so the contact form creates a task on submit - Remove some field from the contact form, but no the email (ex: Phone) - Fill in the contact form; the email must be from one of the existing partners - Submit the form and go look at the task in the project application # The problem The fields removed from the form are still present in the task's description (ex: partner_phone: False) # Why This commit (https://github.com/odoo/odoo/commit/7d0660e034f3be1b92869c266dc2cfb0bc6b6941) changed the way the partner's data was added to the description. When adding that data, it does not check if it exists before hand and instead adds a default value if not found. opw-5920816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252848
This update fixes an issue where configuring PEPPOL document syncing incorrectly directed users to a document form instead of the intended Kanban view. The change ensures users are presented with the correct Kanban view when setting up PEPPOL document synchronization, streamlining the configuration process. This improves usability and efficiency.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111712 Forward-Port-Of: odoo/enterprise#111341
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. This change ensures correct currency calculations for Bulgarian transactions.
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
This update resolves an issue where users without sales permissions were encountering an error when viewing product information. The fix allows all users to access product subscription pricing data 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 Forward-Port-Of: odoo/enterprise#108265
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a truncated unit price for discount calculations, ensuring accurate decimal handling and successful invoice transmission. This prevents errors related to discrepancies in decimal precision.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
This update fixes a misinterpretation of the W4 filing date field in the US payroll module. The change clarifies that the field represents the date the W4 is submitted to the employer, not the date it's initially completed by the employee. This ensures accurate payroll processing and compliance.
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 fixes an issue where vendor codes and names weren't consistently updating in purchase order descriptions. The underlying system logic was flawed, leading to incorrect descriptions after switching between a sales order and a purchase order. The fix ensures accurate vendor information is always reflected in the PO description.
Original PR description
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name…
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name - Put Dropship as the route for the product to create a PO on a SO confirmation - Create a SO with that product - Confirm the SO and go to the PO - Change the vendor in the SO The problem : The Vendor Code and/or Vendor Name does not change correctly in the product description Why : The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user. This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions. It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method. The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change. opw-5888233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254969 Forward-Port-Of: odoo/odoo#247330
This update corrects a small, non-critical message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting of payroll information. This change improves the overall quality and clarity of the documents.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update ensures that changes to a subscription's salesperson are automatically reflected on all associated contacts. Previously, updates only applied to the main company partner, leading to inconsistencies. This change improves data accuracy and reduces the need for manual updates, streamlining the sales process.
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
This update resolves an issue where users couldn't add reactions to messages using the 'mail.group' model. The fix hides the reaction button for these message types, ensuring proper functionality across all discussion channels. This improves the overall stability and usability of the Discuss feature.
Original PR description
*= im_livechat, portal, test_discuss_full **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` •…
*= im_livechat, portal, test_discuss_full **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. https://github.com/odoo/odoo/blob/d12c1e07727f9b04cd2be2e7dac1ec3af49cb637/addons/mail/models/mail_message.py#L579 Desired behavior after PR is merged: This PR fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as mail.group. enterprise: https://github.com/odoo/enterprise/pull/111271 Task-5098050 [Reference](https://github.com/user-attachments/assets/aa2c4251-fd1f-4734-a62c-9fc80dd5f587) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218615
This update resolves a bug preventing users from adding reactions to messages within the Discuss feature when using the mail_group module. The fix ensures that the 'add reaction' button is only displayed for messages with the correct underlying data structure, improving usability and preventing errors.
Original PR description
* = test_spreadsheet_edition 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 Forward-Port-Of: odoo/enterprise#111271
This update corrects a bug where presence status information wasn't updating correctly after changes to related records like holiday schedules. The fix ensures that presence status is refreshed accurately, preventing outdated information from being displayed to users. This improves the reliability of real-time presence tracking.
Original PR description
After sending a presence notification, `_send_status_updated_notification` leaves `im_status` cached on the user/guest record. If a related model that affects `im_status` (such as `hr.leave`) is modified afterwards in the same transaction, the ORM has no declared dependency on it and will not invalidate the cache. Subsequent reads then return the stale value. breaking PR: https://github.com/odoo/odoo/pull/249314 runbot-242076 Forward-Port-Of: odoo/odoo#255361
This update fixes a test failure related to email notifications within the Google Calendar and Mail modules. The previous test incorrectly checked for empty timeout emails, leading to false positives. Now, tests verify that no emails are sent for specific messages, regardless of recipient information, ensuring more reliable test results.
Original PR description
No need to always check the timeout email_to always contains formatted emails. task-5152917 Forward-Port-Of: odoo/odoo#254306 Forward-Port-Of: odoo/odoo#230766
This update ensures that all attendees of appointments – internal users and organizers – receive booking confirmations, regardless of whether their calendars are synced. Previously, notifications were limited to those directly connected via email, leading to a less comprehensive communication experience. This change improves user awareness and meeting coordination.
Original PR description
In [1] we prevented cancelation emails from being sent when the booking was synced via google or outlook calendar. However this means even followers who would not be notified by the mail provider (not assisting to the meeting) would not be notified. As well as the organizer who is doing to booking/cancelling from the perspective of the mail provider, as the meeting is created from their account. Instead we should keep sending the "appointment booked" template in all cases as it is only followed by internal users to whom it is always relevant. As for cancelation templates, it should stil be sent to internal users. Partners of the meeting however need not be notified and may be unsubscribed if syncing is enabled, as cancellation typically only happens once. task-5152917 [1]: https://github.com/odoo/enterprise/pull/60913 Forward-Port-Of: odoo/enterprise#110916 Forward-Port-Of: odoo/enterprise#96638
This update fixes a crash that occurred when opening tax reports without a defined return type. The system now automatically uses the company's tax periodicity, ensuring reports open reliably. This improves the overall stability and usability of our tax reporting functionality.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150
This update resolves an issue where users could inadvertently create 'Requested Documents' instead of folders when syncing Peppol documents through the accounting settings. To avoid a confusing 'My Drive' folder creation, the ability to create or edit documents in the settings has been disabled, aligning with a previous fix.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736 Forward-Port-Of: odoo/enterprise#111761
12 changes
Resolved issues and error corrections
This update fixes an issue where currency rates from the Bulgarian National Bank (BNB) were incorrectly processed, leading to reversed unit-to-EUR and EUR-to-unit calculations. The change adjusts the data parsing process to accurately use the standard 'RATE' value from the XML feed, ensuring correct currency conversions for Bulgarian operations.
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
This update fixes an issue where configuring PEPPOL document sync settings incorrectly directed users to a document form instead of the intended Kanban view. Now, users will correctly see the document Kanban view when setting up PEPPOL document synchronization, streamlining the configuration process. This ensures a smoother and more intuitive experience for managing PEPPOL documents.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111341
This update fixes a misunderstanding regarding the W4 form filing date in the US payroll system. The change clarifies that the field represents the date the W4 is submitted to the employer, not the date it's initially completed by the employee. This ensures accurate payroll calculations and compliance.
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 fixes an issue in Web Studio where invisible fields weren't consistently hidden based on user access. Previously, toggling the 'Show Invisible Elements' checkbox didn't always retain the intended invisibility settings. The fix ensures that invisible fields remain hidden when the user lacks access, improving the user experience and data consistency within the studio.
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 Forward-Port-Of: odoo/enterprise#111299
This update loosens restrictions on creating leave for employees with Swiss payroll, allowing for more flexible leave management. Specifically, it now permits leave creation even when payroll impacts are present, provided certain percentage conditions are met, ensuring accurate leave tracking within the Swiss payroll system. This change improves usability and reduces potential disruptions for HR teams.
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
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report accurately filters partners based on a €1,000 turnover threshold, considering both invoices and credit notes. This ensures more reliable financial reporting.
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#111503 Forward-Port-Of: odoo/enterprise#101333
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent due to a failure to convert dates from UTC to the user's local timezone. Now, all times are correctly formatted for each user, improving data accuracy and user experience.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update prevents the entire reporting cron process from stopping if a single report export fails. Previously, an error would halt all subsequent exports. Now, the cron will continue to attempt sending other reports, improving reliability and ensuring timely report delivery.
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#111602 Forward-Port-Of: odoo/enterprise#105191
This update resolves an issue where users without sales permissions were encountering errors when viewing product information within the Odoo interface. The fix allows all users to access product subscription pricing data by bypassing access restrictions, ensuring a smoother experience for all users regardless of their role.
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 Forward-Port-Of: odoo/enterprise#108265
This update corrects a small, technical issue with a message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting of payroll information. This change improves the overall quality and reliability of the payroll documentation.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update resolves a bug where users could incorrectly create 'Requested Documents' instead of folders when syncing PEPPOL documents. To avoid further complications with folder placement, the ability to create or edit folders within the settings has been removed, aligning with a previous fix. This ensures accurate PEPPOL document synchronization.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736
This update addresses a security vulnerability where automated systems (like Mail Defender) could unintentionally cancel or reschedule appointments through links in emails. The system now uses a form instead of a direct link, preventing these automated actions. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#110795 Forward-Port-Of: odoo/enterprise#79831
26 changes
Resolved issues and error corrections
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition of Odoo. The fix ensures that charts displaying location-based information are now rendered correctly, improving the accuracy and reliability of these reports. This primarily impacts users relying on charts that visualize data by region or location.
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 visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings 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 resolves a problem where tours on the website sale subscription pages weren't loading translations correctly, particularly with newer Chrome versions. The fix introduces a temporary step to ensure translations start loading promptly, preventing delays and interruptions in the tour experience. This ensures consistent and accurate tour guidance for users.
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 corrects an issue where incorrect folio numbering occurred when a Customer Fiscal Account (CAF) wasn't set up. The fix ensures that folios are generated correctly, avoiding negative numbering and preventing performance issues related to repeated sequence searches. This improves data accuracy and stability for Chilean accounting.
Original PR description
`l10n_cl_edi` overrides `account.move._get_last_sequence()` to ensure the folio belongs to an available in-use CAF. When no CAF exists at all, `l10n_latam.document.type._get_start_number()` returns 0 and the fallback builds a previous sequence using start_nb - 1. Formatting -1 as `:06d` yields “-00001”, which then propagates to “FAC -00002”, “-00003” and corrupts the sequence chain. In addition, returning an invalid “last sequence” may force `sequence.mixin` to search for a free number under the UNIQUE constraint by retrying increments inside a savepoint and rolling back on UniqueViolation, which is costly when many values are already taken see [ _locked_increment()](https://github.com/odoo/odoo/blob/18.0/addons/account/models/sequence_mixin.py#L352). Now we only reset to the CAF start when an in-use CAF actually exists (start_nb > 0). opw-5918758 Forward-Port-Of: odoo/enterprise#108909
This update allows superuser administrators to unlink existing salary rules and parameters within the HR Payroll module. This provides greater flexibility for managing payroll configurations and resolving potential conflicts. Previously, this action was restricted, creating a bottleneck for administrators needing to adjust payroll settings.
This update resolves a common error (code 9004) users experience when using the Instagram integration in Odoo. The changes provide clear guidance to help users quickly identify and troubleshoot network or file-related issues, reducing support requests. This improves the overall stability and usability of the Instagram module.
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 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 timesheet 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 resolves a potential error in the bank statement import process for Odoo Enterprise when handling multiple journals with different currencies. The fix prevents a 'singleton error' by streamlining the data retrieval process, focusing only on the necessary IBAN and currency information.
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#111560 Forward-Port-Of: odoo/enterprise#111101
This update corrects a problem where the calculation of employee appraisal dates was unreliable. The fix ensures appraisal dates are correctly determined based on company settings related to appraisal plans. This improves the accuracy 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#111345 Forward-Port-Of: odoo/enterprise#111265
This update ensures the 'To-Do' feature within the project management system functions reliably. Previously, uninstalling the 'To-Do' module could cause issues, but this change guarantees the necessary components are installed, preventing unexpected problems and improving user experience.
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#110593 Forward-Port-Of: odoo/enterprise#109194
This update fixes a technical error that occurred when users tried to take pictures without an IoT device connected to a quality control point. The fix prevents a system crash and guides users to properly set up the IoT device before proceeding, ensuring a smoother workflow.
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 Forward-Port-Of: odoo/enterprise#110615
This update automatically adds missing rows to pivot tables when a group by field causes the layout to shift, preventing errors. Previously, users would encounter confusing '#SPILL' errors and revert changes. Now, the system intelligently adjusts the layout and displays a clear error message if needed, improving usability.
Original PR description
When you update a pivot and you add a group by such that the pivot no longer fits in the available space, the formula becomes a #SPILL error. Users tend to think they messed up something and revert the change. They probably don't know they can hover the cell to see the error message. With this commit, missing headers are automatically added up to a reasonable amount. If it's above the threshold, it opens the error message to make it obvious. task-6023969
This update resolves a warning message appearing during time off processing. The fix removes a redundant check for blocked payslips related to leave, preventing the warning from triggering. This ensures smoother and more reliable time off calculations.
Original PR description
. Remove the check for blocked payslips corresponding to the leave to avoid triggering the warning. task-6044925
This update resolves an issue preventing the successful installation of the Helpdesk Stock module when auto-installation is skipped. The fix ensures that the necessary Sale Stock module is installed, allowing users to correctly utilize Helpdesk Stock's features. This improves the overall stability and usability of the Enterprise suite.
Original PR description
This commit fixes the error when installing helpdesk_stock with auto_install skipped which prevents the module `sale_stock` from being installed. The error is introduced by this PR: https://github.com/odoo/enterprise/pull/103051 To reproduce: install the module with `--skip-auto-install`. The fix: Change the module dependencies to include `sale_stock` to be able to access `sale_order.picking_ids` Runbot error links: https://runbot.odoo.com/odoo/error/242083
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page due to formatting. The change optimizes the report layout to ensure it consistently uses only one page for standard reports, improving readability and reducing unnecessary PDF file sizes. This primarily impacts reports for Belgian companies.
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 Forward-Port-Of: odoo/enterprise#111310
This update fixes a potential issue where the Gemini AI feature would sometimes return empty responses to users, creating a confusing 'no reply' experience. The fix automatically retries the request with a slightly increased budget and, after three failed attempts, gracefully informs the user of the failure. This ensures a more reliable and consistent AI experience.
Original PR description
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a…
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a function call or a message to the user by the LLM. Prior to this commit, when this occured, we didn't perform any explicit handling. We would always just return what the LLM responded with, which when empty would be nothing. UX wise, it would seem like something broke because the user would basically get no reply. In this commit, we add a retry mechanism in `_request_llm_google` of `llm_api_service.py`, where if we get no response, we increase the thinking budget of the next request to 512 and try again. 512 tokens were chosen completely arbitrarily - anecdotally, the model should use around 300 thinking tokens for its tasks so 512 should be enough. After 3 unsuccessful tries, we send a failure response to the user. Task-5959805 Forward-Port-Of: odoo/enterprise#111228 Forward-Port-Of: odoo/enterprise#108755
This update resolves an issue where the 'Appraisal' survey type was not appearing as an option when creating a new survey. The fix replaces a technical code change to ensure the correct survey type selection is available, improving the user experience for creating appraisal surveys.
Original PR description
How to reproduce: - install hr_appraisal_survey - log in as admin and create a new survey The selection for "Appraisal" survey type is missing in the survey form. We solve the issue by replacing the "append" in the compute method by an affectation. Task-6009719
This pull request addresses a minor typo and improves the user interface of the Odoo Enterprise payroll module. Specifically, a corrected spelling and updated styling (using `<label>` instead of `<span>`) were implemented to ensure consistency and a better user experience. The changes also included alignment adjustments for a distance input field.
Original PR description
- Correct typo "reimboursed" -> "reimbursed" - Replace `<span>` labels by `<label>` to match style (bold, arrow cursor) - Add narrow field class to distance input so that it is aligned with the field bellow Task: 5952495
This update simplifies the calendar event interface by removing a redundant button and optimizing its layout. The change addresses a recent update to the calendar event form, streamlining the user experience and improving efficiency. This ensures a cleaner and more intuitive way to manage calendar events.
Original PR description
Removing smart button as new field: `res_record` is added in the form view of calendar event. Also, changing the location of `action_view_sale_order` Task-5106718
This update resolves an issue where only administrators could delete salary rules within the payroll module. Now, superusers (with appropriate permissions) have the ability to remove outdated or incorrect salary rules, improving payroll management flexibility. This change enhances administrative control over payroll configurations.
This update optimizes the calculation of payroll figures by limiting the scope of certain computations to currently active payslips. This change prevents unnecessary processing of older, closed payslips, improving system performance and reducing potential data inconsistencies. It addresses a previous issue that could have impacted a large number of records.
Original PR description
Before this commit, `_compute_basic_net` was not limited to specific payslips, potentially affecting thousands of records and even more of `hr.payslip.line` records. This commit restricts the compute to ongoing payslips. task-6022499 Forward-Port-Of: odoo/enterprise#111437 Forward-Port-Of: odoo/enterprise#110069
This update resolves an issue where employee document filenames were incorrectly displayed as file sizes instead of the actual document names. The fix ensures that the correct document filename is shown when uploading files to the employee's personal information, improving data accuracy and usability. This was a minor bug fix related to the Payroll module.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install Payroll module 2. Go to any Employee > Personal Tab 3. In the Documents section, upload any file in the Sim Card Copy field 4. Save the record Observation: ---------------------------------- File name changed to file size Issue: ---------------------------------- The `filename` attribute was missing in the view, preventing the proper computation of the document filename. Solution: ---------------------------------- Add computed fields for the document filenames and Set these fields in the `filename` attribute of the corresponding binary fields in the view Related Community PR: https://github.com/odoo/odoo/pull/249024 opw-5905408
This update fixes a bug where right-clicking on keypad buttons incorrectly triggered a long-press action. This issue stemmed from the system misinterpreting the context menu opening as a long-press. The fix ensures that only left-button actions are recognized, improving the user experience.
Original PR description
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were…
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1". In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed. Solution: we should never have considered anything else than left-button actions anyways. [1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb [2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185 [3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28 [4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3 task-6055182 Forward-Port-Of: odoo/enterprise#111528 Forward-Port-Of: odoo/enterprise#111490
This update enhances the accuracy of worker code searches within the Odoo Enterprise system. Previously, searches relied solely on display names, leading to potential mismatches. Now, the system incorporates DMFA and egov3 codes for a more reliable and comprehensive search experience.
Original PR description
before when searching for worker code it only used display name. now it uses dmfa, egov3 codes. Task#6020172 Forward-Port-Of: odoo/enterprise#110100
This update corrects a bug in the Social Media Clicks digest KPI calculation. A recent change removed tracking data previously used, and this fix adapts the KPI computation to the new UTM reference logic. This ensures the digest KPI accurately reflects social media click data, even with the updated tracking system.
Original PR description
Steps to reproduce the error : ============== 1. Go to Settings -> Technical -> Digest Emails 2. Open any Digest record 3. Click `Send Now` or `Test` -> A traceback occurs. Issue ============= A…
Steps to reproduce the error : ============== 1. Go to Settings -> Technical -> Digest Emails 2. Open any Digest record 3. Click `Send Now` or `Test` -> A traceback occurs. Issue ============= A previous refactor of Social UTM tracking: - removed `source_id` from social.post and now stores post reference directly in link.tracker (utm_reference) - removed `utm_medium_id` from social.account The "Social Media Clicks" digest KPI computation still relied on `social.post.source_id` and `social.account.utm_medium_id`. Since these fields were removed, the SQL query fails with a “column does not exist” error. Fix ============= Update the KPI computation to adapt to the new utm_reference logic Note ============ If a post is posted across all companies, its clicks are visible to all companies. This is an expected limitation of the new utm_reference logic See https://github.com/odoo/enterprise/commit/0058e409cd9ae4868bc8ed974f34f29d26c1f7df for more details task-5960183 Forward-Port-Of: odoo/enterprise#108728
This update ensures the 'mark as complete' button is always visible when closing returns, regardless of whether the API connection is active. This resolves an issue where the button was hidden for users relying on manual uploads, improving usability for all return closure workflows.
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. Forward-Port-Of: odoo/enterprise#111600
7 changes
Resolved issues and error corrections
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the data source, leading to inaccurate unit conversions. The change ensures correct rate calculations by using the primary 'RATE' value from the XML data.
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
This update fixes a potential issue where a user could indirectly change an employee's work email through salary configuration. Now, the work_email field is protected and will not be reset if the employee is linked to a user, ensuring data consistency and preventing unintended email updates.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974,the employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382
This update corrects a small, unintended message appearing in the documents generated for employee payroll. The fix ensures a cleaner and more professional presentation of these important documents. This change improves the overall user experience and consistency of our HR reporting.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update resolves a technical error that prevented the generation of 281.10 reports for Belgian payroll. The fix ensures accurate report creation by adjusting how the system identifies vehicle information, avoiding a previous traceback. This improves the reliability of payroll reporting.
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#111506
Forward-Port-Of: odoo/enterprise#110860This update resolves a technical issue that caused warnings during the initial setup of reports on some migrated Odoo databases. Specifically, it adds a backup method to identify accounts using their code when XMLIDs are missing, ensuring reports load correctly without errors. This improves the reliability of the reporting process.
Original PR description
Description of the issue this commit addresses: On some migrated BE databases, account template refs a4121/a4521 are missing as XMLIDs. l10n_be_reports then fails to recover partner/reconcile account refs and logs warnings during post-init load. --- Desired behavior after this commit is merged: This commit adds a fallback in BE report chart template data to resolve a4121/a4521 by account code when XMLIDs are missing, preventing recovery warnings while keeping normal XMLID behavior unchanged. --- runbot-[233845](https://runbot.odoo.com/odoo/runbot.build.error/233845)
This update resolves an issue where uploading documents to the 'All' folder in the Documents app prevented them from being viewable through the bridge interface. The fix ensures that 'All' folder uploads 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#111537 Forward-Port-Of: odoo/enterprise#111290
This update resolves an issue where users were directed to the wrong document form view when configuring PEPPOL document syncing settings. The change adds a dedicated Kanban view for PEPPOL documents within the settings, ensuring users can easily manage their PEPPOL documents. This improves the user experience and streamlines the configuration process.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111712 Forward-Port-Of: odoo/enterprise#111341
5 changes
Resolved issues and error corrections
This update corrects a small, unintended message appearing in the documents generated for employee payroll. This ensures a cleaner and more professional presentation of payroll information for employees and managers. The change improves the overall user experience.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update fixes a potential issue where an employee's work email could be unintentionally modified when linked to a user. This change ensures that the work_email remains consistent, preventing indirect email manipulation and improving data integrity. It addresses a bug related to offer updates.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382
This update corrects a problem where translations were not consistently appearing in the Chilean VAT reporting module (l10n_cl_edi_factoring). The change simplifies the code to ensure accurate translation lookup, specifically addressing issues on Ubuntu Jammy and Debian Bookworm. This ensures correct VAT reporting functionality.
Original PR description
This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951
This update corrects a technical issue where FedEx's VAT number limitations caused problems with certain customer records, particularly those using Swiss VAT formats. The change ensures that VAT numbers are properly formatted for FedEx, preventing delivery errors and maintaining accurate data. This resolves a compatibility issue with the FedEx shipping service.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452
A technical problem prevented users from correctly accessing WhatsApp event notifications. This update fixes a validation error that was incorrectly restricting access based on the event type, ensuring all approved event registrations now receive WhatsApp notifications. This resolves a reported issue impacting event communication.
Original PR description
Issue:
1) User goes to Event.event Form -> communication tab -> add line 2) Select whatsapp -> type something -> create and edit -> create new template with any model except event.registration -> save ( all the way including the event form) 3) reload page -> whatsapp event.mail displays "User does not have access to this record".
Fix: Added validation errors for the same criteria as the domain below inside the create and write of the event.mail model
"Domain.AND([[('model', '=', 'event.registration')], [('status', '=', 'approved')], domain])"
https://github.com/odoo/enterprise/blob/b06da04210f820e91ae2c829afe10fd8c82ed1f4/whatsapp_event/models/whatsapp_template.py#L19-L21
opw-60374885 changes
Resolved issues and error corrections
This update resolves an issue where fields weren't being created correctly within Odoo. Specifically, the system now accurately passes the correct model information during the creation process for certain fields. This ensures data is properly associated and prevents potential errors or inconsistencies in reporting and workflows.
Original PR description
See https://github.com/odoo/odoo/pull/199647.
This update corrects a bug where the canteen cost was incorrectly calculated for employees with no attendance during a payslip. The fix ensures that canteen costs are only applied when the employee has recorded actual working hours. This prevents incorrect charges and ensures payroll accuracy for Belgian employees.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406This update corrects an issue preventing the export of Profit & Loss reports with footnotes enabled in the l10n_lu_reports module. The fix addresses a dependency on an outdated model, ensuring proper XML generation and report functionality. This resolves a technical problem impacting report generation.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630
This update addresses a potential issue where the data merge process would fail without warning. Now, if the merge takes too long, a warning notification is displayed, suggesting users reduce the number of records being merged and reloading the model upon successful completion. This enhances the reliability of data operations.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855
This update fixes a potential issue where a user could indirectly change an employee's work email through contract settings. Now, if an employee is linked to a user, their work email will remain unchanged during contract updates, ensuring data integrity. This prevents unintended email modifications.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974,the employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#110808