Daily updates from Odoo
Tuesday, May 5, 2026
195 changes
21 changes
Resolved issues and error corrections
This update resolves an error that prevented users from submitting surveys with background images. The issue stemmed from outdated code referencing a removed component. The fix ensures background images load correctly during the survey submission process, improving the user experience.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update fixes a visual issue where quick actions were incorrectly displayed on tracking messages. By standardizing the styling of tracking messages, quick actions are now positioned correctly, ensuring a consistent and user-friendly experience for viewing email notifications.
Original PR description
Previously, quick actions were incorrectly positioned on tracking messages, as they were not treated the same way as notification messages in terms of bubble styling. This PR ensures that tracking messages are handled like notification messages by excluding them from bubble coloring, resulting in the correct placement of quick actions. task-6176330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small typo in the quality module caused newly created quality alert records to be incorrectly grouped under 'None'. This fix replaces the incorrect '&' character with the correct '|' character, ensuring records are assigned to the appropriate stages.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update fixes an issue where changing a task's project would reset its state (done or canceled) unnecessarily. Now, the state remains consistent when a task is marked as done or canceled, ensuring accurate tracking of task completion and preventing redundant state updates. This improves the reliability of project management workflows.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864 Forward-Port-Of: odoo/odoo#261648 Forward-Port-Of: odoo/odoo#252752
This update fixes an issue where duplicating a user also duplicated their associated tasks, leading to confusion and potential data inconsistencies. The change ensures that tasks are correctly assigned to new users, preventing shared task assignments and simplifying user management. This improves data accuracy and user experience.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update resolves an issue where very long image filenames in Odoo caused errors, specifically 502 errors when uploading images through the Sales Order editor. The fix truncates filenames to 255 characters to ensure compatibility with server limits, improving image upload stability for users.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498
This update ensures that 'Final Consumer' records are correctly identified as individuals, not companies, within the CO Edition module. The change resolves an issue where the system incorrectly classified these records, and includes updated tests to verify anonymous document creation. This ensures accurate reporting and compliance.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751 Forward-Port-Of: odoo/enterprise#115560
This update resolves visual issues with Saudi document layouts by removing redundant information and dynamically updating key details like VAT numbers. It ensures all Saudi companies use the correct paper format, improving the accuracy and presentation of invoices and reports.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where translations for the Dutch returns module (l10n_nl_returns) were missing. Adding the necessary translation keys ensures accurate and complete functionality for our Dutch-speaking users. This resolves a potential issue with localized reporting and processes.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
A recent problem with the departure form being inaccessible when accessed through payslips has been resolved. This change ensures the correct form view is used, preventing errors and improving the user experience for employees submitting departure requests.
Original PR description
The departure form could fail to load when accessed via payslip due to a leaked form_view_ref in the context. Explicitly set the correct form view in the action to avoid this issue. task-6167494 Forward-Port-Of: odoo/odoo#261701
This update corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting that granted excessive access to overtime calculations. The fix removes this access and includes new tests to ensure this issue doesn't reoccur.
Original PR description
- Step to reproduce: everyone can see everyones overtimes. - Cause: total_overtime compute method is using `compute_sudo=True`. - Solution: removing compute_sudo and adding tests Task: 6125021 Forward-Port-Of: odoo/odoo#262206 Forward-Port-Of: odoo/odoo#261496
This update fixes an issue where the 'Share' button on the Dashboard was not correctly copying content to the clipboard. The problem stemmed from a change in a previous update (m3) that removed design rules. This commit manually re-added Bootstrap classes to restore the button's functionality and appearance, ensuring users can seamlessly share data.
Original PR description
Because of m3, some rules have been deleted. This commit restores them by manually adding Bootstrap classes. Steps to reproduce: - Go to the Dashboard - Click on the "Share" button Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a visual design problem in the Documents and Spreadsheet modules, specifically related to copy-paste functionality. The issue was caused by a previous system change (m3) that removed essential styling rules. This commit manually re-added the necessary Bootstrap classes to restore the original design and ensure proper functionality.
Original PR description
…h BS Because of m3, some rules have been deleted. This commit restores them by manually adding Bootstrap classes. Steps to reproduce: Here is a way to trigger a traceback - Open the browser console - Type: "odoo.__WOWL_DEBUG__.root.notification.add(new Set())"
This update resolves an issue where customers couldn't be found using their email addresses. The system was incorrectly searching for emails in the phone field. This change ensures accurate customer retrieval based on email, improving data accuracy and customer identification.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before setting it in the main accounting view. Now, users can directly create and edit digipoort certificates within the accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update automatically sets the first available printer as the default for Point of Sale transactions. Previously, users had to manually select a printer, and this change simplifies the process. Additionally, restrictions have been added to prevent accidental changes to printer settings during quick creation, ensuring data consistency.
Original PR description
Following this commit: ===== - Set first printer as default printer from the list configured. - Updated the help tooltip. - Added placeholder "None" to field product_categories_ids. - Restrict quick create for `receipt_printer_ids` and `default_receipt_printer_id` for pos.config and res.config.settings views task-5494313 Forward-Port-Of: odoo/odoo#246448
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with: TypeError: Cannot read properties of null (reading 'textContent') Steps to reproduce: ==================== 1. Go to /contactus and edit the form 2. Add a Radio Buttons field and enable "Add other" 3. Add another field and set "Visible only if" to depend on the radio field => TypeError, form options panel broken Cause:
Original PR description
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with: TypeError: Cannot read properties of…
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with:
TypeError: Cannot read properties of null (reading 'textContent')
Steps to reproduce:
====================
1. Go to /contactus and edit the form
2. Add a Radio Buttons field and enable "Add other"
3. Add another field and set "Visible only if" to depend on the radio field
=> TypeError, form options panel broken
Cause:
=======
The "Add other" feature inserts an additional `.o_other_input` text input next to the radio inputs (the free-text input shown when "Other" is selected). When loading the available condition values, the code iterated over every `.s_website_form_input` in the dependency container and looked up `label[for="${el.id}"]`. The `.o_other_input` has no `id` and no associated label, so `querySelector(...)` returned `null` and accessing `.textContent` threw.
The crash also prevented editing any field's label on the form until the page was reloaded.
Solution:
==========
Excluding `.o_other_input` from the iteration is correct: the "Other" choice is already represented in the list by its dedicated radio (with its own label), so the free-text payload input must not be treated as a separate condition value.
An alternative would have been to narrow the selector to `.s_website_form_input.form-check-input` (the class carried by radio and checkbox inputs), which also excludes the `.o_other_input`. The chosen approach (`:not(.o_other_input)`) is more explicit about the intent: skip the "Add other" payload input, regardless of any class additions to the radio/checkbox inputs in the future.
=> Visibility dependency loads correctly, only the radio choices
("Other" included via its radio label) are listed
opw-6170367
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262046This update resolves a technical issue preventing the automated tour test from running correctly within the HR Contract Salary module. The fix addressed a missing configuration setting, ensuring the tour test now passes as expected. This ensures the tour test functionality is reliable for new users.
Original PR description
tour test is failing without employee_type task-6186664
This update fixes an issue where closed Helpdesk tickets were sending out emails with the incorrect ticket ID instead of the reference number. This ensures that customers receive consistent and accurate information about their resolved tickets, improving communication and transparency. The change updates a key email template to use the correct ticket reference.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#115946 Forward-Port-Of: odoo/enterprise#113932
This update fixes an issue where users connecting to multiple Shopee shops through a Shopee Account were experiencing errors due to repeated authorization code usage. Now, the system correctly reuses the initial authorization code to retrieve access tokens for all associated shops, streamlining the onboarding process for users managing multiple stores.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
This update simplifies the permissions needed to upload Unsplash images, reducing complexity and potential security risks. The change focuses on granting access only to set the attachment URL, rather than broader permissions, resulting in a cleaner and more secure system. This improves the overall stability and efficiency of the Unsplash integration.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
22 changes
Resolved issues and error corrections
A bug was fixed that prevented the custom color settings for self-ordering kiosks from being applied. The issue stemmed from a missing data field, which defaulted to the standard color. This update ensures that self-ordering kiosks now correctly display the configured color scheme.
Original PR description
The background color configured for the self ordering / kiosk was not applied. This was caused because the `self_ordering_primary_color` field was not sent to the self order when loading the data, resulting in the default color always being used. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6149865
This update resolves an issue where long image filenames in Odoo could cause website errors. The system now automatically shortens these filenames to prevent exceeding server limits, ensuring images load correctly and maintaining a stable user experience. This improves the reliability of image uploads and related features.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498
A small typo in the quality module caused new quality alert records to be incorrectly grouped as 'None'. This update corrects the typo, ensuring records are properly assigned to the correct stages when created. This resolves a potential issue with data accuracy and reporting.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update resolves a crash in the form builder when using the 'Add other' option with radio buttons. The fix prevents a JavaScript error that occurred when the system tried to access data from a special input field created by the 'Add other' feature. Now, the form builder works reliably with this functionality.
Original PR description
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with: TypeError: Cannot read properties of…
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with:
TypeError: Cannot read properties of null (reading 'textContent')
Steps to reproduce:
====================
1. Go to /contactus and edit the form
2. Add a Radio Buttons field and enable "Add other"
3. Add another field and set "Visible only if" to depend on the radio field
=> TypeError, form options panel broken
Cause:
=======
The "Add other" feature inserts an additional `.o_other_input` text input next to the radio inputs (the free-text input shown when "Other" is selected). When loading the available condition values, the code iterated over every `.s_website_form_input` in the dependency container and looked up `label[for="${el.id}"]`. The `.o_other_input` has no `id` and no associated label, so `querySelector(...)` returned `null` and accessing `.textContent` threw.
The crash also prevented editing any field's label on the form until the page was reloaded.
Solution:
==========
Excluding `.o_other_input` from the iteration is correct: the "Other" choice is already represented in the list by its dedicated radio (with its own label), so the free-text payload input must not be treated as a separate condition value.
An alternative would have been to narrow the selector to `.s_website_form_input.form-check-input` (the class carried by radio and checkbox inputs), which also excludes the `.o_other_input`. The chosen approach (`:not(.o_other_input)`) is more explicit about the intent: skip the "Add other" payload input, regardless of any class additions to the radio/checkbox inputs in the future.
=> Visibility dependency loads correctly, only the radio choices
("Other" included via its radio label) are listed
opw-6170367
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where copying a user also duplicated their associated tasks, leading to shared task assignments. The change ensures that tasks are correctly isolated to the new user, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update ensures that EC Sales Reports generated for the Swedish market (l10n_se) are exported to KVR in whole numbers, as required by Swedish tax regulations. Previously, the export included decimal places, which was incorrect. This fix corrects the rounding logic to meet reporting standards.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#115980 Forward-Port-Of: odoo/enterprise#114292
This update prevents Odoo from crashing when viewing order details without a linked employee. Previously, enabling 'Log in with Employees' after processing an order would cause issues. Now, the 'Served By' field defaults to the user who created the order, ensuring a smoother experience.
Original PR description
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is…
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is enabled after at least one order has already been processed. **After this commit** If there isn't an `employee_id` associated with an order, don't try to overwrite the "Served By" field. By default, this should allow the name of the user who processed the order to be displayed. This can be seen in the original `getOrderFields()` method on the `OrderDetailsDialog` component. https://github.com/odoo/odoo/blob/e1c81c326e370b0a7b5bc8018b151e251ebce544/addons/point_of_sale/static/src/app/screens/ticket_screen/order_details_dialog/order_details_dialog.js#L81 This commit is mostly a backport of the slight refactor in 19.3, with the added benefit of still showing the names of the users who processed orders before `pos_hr` was installed on the database. https://github.com/odoo/odoo/blob/be57b42442db8c6be219d36f8c3e07e8baf45e31/addons/pos_hr/static/src/app/screens/order_details_dialog.js#L10-L15 opw-6169880
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before selecting it. Now, users can directly create and edit digipoort certificates within the primary accounting settings, improving usability.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update ensures that 'Final Consumer' records created within the CO Edition are correctly identified as individuals, not companies. Previously, a calculation error resulted in these records being incorrectly classified. The fix includes a necessary adjustment to the data and updated tests to guarantee accurate record creation.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751 Forward-Port-Of: odoo/enterprise#115560
This update resolves an error that prevented users from submitting surveys with background images. The issue stemmed from outdated code referencing a removed component. The fix ensures background images load correctly during the survey submission process, improving the user experience.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update resolves visual issues and ensures accurate Saudi document formatting. Specifically, it dynamically updates VAT information and standardizes paper formats for Saudi companies, improving the clarity and reliability of printed reports.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where the Dutch translations for the 'l10n_nl_returns' module were missing from the project's translation files. Adding these translations ensures accurate and complete functionality for Dutch-speaking users of the Enterprise software. This resolves a potential display issue and improves the user experience.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update resolves an issue where invoices generated with the l10n_sa and l10n_sa_edi modules were displaying a duplicate tax number. The change ensures that company details now print the tax number only once, improving invoice accuracy and presentation. This was related to a previous change in the Odoo codebase.
Original PR description
Before this change: - the additional_company_details would print a second tax number to invoice printout in l10n_sa After this change: - company details will print tax number only once Forward-Port-Of: odoo/odoo#261272
This update resolves a visual glitch where the user status icon on the dashboard incorrectly displayed a grey question mark instead of the correct work location. The fix standardizes the data format used for user status, ensuring the icon accurately reflects the user's location. This improves the user experience and consistency.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `hr_homeworking` module 2. Go to User > Calendar Tab 3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun) 4. Go back…
Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload
Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.
Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.
Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format
`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons
opw-6064997
Forward-Port-Of: odoo/odoo#261977
Forward-Port-Of: odoo/odoo#258829This update fixes a potential issue where errors during holiday creation wouldn't be properly handled. By wrapping the core holiday creation logic in a try/except block, the system now catches and resolves validation errors more reliably, ensuring smoother holiday setup. This improves the overall user experience and data integrity.
Original PR description
this commit, in this PR:https://github.com/odoo/odoo/pull/242299 the create method was refactored to wrap only the _create_all_new_leave call in a try/except block, ensuring that ValidationError is caught at the correct. Task-6179171 Forward-Port-Of: odoo/odoo#262175
This update simplifies the process for creating Unsplash attachments, reducing complexity and potential security risks. Previously, broad access rights were required; now, only the necessary permission to set the attachment URL is granted, improving efficiency and security.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
This update resolves a rejection issue with Mexican tax filings (NOM36) when payslips only include non-taxable payments. The change ensures the XML data sent to the SAT accurately reflects the situation, aligning with tax regulations and preventing errors.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
This update resolves an issue where the 'delete' action was unexpectedly removed after installing the 'data_cleaning' module for attachments. The change ensures that the original attachment view order is maintained, preventing conflicts and restoring the expected delete functionality. This improves the usability of the attachment management feature.
Original PR description
Steps: - Enable debug mode - Go to Attachments view (list) - Select several items - Actions -> You have delete - Install `data_cleaning` - Do the same - Actions -> You don't have delete anymore Context: - `IrUiView` has 16 by default for `priority` field and order set as `priority,name,id`. - `IrAttachment` has a default view with no name, so `ir.attachment` is taken by default. - `data_cleaning` creates a view named `Storage Detail` with no priority specified (so 16 by default) on model `ir.attachment`. That makes the `ir.attachment` view from `data_cleaning` before the original one if we use the order "priority,name,id", as both of them have 16 in priority and `Storage Detail` is before `ir.attachment`. This commit restore the previous behaviour by preventing `data_cleaning` from overriding original `ir.attacmhent` view. opw-6149907 Forward-Port-Of: odoo/enterprise#115421
This update fixes an issue where closed Helpdesk tickets were sending out emails with the incorrect ticket ID instead of the reference number. Previously, the 'Ticket Closed' email template used the database ID, leading to inconsistent information for customers. This change ensures all email communications accurately reflect the ticket reference number.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#115946 Forward-Port-Of: odoo/enterprise#113932
A bug in the Odoo spreadsheet functionality was causing the user interface to freeze when a specific function was used. This update fixes an infinite loop within the spreadsheet, preventing this freezing issue and ensuring a stable user experience. This resolves a reported performance problem.
Original PR description
When using `ODOO.LIST.HEADER(1, <empty_cell_ref>)`, the spreadsheet enters an infinite evaluation loop, causing the UI to freeze. Task: 6171185 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262037 Forward-Port-Of: odoo/odoo#261724
This update corrects a technical error that prevented live chat channels with AI agents from appearing correctly to users. The fix ensures that all live chat channels, regardless of agent type, are accurately displayed. This improves the user experience and functionality of the live chat feature.
Original PR description
The number of agents linked to a livechat channel was always 0 because of a mistake in the code. This prevented livechat channels with AI agents from appearing to users. This commit fixes the problem. task-5409200 Forward-Port-Of: odoo/enterprise#111574
This update fixes an issue where users were encountering errors when authorizing multiple Shopee shops through a Shopee Account. Now, the system correctly reuses authorization tokens, streamlining the process and preventing duplicate requests. This ensures a smoother onboarding experience for users managing multiple shops.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
26 changes
Resolved issues and error corrections
A small typo in the quality module caused new quality alert records to be incorrectly grouped as 'None'. This update corrects the typo, ensuring records are properly assigned to the correct stages when created. This resolves a potential issue with data accuracy.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update corrects a technical issue that was causing unwanted options to appear in the email marketing builder. Specifically, it ensures the image transform option is hidden, and adds visibility to the Background Color and Border options. This improves the user experience and consistency within the mass mailing builder.
Original PR description
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced…
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced the `OptionComponent` with some modified version. As the `OptionComponent` is no longer present in the base option, patching the same won't use the modified option. Hence, the option became visible in the mass mailing builder. This commit adapts the mass mailing builder with the refactoring of the options API to keep the image transform option hidden. [commit]: https://github.com/odoo/odoo/commit/179480d996a19dff4d56265a610259b1c6e33f99 Commit 2 ------------------- ### Steps to reproduce 1. Open Email Marketing 2. Open/Create a Mailing 3. In the editor, insert an `Alert` block. --------> Some options won't be visible. ### Technical The [commit] restructured the `Alert` snippet, therefore, for the builder to identify the mass mailing's alert block, we need to adapt the selector of the option to `.s_mail_alert`. After this commit, the following options will become visible (which were invisible before the commit): - Background Color - Border Option Note: 1. mass_mailing's `Alert` option now correctly uses the mass mailing's option template. Which included different size options, but those are now already added by `size_option_plugin`. Therefore this commit also removes those redudant size options from the alert option. 2. The width option for the `Alert` block is already added by original `width_option_plugin`, therefore we remove the patch of the selector inside mass mailing to avoid redundancy. [commit]: https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6 Task-5999942 Forward-Port-Of: odoo/odoo#260923
This update resolves an issue preventing the `sale_stock` and `purchase_stock` modules from installing correctly on databases with existing sale or purchase orders that include non-stock items like downpayments. The fix filters out these lines during the installation process, preventing a software error and ensuring proper module functionality.
Original PR description
## Summary When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:…
## Summary
When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:
ValueError: Expected singleton: uom.uom()
## Root Cause
The `post_init_hook` (`_create_pickings_for_open_sale_orders` / `_create_pickings_for_open_purchase_orders`) filters order lines to create pickings:
```python
empty_lines = open_sale_orders.order_line.filtered(
lambda l: l.product_uom_id.is_zero(l.qty_delivered)
)
```
This accesses product_uom_id without checking if it exists. Lines with:
- display_type set (sections, notes)
- is_downpayment = True (downpayments)
...don't have a product_id or product_uom_id, causing the error.
Fix
Add filters to skip non-stock lines before accessing product_uom_id:
```
empty_lines = open_sale_orders.order_line.filtered(
lambda l: not l.display_type and not l.is_downpayment and l.product_uom_id.is_zero(l.qty_delivered)
)
```
Steps to Reproduce
1. Create a fresh database (without sale_stock/purchase_stock)
2. Create a sale order with a downpayment line or section/note
3. Install sale_stock module
4. Error: ValueError: Expected singleton: uom.uom()
Reproduction Reference
- purchase_stock issue: https://drive.google.com/file/d/1aKw-ago-pMds_-x_y9f8nJZyZsLqGJ67/view?usp=sharing
- sale_stock issue: https://drive.google.com/file/d/1I9fY8UZZZ3ULcairl3YGZTi_KttsYLNR/view?usp=sharing
opw-6179073
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prAn error prevented users from importing emissions data through the Emitted Emissions menu. This fix restricts imports to manual emissions, resolving a database conflict issue related to journal entry emissions. This ensures data integrity and stability within the ESG reporting functionality.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587 Forward-Port-Of: odoo/enterprise#115856 Forward-Port-Of: odoo/enterprise#115306
This update ensures that 'Final Consumer' records are correctly created as individuals, not companies, within the Odoo system. The previous issue stemmed from incorrect test assertions related to anonymous document creation. This fix resolves the problem by explicitly setting the 'Final Consumer' type to 'individual' and updating associated tests.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751
This update simplifies the process for Dutch companies to manage their digipoort certificates. Previously, users had to navigate between separate menus to create and select a certificate. Now, users can directly create and edit digipoort certificates within the main Accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update resolves an issue where users couldn't access equity information for partners linked to companies they didn't have access to. The change adds a 'company_id' field to equity models, allowing the system to correctly identify and display equity data for all partners, regardless of their associated company.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771 Forward-Port-Of: odoo/enterprise#110724
This update resolves an issue where the survey module would fail to load background images due to an outdated reference to a component that was no longer used. The fix ensures the background image loading process is correctly implemented, preventing the error and improving the survey experience. This ensures surveys load correctly and reliably.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update resolves visual issues with Saudi document layouts by dynamically updating VAT information and ensuring the correct paper format is applied to all Saudi companies. This improves the accuracy and presentation of invoices and other financial documents for our Saudi customers.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where translations for the Dutch returns module (l10n_nl_returns) were missing in the system's configuration. Adding these translations ensures accurate and localized functionality for our Dutch-speaking customers. This resolves a potential problem with incorrect display or functionality.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update corrects a setting for Thai WHT (Withholding Tax) taxes, ensuring they don't automatically generate closing entries. WHT uses separate accounts, simplifying reporting and aligning with local tax regulations. This change improves the accuracy of WHT financial reporting.
Original PR description
Set tax closing entry to False by default for WHT taxes, as WHT uses separate payable accounts and does not require closing entries. task-6146195 Forward-Port-Of: odoo/odoo#262464
This update resolves a visual glitch where the user status icon on the dashboard displayed a grey question mark instead of the correct work location. The fix standardizes the data format used for user status, ensuring the icon accurately reflects the user's location setting. This improves the user experience and consistency.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `hr_homeworking` module 2. Go to User > Calendar Tab 3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun) 4. Go back…
Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload
Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.
Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.
Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format
`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons
opw-6064997
Forward-Port-Of: odoo/odoo#258829This update fixes a technical issue that caused a traceback when canceling an empty order in the Point of Sale (POS) system, specifically when loyalty programs were active. The fix ensures the POS dialog is closed before order deletion, preventing a re-render and the resulting error. This improves stability and prevents unexpected errors during order cancellation.
Original PR description
Steps to reproduce: = - Enable loyalty in the POS configuration. - Add an eWallet program for this POS. - Open a table and cancel the (empty) order using the "Cancel Order" control button. Issue: = - A traceback occurs: `TypeError: Cannot read properties of undefined (reading 'getTotalWithTax')` Reason: = - When clicking "Cancel Order", the order is deleted and `currentOrder` becomes `undefined`. - During the re-render of `ControlButtons` on the product screen, there is no active order, which leads to the traceback. Fix: = - Ensure the `ControlButtons` dialog is closed before deleting the order to prevents the re-render of `ControlButtons` without an active order and avoids the traceback. task-6030182 Forward-Port-Of: odoo/odoo#261775 Forward-Port-Of: odoo/odoo#254337
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we
Original PR description
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.…
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`. - When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678` ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6148039) opw-6148039 Forward-Port-Of: odoo/odoo#262339 Forward-Port-Of: odoo/odoo#261964
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_ka
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259305
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render incorrectly. Steps to produce: --- - Install the `website_sale` module. - Go to Settings and enable `Prevent Sale of Zero Priced Products`. - Create a product with a sales price of `0` and publish it. - Open the product on the website. - Open the editor and change the purchase style to `Box`. Iss
Original PR description
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render…
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render incorrectly. Steps to produce: --- - Install the `website_sale` module. - Go to Settings and enable `Prevent Sale of Zero Priced Products`. - Create a product with a sales price of `0` and publish it. - Open the product on the website. - Open the editor and change the purchase style to `Box`. Issue: --- - The price text renders incorrectly inside the box. Root Cause: --- - At [1], the `<span>` element responsible for rendering the price text does not check whether zero-price sale prevention is enabled, causing the price string to appear regardless. - At [2], after hiding the price span, the `o_wsale_cta_wrapper` element still renders an empty box because no corresponding guard exists there either. Solution: --- - Add a conditional check on the price `<span>`: apply `d-none` when zero-price sale prevention is active, so the price string is not displayed. - Also, add the same zero-price sale prevention check on `o_wsale_cta_wrapper` to avoid rendering an empty box when no price is shown. [1]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2233 [2]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2221 Before: --- <img width="1488" height="689" alt="image" src="https://github.com/user-attachments/assets/5b3a565f-5ced-4d75-b538-63abc3690e09" /> After: --- <img width="1457" height="612" alt="image" src="https://github.com/user-attachments/assets/1e04fe54-98b6-4e1c-bd26-4d56bb34b90e" /> opw-5994812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261313 Forward-Port-Of: odoo/odoo#252666
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
Original PR description
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
This update resolves an issue where Amazon order-related stock movements incorrectly showed 'False' as their reference. The code has been updated to use the `reference` field instead of `name`, ensuring accurate tracking of these movements within the Odoo system. This prevents reporting errors and improves the reliability of Amazon order fulfillment data.
Original PR description
Issue ----- Commit d0c1e78 removed the `name` field of `stock.move`. Instead, we now use the `reference`field, which is computed in `_compute_reference` https://github.com/odoo/odoo/blob/2ec714b19e2c56bff965ab32f7e6a4485df2d247/addons/stock/models/stock_move.py#L357-L369 The problem is that there is no picking linked to the move, so `move.reference` is set to `False`. This means that, after we go through the override in `sale_amazon`, we end up with `Amazon move: False` https://github.com/odoo/enterprise/blob/596d8c1216b33c1f73feb8f60eef1b69a2164579/sale_amazon/models/stock_move.py#L10-L14 ----- Ticket: opw-5969357 Forward-Port-Of: odoo/enterprise#114345
This update simplifies the process for creating Unsplash attachments, reducing complexity and potential security risks. Previously, broad access rights were required, but now only the necessary permission to set the attachment URL is granted, improving efficiency and maintainability. This change ensures secure and streamlined image uploads.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
This update resolves an issue where the 'delete' action was unexpectedly removed after installing the 'data_cleaning' module for attachments. The change prevents the module from overriding the standard attachment view, restoring the original functionality. This ensures users can consistently delete attachments through the standard interface.
Original PR description
Steps: - Enable debug mode - Go to Attachments view (list) - Select several items - Actions -> You have delete - Install `data_cleaning` - Do the same - Actions -> You don't have delete anymore Context: - `IrUiView` has 16 by default for `priority` field and order set as `priority,name,id`. - `IrAttachment` has a default view with no name, so `ir.attachment` is taken by default. - `data_cleaning` creates a view named `Storage Detail` with no priority specified (so 16 by default) on model `ir.attachment`. That makes the `ir.attachment` view from `data_cleaning` before the original one if we use the order "priority,name,id", as both of them have 16 in priority and `Storage Detail` is before `ir.attachment`. This commit restore the previous behaviour by preventing `data_cleaning` from overriding original `ir.attacmhent` view. opw-6149907 Forward-Port-Of: odoo/enterprise#115421
This update fixes a potential issue where errors during holiday creation wouldn't be properly handled. The code was adjusted to ensure that errors related to holiday data are caught and addressed, leading to a more reliable and stable holiday management process. This improves the overall user experience.
Original PR description
this commit, in this PR:https://github.com/odoo/odoo/pull/242299 the create method was refactored to wrap only the _create_all_new_leave call in a try/except block, ensuring that ValidationError is caught at the correct. Task-6179171 Forward-Port-Of: odoo/odoo#262175
This update corrects a technical error in the l10n_ch_hr_payroll module that was causing a system error. The change replaces an outdated function (`get_param`) with a more modern approach (`get_bool`), ensuring the payroll module functions correctly within the new saas-19.1 environment.
Original PR description
ref commit: https://github.com/odoo/odoo/commit/142eab81dad3f88afa18c0db99007db2288a85df `get_param` is no longer available in saas-19.1 and above, and it was causing a traceback.
This update fixes an issue where warning messages from the IoT blackbox were incorrectly treated as errors. Now, warning messages are displayed as notifications, providing clearer visibility into the status of IoT data processing. This improves the user experience and helps identify potential issues more effectively.
Original PR description
Before this commit, all errors returned by the iot after a call to the blackbox were considered as errors. Actually, the errors are only the ones that do not start with 0 (no error) or 1 (warning). This commit changes the behaviour when handling warning. We now show a notification. task-id: 5062178 Forward-Port-Of: odoo/enterprise#109251 Forward-Port-Of: odoo/enterprise#93896
This update resolves an issue preventing non-admin internal users from accessing the website generator import feature. The fix grants read-only access to a broader group of users, ensuring a smoother import process without impacting system security. The website generator systray now functions correctly for all users.
Original PR description
Steps to reproduce: =================== 1. On a 19.1, launch a website import as admin 2. Log in as a non-admin internal user => AccessError on website_generator.request Cause: ====== The website generator systray polls `website_generator.request` on every page load: https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/website_generator/static/src/systray_items/generator_request.js#L48 Only `base.group_system` had access on the model, so any non-admin user hit an AccessError as soon as an import request existed (session_info sets show_scraper_systray=True for everyone based on the last request's notified flag). Solution: ========= Grant read-only access to `base.group_user`; writes/creates stay restricted to system so the import flow itself is unchanged. => Systray loads silently, shows status indicator opw-6092411
This update fixes a restriction that prevented users from deleting time off requests after a payslip had been validated. Previously, the system incorrectly blocked deletion, even if the time off wasn't included in the payslip. This change ensures the system correctly handles time off requests regardless of payslip validation status.
Original PR description
## Issue After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved. ##…
## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
- Date: anywhere during March
- **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**
## Cause
The condition to raise the error message does not take into account the state of the leave:
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204
This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.
(related to)
opw-6089990
Forward-Port-Of: odoo/enterprise#115765This update fixes an issue where users were encountering errors when authorizing multiple Shopee shops through a Shopee Account. Now, the system correctly reuses authorization tokens, streamlining the process and preventing duplicate requests. This ensures smoother onboarding and access for users connecting multiple shops.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
2 changes
Resolved issues and error corrections
This update fixes an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents misdirected support tickets.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
This update corrects a display issue where the 'Update Payment' button remained visible after processing batch payments for Mexican CFDI invoices. The fix addresses a technical discrepancy in how invoice UUIDs were compared, ensuring the button only appears for the relevant invoice when a batch payment is created.
Original PR description
backport of f41900a4353ea867b08f71ed64f8702a13411bac - Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#114440
4 changes
Resolved issues and error corrections
This update resolves an issue where multiple documents with the same subject wouldn't all be included in the downloaded zip file. The fix ensures that all signed documents with identical subjects are correctly bundled together, preventing data loss. This improves the reliability of the Sign app's download feature.
Original PR description
## Issue In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file. ## Steps to reproduce 1. Install *Sign* (`sign`)…
## Issue
In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file.
## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sign a same template twice, using the same subject S1. This gives us Documents D1 an D2.
3. (Optionally), sign the same template a third time, using a different subject S2, creating document D3.
4. In Sign > Documents, select the 2 (3) signed documents and click *Download*.
5. **In the resulting zip file, there's one folder S1 containing a single pdf document (D1) (and one folder S2 containing D3). Document D2 is missing from the zip file.**
## Cause
When generating the zip file, the path used for each document is `{subject}/{doc_name}`.
https://github.com/odoo/enterprise/blob/863abc99469c12acdebcab05788d566c370bb46f/sign/controllers/main.py#L276-L286
Neither of this attribute are unique, which means that two signed documents with the same name and subject can be downloaded simultaneously, but will then overwrite each other.
## Fix
Before version 18.3, the zip file would contain folders named with the (unique) request id, which would consistently make them distinct from one another. This behavior was changed by https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b to use the `sign_request.subject` instead. This commit adds the `request.id` after the subject to keep the clarity of the subject, and add the uniqueness of the id.
opw-6143128This update fixes a bug that prevented users from assigning recruiters to job positions when the hr_payroll module wasn't installed. The change ensures the necessary data is always available, resolving an error message and improving the usability of the recruitment process. This update doesn't impact any core functionality.
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259305
This update corrects a problem with the Intrastat CSV export functionality, which was broken following a technical update in version 18.0. The fix ensures accurate data is exported by addressing formatting errors and database synchronization, preventing potential reporting discrepancies.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#116004 Forward-Port-Of: odoo/enterprise#115791
This update fixes an issue where users could select customers from different companies within the Helpdesk system. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents incorrect customer assignments.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
5 changes
Resolved issues and error corrections
This update corrects a bug that prevented users from saving accounting settings when GST registration was unregistered. The fix ensures the system correctly checks GST registration status, preventing a 'Missing Required Fields' error and allowing users to configure the module properly. This improves the usability of the Invoicing module for businesses operating in India.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001
This update resolves an issue where multiple users were incorrectly added to WhatsApp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added to the channel, preventing unnecessary notifications and channel clutter. This improves the user experience and channel management efficiency.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#102452
This update resolves a problem with the CSV export for Dutch Intrastat reporting, which was broken following a recent technical update. The fix addresses an incorrect formatting of 'Commodity flow' data and ensures the database is up-to-date before generating the report, improving data accuracy for reporting.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#115791
This update resolves an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix adds a restriction to the customer selection field, ensuring users only see customers within their assigned company. This improves data accuracy and prevents potential errors in ticket management.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
This update resolves an issue causing incorrect rounding when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the intended functionality for EDI processing, rather than the OCR process. This ensures accurate financial data import.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116021
14 changes
Resolved issues and error corrections
This update eliminates a distracting popup message that appeared when opening the Point of Sale (PoS) module, specifically when reading scale weight data. The fix prevents a frustrating user experience and ensures smoother PoS operations. This resolves a minor usability issue.
Original PR description
This PR removes the unwanted popup "can't reach iot box on local network" before opening PoS when reading scale weight
This update prevents referral-only users from accessing the Reporting tab within the Referrals app. Access to this tab is now restricted to users with recruitment management permissions, streamlining the reporting process for authorized personnel. This change improves data security and usability.
Original PR description
This commit hides the Reporting tab in the Referrals app from users with referral only access rights, and only show it to users with recruitment access. TaskID-6133065
This update restores a previous system for tracking changes made to employee payslips. Now, when a user edits a payslip line, a detailed log is created showing all affected lines. This enhances transparency and simplifies auditing of payroll adjustments.
Original PR description
purpose: We want to reintroduce the same way of logging payslip lines changes as previously done by the removed payslip edit wizard - changed the log in chat to include all affected lines by the user's change task-id: 6144266
This update fixes a technical issue that previously displayed confusing error messages when generating tax reports. Now, users will receive a helpful message guiding them to set up a certificate if one isn't already configured, preventing tracebacks and improving the user experience. This ensures reports can be successfully submitted to authorities.
Original PR description
Description of the issue this commit addresses: When sending the tax report or ec sales list xbrl file via the wizard to the authority, if no certificate has been set, a traceback shows up. This happens because some processes try to use the certificate without checking its existence. Desired behavior after the commit is merged: When sending via the xbrl wizard, if no certificate has been set up, an error offering the user to go to the certificate set up shows up and no traceback. task-6065382 Forward-Port-Of: odoo/enterprise#115907 Forward-Port-Of: odoo/enterprise#112951
A small typo in the quality module caused newly created quality alert records to be incorrectly grouped as 'None'. This fix replaces the incorrect '&' character with the correct '|' character, ensuring records are properly assigned to their intended stages. This resolves a potential data grouping error.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update ensures our accounting system accurately reflects the latest Ecuadorian withholding tax regulations (Resolución N.º NAC-DGERCGC26-00000009) for 2026. The changes involve updating unit tests to align with these new tax percentages, ensuring compliance and accurate reporting.
Original PR description
In accordance with the implementation of the new withholding tax percentages according to "Resolución N.º NAC-DGERCGC26-00000009" for Ecuador, following internal implementation guidelines by TRESCLOUD. Unit tests are updated to be based on the new withholding percentages. BP #110343 Forward-Port-Of: odoo/enterprise#112957 Forward-Port-Of: odoo/enterprise#110712
This update fixes a validation error that occurred when creating correction payslips in Odoo. It ensures that each correction payslip is correctly linked to a structure, allowing for accurate payroll processing. This improves the reliability of the payroll system when adjustments are made.
Original PR description
Ensure `structure_id` is set when creating correction payslips to avoid validation errors. Group payslips by structure before creating pay runs for corrections/reverts, and set the payrun period from the minimum to maximum payslip dates. Fix condition in "Payslip period does not match payrun" to exclude correction payslips (they may span multiple months). task: 6089082 Forward-Port-Of: odoo/enterprise#115405
This update fixes an issue where copying a user also duplicated their assigned tasks, leading to shared task assignments. The change ensures that tasks are uniquely associated with each user, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update adds logging of Amazon's unique request IDs for SP-API responses. Previously, this information wasn't captured, making it harder for support teams to troubleshoot issues with Amazon orders. This enhancement streamlines support investigations and improves order processing efficiency.
Original PR description
Each response from Amazon's SP-API includes a request identifier used by their support team for debugging. This identifier was not previously logged, making support investigations more difficult. Forward-Port-Of: odoo/enterprise#115929 Forward-Port-Of: odoo/enterprise#114483
This update resolves a crash that occurred when users attempted to fetch device information in the HR Attendance module. The issue stemmed from a missing server URL configuration, which has now been addressed by displaying a user-friendly error message prompting them to set the correct URL.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Install the hr_attendance_zkteco module - Go to Settings → Device/Terminal - Click on “Fetch Terminal” Issue: - A traceback error occurs. Cause: - The server URL is not set in settings, so the server value is empty and causes an error. Fix: - Show a user error if the server URL is not configured, asking the user to set it before fetching the terminal. Task-6144254 Forward-Port-Of: odoo/enterprise#114561
This update ensures that 'Final Consumer' records are correctly created as individuals, not companies, within the Odoo system. The change was triggered by a recent update to how the 'is_company' field is calculated. The fix includes correcting test assertions to reflect this accurate creation process.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751 Forward-Port-Of: odoo/enterprise#115560
This update resolves a minor issue in a test related to the HR payroll module's user interface. The change ensures the test accurately reflects updates made to the CSS styling, preventing potential errors in how the toggle field is displayed. This ensures consistent and reliable functionality for users.
Original PR description
Updates the `rule_selection_exclusive_toggle_boolean` test to account for the changes made in https://github.com/odoo/odoo/pull/262543. The test now correctly anticipates the widget sharing the same CSS rules as its base widget. task-3378044
A recent update to the Odoo Enterprise system introduced a new Dutch returns module (l10n_nl_returns) without the necessary translation files. This update corrects this issue, ensuring accurate and complete translations are available for users in the Netherlands. This prevents potential errors or confusion when using the module.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update resolves a problem where payroll exports to the Mexican SAT were being rejected due to incorrect data formatting. Specifically, when a payslip only includes non-taxable payments, the system was including a 'TotalPercepciones' field that the SAT requires to be absent. This change ensures compliance with Mexican tax regulations.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
1 change
Resolved issues and error corrections
This update fixes an issue where Odoo's barcode scanning system wouldn't correctly assign a result package when moving a package with existing contents. Previously, only empty packages could be assigned. Now, the system accurately assigns the result package regardless of the package's contents, ensuring seamless internal transfers.
Original PR description
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable…
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable "Packages" and "Storage Locations" settings; 2. Create two packages with some content in WH/Stock/Shelf 1; 3. Create an empty package; 4. Create an internal transfer directly from the Barcode app; 5. Scan Shelf 1 barcode and scan first package; 6. Scan the empty package => It's assigned as the result package; 7. Confirm the operation; 8. Create another internal transfer; 9. Scan Shelf 1 barcode and scan second package; 10. Scan the no more empty package => This time, it's not assigned as the result package. Reason ====== A package was assigned as the result package only if one of the following conditions is matched: 1. The scanned package is empty (it's what's happening in 6.); 2. The selected line has no result package yet and the scanned package is in the selected line's destination location. Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.) Fix === For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package. [opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234) Forward-Port-Of: odoo/enterprise#102051 Forward-Port-Of: odoo/enterprise#101357
4 changes
Resolved issues and error corrections
This update resolves a problem where community edition tests for invoice payments were failing due to inconsistent payment status after registration (paid or in_payment). The change uses a dynamic function to determine the correct payment state, ensuring tests accurately reflect real-world scenarios and improving test reliability.
Original PR description
Community edition tests fail because payment status after registration can be (`paid` or `in_payment` depending on environment), while the test assumes a fixed value. so instead of hardcoding the state, we use `_get_invoice_in_payment_state` which return required state, depending on environment we are Runbot [link](https://runbot.odoo.com/odoo/error/243480) runbot-error:243480
This update resolves an issue causing incorrect rounding when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the system's intended use for EDI, rather than the OCR process. This ensures accurate financial calculations for purchase orders.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387)
This update fixes an issue where users could accidentally select customers from different companies within the Helpdesk system. The fix involved adding a restriction to the customer selection field, ensuring users only see customers within their assigned company. This improves data accuracy and prevents misdirected support requests.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
This update corrects a technical error in how Odoo's Discussions feature sorts partners based on email addresses. The fix ensures that partners with matching email prefixes are correctly prioritized, leading to more accurate and relevant search results within Discussions. This improves the overall user experience.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
1 change
Resolved issues and error corrections
This update clarifies the purpose of the invoice_mail_template_id field in the subscription module. The help text has been revised to specifically state that it applies only to recurring renewal invoices, reducing potential confusion. This change ensures users understand when and how the email template is utilized.
Original PR description
The existing help text of the invoice_mail_template_id field was unclear andcould lead to confusion about when the email template is used. After discussion with the Product Owner, the help text has been updated to better clarify that it applies only to recurring renewal invoice emails. **opw-5993315**