Daily updates from Odoo
Wednesday, March 11, 2026
187 changes
24 changes
Resolved issues and error corrections
This update fixes a visual issue on the mobile POS tablet where the pill selection popup was positioned incorrectly, leading to a confusing user experience. The change adjusts the popup's starting position to the bottom of the screen, resulting in a cleaner and more intuitive interface for tablet users. This ensures a consistent and user-friendly experience.
Original PR description
Small modification of the pills selection popup in order to make it starting at the bottom of the screen and not with a fixed size, which caused in certain cases, weird UI. task: 5952769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a restriction preventing users without the necessary HR group from accessing bank account information. Previously, accessing a bank account triggered an error, impacting data visibility. This fix ensures all users can manage bank accounts correctly.
Original PR description
The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`. If you try…
The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`. If you try to check a bank account without an hr group, you will get an access error: ``` odoo.exceptions.AccessError: You do not have enough rights to access the field "salary_distribution" on Employee (hr.employee). Please contact your system administrator. Operation: read User: 21 Groups: allowed for groups 'Employees / Officer: Manage all employees' ``` This also happens during the mock crawl test of upgrades if the admin lacks the group. To reproduce in standard: - Install contacts and hr. - Use a user without hr permissions. - Try to create a new bank account. [^1]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/res_partner_bank.py#L26 [^2]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/hr_employee.py#L147 --- I've also added another commit to make the percentage symbol stick to the salary amount. Before: <img width="366" height="38" alt="image" src="https://github.com/user-attachments/assets/ef890852-50ca-40b1-8c09-07c4aa2d330d" /> After: <img width="219" height="35" alt="image" src="https://github.com/user-attachments/assets/88e4a6c4-bc3f-483e-97f9-3080c6aa85c9" /> I know the number is not formated correctly but I don't think I can do more just from the view. Forward-Port-Of: odoo/odoo#239298
This update resolves a recurring issue causing nightly builds to fail due to timeouts. The changes include improvements to emoji loading, debugging tools, and asset caching to enhance stability and test efficiency. These updates ensure smoother and more reliable nightly builds.
Original PR description
Community: https://github.com/odoo/enterprise/pull/107499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a recurring issue causing nightly timeouts within the Odoo Enterprise system. The team reorganized code to improve asset caching, allowing for more reliable testing and ultimately a more stable system. This change enhances the overall performance and stability of the Enterprise edition.
Original PR description
Enterprise: https://github.com/odoo/odoo/pull/248815
This update resolves an issue where Dutch tax returns appeared to be submitted but weren't actually sending data to the tax authorities. The fix ensures that the XBRL export is triggered when a Dutch tax return is submitted, accurately reflecting the status in the system and ensuring compliance.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#110015 Forward-Port-Of: odoo/enterprise#109691
This update resolves a technical issue preventing the Quote Builder from generating PDF quotes correctly. The change ensures compatibility with a newer version of the PDF library, specifically addressing a requirement for 'Fields' within AcroForm structures. This ensures Quote Builder continues to function as expected.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464 Forward-Port-Of: odoo/odoo#250329
This update resolves an issue where large file uploads to forms would fail, resulting in error messages. The fix adjusts how the system handles request body sizes, ensuring compatibility with our web server's limits. This prevents form saving failures and improves the user experience when uploading files.
Original PR description
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below…
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below 128mb (for nginx : client_max_body_size) - If the system parameter web.max_file_upload_size is set, delete it and refresh your page - Pick any form view and add a file field with studio - Upload a file larger than the limit set in the proxy, but smaller than 128mb - Save the form # The problem The form is not saved and depending on the version, a Traceback will be shown (18.X) or a Connection Lost notification will be shown for a short period of time (19.0+) # Why When the system parameter web.max_file_upload_size is not set, the check for file size uses the default 128mb. A binary field added to a form via studio will upload its file in the json of the post request. This is done by encoding the file in base64. Our nginx servers set a limit for the request body size (usually 64mb). So if you add a file between 64mb and 128mb, it will bypass the default front-end size check but be stopped by the nginx reverse proxy. The proxy will send back an HTTP response with error code 413 to the client. Theses http responses are not correctly handled by the framework and are interpreted as a Connection Lost error because the response content cannot be parsed to json. Additionally, since we use base64 for the encoding and then use gzip to compress the json request, it's not really feasible to synchronize the front-end limit with the nginx one. opw-5891662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252527 Forward-Port-Of: odoo/odoo#249025
This update resolves an issue where autocomplete fields weren't consistently saving manual changes made by the user. The fix ensures that the field's value is correctly updated after a user manually edits the input, preventing data discrepancies when saving the form. This improves data accuracy and reliability.
Original PR description
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because…
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because they basically render an input (spiced with the autocomplete feature), so they must handle "manual" updates (listen to `input`, `change`, `keydown` events), like regular input fields. However, the input also acts as a "search bar" for the autocomplete. As a consequence, it might happend that the `useInputField` hook internals weren't correctly reflecting the actual state of the field. Here's a faulty scenario to highlight the issue, involving any of the two widgets: - open a form view with the field set to value "XYZ" - type in the input "ABC" and select a suggestion from the autocomplete dropdown => say the value is now "Value ABC" - manually erase the content of the input and type "XYZ" as before - save => the value sent to the server was actually "Value ABC" The reason is that the hook still believes that the field is dirty after the value has been picked from the dropdown, and set (in the model) to "Value ABC", so `lastSetValue` isn't correctly updated to "Value ABC" (it's still "XYZ"). Later on, after the manual update to go back to the value "XYZ", we compare this value with `lastSetValue`, and as they are the same, we do nothing, so the value in the model remains "Value ABC". Those widgets need to use the hook, because the logic encapsulated inside it is really tricky and we don't want to duplicate it. But the hooks internals aren't exposed, and we don't want to expose them to keep it under control. So we did the fix inside the hook itself: in `useEffect`, so after a patch, if the value in the model is the same than the value in the input, it means that the field isn't dirty anymore, so we force-reset the flag to `false`. This scenario only makes sense for inputs that are handled both internally by the hook and externally (e.g. by the autocomplete). Task~6018655 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#252829
This update enhances the clarity of Odoo's server logs during data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or which specific model the data was being loaded into. This change makes it easier for support teams to investigate issues and resolve import problems efficiently.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update fixes a test failure related to live chat operator access. The system now correctly handles operator assignments, ensuring the test accurately validates description edit permissions. This change improves the reliability of our live chat functionality.
Original PR description
this PR is resolving [runbot error](https://runbot.odoo.com/odoo/runbot.build.error/241727) due to **/get_session** now creates the assigned operator as a channel member, so the previous non-member assertion became invalid and could fail depending on operator assignment. The test now uses a distinct livechat operator added after session creation to keep validating description edit access without relying on outdated membership assumptions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252736
This update resolves a technical problem where screenshots of spreadsheets were sometimes failing due to the spreadsheet being unexpectedly closed. The fix ensures that thumbnails are consistently saved, improving the reliability of spreadsheet sharing and reducing potential data loss. This was a priority fix to maintain a stable user experience.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update fixes an issue where POS receipts displayed duplicate company names and incorrectly showed the company name instead of the POS configuration name. The change ensures receipts now accurately display the POS configuration name once, improving the clarity and professionalism of customer receipts.
Original PR description
Before this commit: =================== The POS receipt displayed the company name twice, resulting in duplicated company information. Additionally, the company name was shown instead of the PoS config name. After this commit: ================== The receipt now correctly displays the POS config name only once. Duplicate company information has been removed to ensure a clean and accurate receipt layout. Task-5951599
This update resolves a technical issue preventing users from generating ird reports when employees have multiple versions recorded within the same reporting period. The fix temporarily prioritizes the most recent version for report generation, ensuring report functionality is restored. This ensures accurate reporting for employees with complex payroll histories.
Original PR description
Fixes an issue that blocks users from generating ird reports if the employee has multiple versions in the period. For now, we will only keep the latest version at the time of reporting. task - 6023310
This update fixes a technical issue preventing module overrides (like those in HR) from correctly updating VoIP contact status information. The change ensures VoIP data aligns with Odoo's extensibility standards, maintaining consistency between the real system and test environments. This improves the reliability of VoIP integrations.
Original PR description
`_store_voip_fields` was directly adding `"im_status"` to the stored partner fields. This bypassed `_store_im_status_fields`, so module overrides (notably HR-related ones) could not extend/adjust the IM status payload. Use `_store_im_status_fields(res)` from `_store_voip_fields` instead of hardcoding `"im_status"`. Also align the VoIP mock server `res.partner` contact payload with the real store payload by including the same contact fields and IM status data (`partner_share`, `im_status`, `im_status_access_token`, etc.). This keeps VoIP aligned with the extensibility contract and keeps tests on the same data shape as runtime. [H>A]
This update resolves an issue where the point-of-sale search feature wasn't consistently working due to a timing problem with updating the search input. A small delay has been added to ensure the search input is properly updated before triggering the search, guaranteeing accurate database lookups. This improves the reliability of the search function.
Original PR description
In some test, we try to search the database for a partner through the partner_list. To do this, we edit the partner_list input and trigger an "Enter" event. In some case, the value is not set to the state of the partner_list before we dispatch the event and result in no search in the database being done. This is partly due to the debounce of the input before setting the state of the partner list and due to some method running asynchronously every method triggered by the insertion of text. To fix this, we add a little sleep in the tour (200ms) to ensure that the state of the component is well updated before triggering the event. runbot-error: 238511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent issue prevented the automated update of POS price tags. This fix removes an outdated argument from the scheduled process, resolving a technical error that was disrupting the tag synchronization. This ensures the POS Pricer module functions correctly without interruption.
Original PR description
Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs. **Steps to Reproduce:** - Install the `pos_pricer` module. - Go to `Scheduled Actions` and run…
Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs.
**Steps to Reproduce:**
- Install the `pos_pricer` module.
- Go to `Scheduled Actions` and run `"POS Pricer: Tags Update Synchronization"`.
**Error:**
`
ValueError: TypeError("PricerStore._update_pricer_tags() got an unexpected keyword argument 'update_all'") while evaluating 'model.search(([("pricer_tag_ids", "!=", False)]))._update_pricer_tags(update_all=False)'`
This error occurs because, after this [recent commit], `_update_pricer_tags` was changed to
no longer accept the `update_all` argument and now relies on the `needs_pricer_update` instead.
However, the scheduled action still passes the `update_all` argument [1], which causes the
error when the cron job runs.
This commit removes the unexpected `update_all` argument from the tag update synchronization cron.
[recent commit]: https://github.com/odoo/enterprise/commit/166a8a240d0588f4e908ce09c4639da1216ba3b7
[1]- https://github.com/odoo/enterprise/blob/0ef7643bba5b3fa3d22ab122ef3b65f0d67c8fb7/pos_pricer/data/pricer_ir_cron.xml#L9
sentry-7324339777This update fixes a temporary issue that prevented a helpful training tour for restaurant staff within the Odoo POS system. The tour has been re-enabled with added checks to ensure order synchronization, particularly after printer errors, improving the user experience and training process.
Original PR description
In this commit: --- - Re-enable `test_course_restaurant_preparation_tour`, which was previously disabled to allow merging during freeze. - Add steps to ensure the order is properly synchronized. task-5958387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update caused crashes when creating YouTube posts in Odoo Enterprise. This fix removes an outdated dependency within the social_youtube module, resolving the crash. The change ensures stable saving of YouTube posts without impacting core functionality.
Original PR description
Bug: Following recent changes introduced in saas-19.2, creating and saving a YouTube post causes the flow to crash. Cause: A refactoring in the social module removed the `utm.source.mixin` dependency from the `social_post` model. This consequently removed the `name` attribute from the model. However, `social_youtube` still expected this attribute to exist, triggering the crash. Solution: Remove all references to the `name` attribute within the `social_youtube` module. We opted not to reintroduce the attribute on the model because it did not add significant functionality and has been superseded by other attributes.
This update fixes a minor issue where a warning about leaving a chatbot conversation was displayed even when the conversation was already closed. Now, the warning only appears when a chatbot conversation is actively in progress, providing a smoother and less disruptive user experience. This change ensures users aren't unnecessarily alerted about finished chats.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252750 Forward-Port-Of: odoo/odoo#247918
This update corrects a minor CSS error that was causing incorrect display rules for elements within the timesheet grid. The change ensures that the grid renders correctly, improving the overall user experience. This fix focuses on internal styling and doesn't impact external functionality.
Original PR description
This commit fixes the generation of the `display` CSS rules.
Before:
```scss
//...
.aw_nca_step_1 .aw_nca_d-block_from_step_1 {
display: "block";
}
//...
.aw_nca_step_1 .aw_nca_d-inline-flex_from_step_1 {
display: "inline-flex";
}
```
After:
```scss
//...
.aw_nca_step_1 .aw_nca_d-block_from_step_1 {
display: block;
}
//...
.aw_nca_step_1 .aw_nca_d-inline-flex_from_step_1 {
display: inline-flex;
}
```
Doc:
> In Sass, elements in lists can be separated by commas (Helvetica, Arial, sans-serif), spaces (10px 15px 0 0), or slashes as long as it’s consistent within the list.
https://sass-lang.com/documentation/values/lists/This update resolves an issue where the zoomable chart cursor was behaving unexpectedly, particularly with chart interactions. The changes enhance the chart's responsiveness and stability, ensuring a smoother user experience when zooming and interacting with charts. This improves the overall quality and reliability of the spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/04d519e592 [REL] 19.2.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/04d519e592 [REL] 19.2.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/fdaade3e5c [FIX] spreadsheet: fix zoomable chart cursor [Task: 5012198](https://www.odoo.com/odoo/2328/tasks/5012198) https://github.com/odoo/o-spreadsheet/commit/ed7ce1c9e4 [FIX] Model: reject data that postdate the library version [Task: 5895572](https://www.odoo.com/odoo/2328/tasks/5895572) https://github.com/odoo/o-spreadsheet/commit/1c54150e4c [IMP] functions: Add `ISFORMULA` function [Task: 6013888](https://www.odoo.com/odoo/2328/tasks/6013888) https://github.com/odoo/o-spreadsheet/commit/32709c4560 [FIX] selection_input: disable spill references [Task: 5945112](https://www.odoo.com/odoo/2328/tasks/5945112) https://github.com/odoo/o-spreadsheet/commit/b0f06197d4 [FIX] charts: remove zoom slicer for scatter plot [Task: 5388389](https://www.odoo.com/odoo/2328/tasks/5388389) https://github.com/odoo/o-spreadsheet/commit/0cd9a76df9 [FIX] pivot_style: assert pivot is valid before creating a table [Task: 5932073](https://www.odoo.com/odoo/2328/tasks/5932073) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where dynamic pivot tables in the Enterprise version of Odoo were occasionally crashing. The fix, stemming from an update to the underlying o-spreadsheet library, ensures pivot tables are correctly recomputed and avoids creating invalid tables, resulting in a more stable user experience.
This update resolves an issue where users were encountering an error when uploading SVG images as logos in document layouts. The fix ensures that the system gracefully handles SVG uploads, preventing the error and allowing users to successfully configure their document layouts with SVG logos. This improves the user experience for logo customization.
Original PR description
Currently an error occurs when user tries to upload a svg image as a logo in document layout. Steps to replicate: - Initialize a db and open settings. - Under the Document Layout section, click on…
Currently an error occurs when user tries to upload a svg image as a logo in document layout.
Steps to replicate:
- Initialize a db and open settings.
- Under the Document Layout section, click on `Configure Document Layout`.
- In the logo field add any SVG image.
Error:
```
File '/home/odoo/odoo19/community/addons/web/models/base_document_layout.py', line 106, in _compute_logo_colors
wizard.logo_primary_color, wizard.logo_secondary_color = wizard.extract_image_primary_secondary_colors(wizard_for_image.logo)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo19/community/addons/web/models/base_document_layout.py', line 215, in extract_image_primary_secondary_colors
base_w, base_h = image.size
^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'size'
```
Cause:
- As user added an svg to the logo field, `tools.ImageProcess(logo)` tried to load the SVG which returned `self.image` as False because we dont process SVG or WEBP images [1].
- Later when we try to access `image.size` where image is false, we get error.
Solution:
- In earlier versions the method `base64_to_image()` was used [2], which raised an UserError on attempting `Image.open()` on a SVG.
- This error was caught by the try except block and returned `False, False` [3].
- To match to this behavior we return from the function when there is no image.
[1]: https://github.com/odoo/odoo/blob/4b2aaf2b711c9cfd8fd9f4a5915d6310064af6a9/odoo/tools/image.py#L83-L85
[2]: https://github.com/odoo/odoo/blob/39974cea6c37d21e21e3ed46a914d58f5ac16aad/addons/web/models/base_document_layout.py#L207
[3]: https://github.com/odoo/odoo/blob/4b2aaf2b711c9cfd8fd9f4a5915d6310064af6a9/addons/web/models/base_document_layout.py#L207-L211
sentry-7323084659
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue causing instability in automated tests for key Odoo features. We've removed a problematic setting that led to inconsistent test results and replaced it with a more reliable approach. This ensures our testing process is more stable and accurate.
Original PR description
In this commit, we remove the undeterministicTour key in 2 tours:
- test_form_view_mail_triggers
- test_form_view_custom_reference_field
We have replace assertions in run functions (sync) by pseudo selectors in triggers (async).
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
Backport of odoo/odoo#25083010 changes
Resolved issues and error corrections
This update resolves an issue where empty options were being saved and displayed in dropdown selectors within website forms. The fix ensures that empty 'Selection' fields are now automatically removed before saving, improving the user experience and data consistency. This was caused by a previous change affecting how form custom field values were handled.
Original PR description
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown…
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown selector. **How to reproduce the problem** 1. Drop a form 2. Add a "Selection" field (many2one) 3. Clear the text in one of the options in "Option List" 4. Save 5. The empty option is not removed, and shows up in the dropdown selector **Why the problem happens** Commit [1] introduced some changes to the action `SetFormCustomFieldValueListAction`, as a result, empty many2one options are not dropped anymore on apply. **Solution** The solution is applied on `BuilderList` (not only forms), as required by the task. `BuilderList.handleValueChange` now drops empty text fields before commiting changes, unless this violates `props.forbidLastItemRemoval`. The form action `setFormCustomFieldValueList` is changed such that the last entry is never removed even if its text is empty (unless `props.forbidLastItemRemoval` is false). task-5925171 [1]: https://github.com/odoo/odoo/commit/cb8469e9fe73f5c10b4e49d3462e0b23df2a047d
This update fixes a warning appearing in the Belgian VAT report due to an incorrect sign for tax code 61. The change ensures the report aligns with updated standards, preventing potential rejection by tax authorities. It corrects a formula discrepancy within the accounting data to ensure accurate VAT reporting.
Original PR description
Currently, in the Belgian VAT report, `61 – Various VAT regularizations in favor of the State` is displayed with a negative amount under `Taxes > IV Due`, which triggers a warning in the report.…
Currently, in the Belgian VAT report, `61 – Various VAT regularizations in favor of the State` is displayed with a negative amount under `Taxes > IV Due`, which triggers a warning in the report. **Steps to reproduce:** - Install the `l10n_be` module and switch to the `BE company CoA`. - Navigate to `Invoicing > Configuration > Taxes` and open any tax (e.g., 6%). - Replace the `Tax Grid` with `61` on the second line under `Distribution for Invoices`, then `save`. - Navigate to `Customers > Invoices` and create and confirm an invoice using this `tax`. - Navigate to `Reporting > Tax Report` and select the current month. **Observation:** - The report shows a warning: `The report contains negative amounts. This is normally not allowed and could cause the tax authorities to reject it.` - Case `61` under `Taxes > IV Due` displays a `negative` value. **Root Cause:** At [1], all formulas under `IV Due` use a negative sign (-XX) except for case `61`, which uses `61` instead of `-61`. Since the concept of `inverted tax tags` was removed in v19 in PR [2], case `61` must follow the same sign convention as the other `IV Due` cases to ensure correct reporting behavior. **Fix:** This commit updates the formula of case `61` to `-61`, aligning it with the other `IV Due` lines. As a result, the VAT report no longer displays an incorrect negative amount for case `61` and prevents the related `warning` from appearing. [1]: https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/l10n_be/data/account_tax_report_data.xml#L497-L596 [2]: https://github.com/odoo/odoo/pull/225252 opw-5866225 Forward-Port-Of: odoo/odoo#248961
This update fixes an issue where sign requests generated from HR wizards didn't automatically use the expiration dates defined on the sign templates. Now, all sign requests will adhere to the template's configured validity period, ensuring accurate tracking and preventing outdated requests.
Original PR description
Before, when sending sign requests from the HR custom wizards, the validity date defined on the sign template was not applied to the generated signature requests. As a result, requests were created without respecting the template’s configured expiration. task-5928110 Forward-Port-Of: odoo/enterprise#107076
This update resolves an issue where autocomplete fields weren't consistently saving manual changes made by the user. The fix ensures that the field's value is correctly updated after a user manually edits the input, preventing data discrepancies when saving the form. This improves data accuracy and reliability.
Original PR description
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because…
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because they basically render an input (spiced with the autocomplete feature), so they must handle "manual" updates (listen to `input`, `change`, `keydown` events), like regular input fields. However, the input also acts as a "search bar" for the autocomplete. As a consequence, it might happend that the `useInputField` hook internals weren't correctly reflecting the actual state of the field. Here's a faulty scenario to highlight the issue, involving any of the two widgets: - open a form view with the field set to value "XYZ" - type in the input "ABC" and select a suggestion from the autocomplete dropdown => say the value is now "Value ABC" - manually erase the content of the input and type "XYZ" as before - save => the value sent to the server was actually "Value ABC" The reason is that the hook still believes that the field is dirty after the value has been picked from the dropdown, and set (in the model) to "Value ABC", so `lastSetValue` isn't correctly updated to "Value ABC" (it's still "XYZ"). Later on, after the manual update to go back to the value "XYZ", we compare this value with `lastSetValue`, and as they are the same, we do nothing, so the value in the model remains "Value ABC". Those widgets need to use the hook, because the logic encapsulated inside it is really tricky and we don't want to duplicate it. But the hooks internals aren't exposed, and we don't want to expose them to keep it under control. So we did the fix inside the hook itself: in `useEffect`, so after a patch, if the value in the model is the same than the value in the input, it means that the field isn't dirty anymore, so we force-reset the flag to `false`. This scenario only makes sense for inputs that are handled both internally by the hook and externally (e.g. by the autocomplete). Task~6018655 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#252829
This update enhances the clarity of Odoo server logs related to data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or to see which specific model the data was imported into. This change makes it easier for support teams to investigate issues and improve the overall efficiency of data import troubleshooting.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update resolves a technical error that occurred when processing refunds in the Spanish Point of Sale (POS) module. Specifically, a 'singleton error' was triggered due to incorrect data being passed during refund operations. The fix ensures the correct order ID is used, preventing the error and ensuring refunds are processed smoothly.
Original PR description
Step to reproduce: - install l10n_es_pos - create a pos, open its setting and set its `Simplified Invoice` with a journal - start pos, create a order and refund it Observation: - we receive a singleton error for account.move Cause: - when calling `get_invoice_name` method, we pass `order_server_ids` which contains order and refund order id, hence two ids are passed Fix: - instead of using `order_server_ids` we use 'order.id' i.e. current order opw-5870707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251519 Forward-Port-Of: odoo/odoo#247986
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a bug where date formats like '2500/1222' were wrongly identified as '%Y.%m.%d'. This ensures that import files with various date formats are now processed accurately, preventing import errors and improving data reliability.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
This update resolves a minor typo in the name of a Belgian work entry type. The change ensures accurate reporting and categorization of overtime hours, specifically updating the description from "Overtime Hours not suject to social security contribution" to "Overtime Hours not subject to social security contribution".
Original PR description
Version: saas-19.1 Fix typo in belgian work entry type name: - from "Overtime Hours not suject to social security contribution" to "Overtime Hours not subject to social security contribution" Task-5946323
This update resolves an issue where the zoomable chart cursor was behaving unexpectedly. The changes remove certain interactive elements and add checks to ensure smoother chart navigation, enhancing the user experience. This improves the overall performance and reliability of the Odoo spreadsheet charts.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0f82c2f2af [REL] 19.1.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0f82c2f2af [REL] 19.1.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e05cd0e473 [FIX] Model: reject data that postdate the library version [Task: 5895572](https://www.odoo.com/odoo/2328/tasks/5895572) https://github.com/odoo/o-spreadsheet/commit/64b3655ed5 [FIX] spreadsheet: fix zoomable chart cursor [Task: 5012198](https://www.odoo.com/odoo/2328/tasks/5012198) https://github.com/odoo/o-spreadsheet/commit/056b5c51bc [IMP] functions: Add `ISFORMULA` function [Task: 6013888](https://www.odoo.com/odoo/2328/tasks/6013888) https://github.com/odoo/o-spreadsheet/commit/61f0761fd5 [FIX] charts: remove zoom slicer for scatter plot [Task: 5388389](https://www.odoo.com/odoo/2328/tasks/5388389) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a potential issue where the ECPay integration for Taiwanese companies wasn't working correctly. The change ensures the integration triggers accurately by checking the company's fiscal country instead of its physical address. This guarantees proper ECPay processing for all Taiwanese businesses using Odoo.
Original PR description
Previously, the module checked `company_id.country_id.code == 'TW'` to determine if Taiwan's ECPay logic should be applied. However, `country_id` only represents the physical address of the company. This commit replaces `country_id` with `account_fiscal_country_id` across the sale order model and website controllers. This ensures that the ECPay integration correctly triggers for any company using the Taiwan fiscal localization. Task-6002433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252464 Forward-Port-Of: odoo/odoo#251924
4 changes
Resolved issues and error corrections
This update fixes an issue where currency exchange difference values were missing from DATEV exports. The fix correctly uses the line balance instead of the currency amount, ensuring accurate reporting of exchange rates for DE company transactions. This improves the reliability of financial data sent to DATEV.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update resolves an issue where users were unable to set both a start and end date simultaneously within the web_studio feature. The fix prevents the creation of invalid date range fields, ensuring data consistency and a smoother user experience when configuring forms and workflows. This improves the reliability of the studio interface.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing when multiple bills were selected has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update fixes a previous issue where certain salary deductions (specifically 'ATTACH_SALARY') weren't correctly reflected in employee net pay calculations for the Kenyan payroll module. The changes add four new rules to the deduction line, adjusting their sequence and sign to accurately account for these attachments, ensuring accurate net pay reporting.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#107033
15 changes
Resolved issues and error corrections
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change skips adding redundant information to ensure compliance with regulations, preventing invoice submission errors. This ensures seamless integration with Peppol networks for Danish businesses.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update removes an unnecessary check for local network connectivity when opening cashboxes via IoT. Because Stable IoT Boxes are now reachable through a websocket, this redundant step has been removed, streamlining the process. This change improves the reliability of cashbox operations.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#107397
This update fixes an issue where sandwich leave durations were incorrectly calculated when public holidays were involved. The fix ensures that all date calculations are properly localized to the company's timezone, guaranteeing accurate leave duration calculations for employees. This improves the reliability of leave management.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#252466
This change corrects a typo in the XML format used when sending debit notes to the Italian SDI (electronic reporting system). The original error caused debit notes to be rejected, preventing accurate tax reporting. The fix updates a field name to ensure compliance with the required XML structure.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#252272
Forward-Port-Of: odoo/odoo#249284A recent issue causing Distro builds to fail during the quality control tour has been resolved. The fix increases a delay in the tour process to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing environment.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users could incorrectly set both a start and end date simultaneously within the web_studio interface, leading to a validation error. The fix prevents this conflicting input, ensuring date range fields function as expected and improving data accuracy. This change impacts the usability of date-based fields in project configurations.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update fixes a problem in the Odoo stock module where error messages about package consistency were unclear. Now, the messages specifically identify the problematic package, allowing users to quickly diagnose and resolve issues, especially during large product transfers. This improves efficiency and reduces support requests.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249290
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now gracefully handles this attachment type by converting it to a standard format, ensuring all emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill history. The system now checks the last posted bill to determine if lines should be grouped by tax, streamlining the import process and reducing manual adjustments. This improves data accuracy and efficiency for invoice processing.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#251948
Forward-Port-Of: odoo/odoo#251419This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (specifically, 2 payments instead of 4). This change improves the user experience by providing accurate information about the payment schedule. Additionally, the 'group payment' button is now correctly hidden when necessary.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#247830
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing under certain circumstances has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update fixes an issue where event tickets in the POS were not correctly calculating prices. Now, ticket prices will dynamically adjust based on the event's price or a linked pricelist, ensuring accurate pricing for event attendees. This improves the POS experience and prevents discrepancies in ticket costs.
Original PR description
Event tickets in POS would have their price locked to the price defined in the event itself. They would be filtered out of any price recalculation inside the POS to keep the POS from recalculating the price based on the `product_template` and to keep the price defined in the event itself. This PR will add event tickets back into price recalculation. It will set the price to the price defined inside the event if no pricelist is applicable, or use the pricelist to calculate the price if there is one applicable. Task-[5092613](https://www.odoo.com/odoo/project/1737/tasks/5092613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when generating lots without a defined sequence. The fix ensures the system handles cases where the lot sequence is initially empty, preventing a critical error and allowing users to correctly generate lot numbers. This improves the reliability of inventory management.
Original PR description
Currently, an error occurs when a user tries to generate lots while providing a lot number. **Steps to replicate:** - Install purchase (without demo). - Create a product `test`. - Install stock and…
Currently, an error occurs when a user tries to generate lots while providing a lot number.
**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.
**Error-1:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
self.ensure_one()
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```
**Error-2:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].
**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
assignment triggers only during the record creation, any records created
before stock is installed will not be assigned any value for
`lot_sequence_id`.)
- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].
**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**
**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.
**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.
[PR]: https://github.com/odoo/odoo/pull/240368
[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026
[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237
[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227
[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989
[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994
[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000
[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004
[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025
sentry-7254849206,7265844194
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a bug in how scrap quantities are calculated for products. Previously, if a product didn't have a related Bill of Materials, the calculation would stop, leading to incorrect scrap quantities being reported. Now, all products are correctly processed, ensuring accurate scrap tracking.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252149
This update fixes an issue where backorders were incorrectly doubling labour costs in the accounting system. When 'Create Backorder' is always enabled, a process triggered a duplicate labour entry. The fix ensures labour costs are only recorded once per workorder time, preventing inaccurate financial reporting.
Original PR description
When the Manufacturing operation type is configured with Create Backorder = Always, `mrp.production.pre_button_mark_done()` re-enters `button_mark_done()` in the same server execution path. This can trigger `_post_labour()` twice, causing two posted “<MO> - Labour” journal entries and doubling labour costs in Accounting. Labour costs should be posted only once per workorder time entry. Ensure labour is only posted once by skipping workorder times that were already linked to an accounting entry. This prevents a second execution from creating a duplicate labour journal entry. A test was added to cover the partial production flow when backorder is set to “Always.” Related ticket: opw-5931754 --- Forward-Port-Of: odoo/odoo#250237
5 changes
Resolved issues and error corrections
A recent issue causing tour tests to fail in our automated build process has been resolved. The fix increases the delay in the tour to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users were unable to correctly set both a start and end date for date range fields within the Web Studio design tool. The fix prevents the system from accepting both date fields simultaneously, ensuring data integrity and preventing invalid date range configurations. This improves the overall usability of Web Studio for creating date-based views.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update resolves conflicts in how Odoo handles Fiskaly transactions, particularly when using the API. It ensures that transactions are correctly cancelled or finished, preventing errors and maintaining data integrity. This improves the reliability of the POS system for our German clients.
Original PR description
Changes:
- cancelActiveTransactions: use the TSS-scoped endpoint
/tss/{tss_id}/tx and filter results by client_id so only orphaned
transactions from this terminal are cancelled, never those from
other POS sessions sharing the same TSS
- transactionCall: on non-retryable errors (400 revision conflict or
terminal state mismatch), call _handleTransactionStateConflict which
GETs the actual transaction state and recovers:
- Cancelling already CANCELLED → silent success
- Finishing already FINISHED → return existing tx data
- Finishing a CANCELLED tx → create a fresh transaction and finish it
- handleFiskalyCancellation: correctly reset transactionState to
inactive on the uiState after cancellation
opw-5972708This update resolves an issue where users with the invoicing & banks role were unable to access certain transaction views. The change ensures these users have the necessary permissions to view duplicate and missing transactions, aligning with previous improvements in Odoo 19.0. This ensures consistent access for key user groups.
Original PR description
In 19.0 we made a fix to allow users with the invoicing & banks role, to have access to duplicate transaction and missing transaction. https://github.com/odoo/enterprise/commit/748660f7ad9ca30d59f00e69d42a24864f1764d3 https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 This commit will allow user with that role to access those menus task-5998895 Forward-Port-Of: odoo/enterprise#109941
This update removes a redundant check for local network connectivity when opening cashboxes via IoT. Because Stable IoT Boxes are now accessible through a websocket, this check was unnecessary and causing potential delays. This change improves the reliability of cashbox operations.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#107397
9 changes
Resolved issues and error corrections
This update resolves an issue preventing automated tests from correctly opening the POS session. The changes update tour selectors to target the 'Open Register' button and modify the UI rendering to ensure the button is consistently accessible. This improves the reliability of our test automation.
Original PR description
In this commit:
- The POS open UI button is now rendered through a widget and no longer exposes the `name=open_ui` attribute. As a result, the existing tour selectors could not locate the button.
- Update the tour triggers to use `button:contains('Open Register')` so the POS session can still be opened correctly during tests.
Task:5425256
Related PR:
- Community: https://github.com/odoo/odoo/pull/241641
- Upgrade: https://github.com/odoo/upgrade/pull/9205This update resolves an issue preventing correct validation of data properties within the Knowledge and Spreadsheet Edition modules. The fix ensures data integrity and proper functionality for these key features, improving overall system stability.
Original PR description
This commit corrects wrong props validation schema that could not work.
This update fixes a technical issue within Odoo's VoIP system. Previously, the system relied on a single data field for status updates, which created maintenance challenges and lacked crucial information like employee access tokens. This change ensures accurate and complete status updates, improving the reliability of the VoIP feature.
Original PR description
Just reading `im_status` instead of the dedicated method makes the maintenance harder and it is potentially problematic as it doesn't return the `im_status_access_token` nor the necessary extra information from employee records to compute out of office. https://github.com/odoo/odoo/pull/252008
This update resolves a minor visual issue in the Helpdesk module related to the 'Rotting days' field. The change improves the field's appearance and usability by applying a standard UI element. This ensures a consistent and polished user experience for Helpdesk users.
Original PR description
This commit fixes the UI of the 'Rotting days' field, by wrapping it in a o_input_box div and using the o_input_box_overlay_end and the o_input_box_overlay_inline classnames. task-6025631
This update streamlines the spreadsheet experience by grouping data sources into organized submenus under 'Data' and 'Charts'. This change addresses a previous crash related to dynamic pivot tables and enhances usability by reducing the length of the Data menu, making it easier for users to find the information they need.
This update removes a temporary flag from the account reports tour, signifying that it is now fully functional and reliable. This ensures users can consistently access and utilize the tour without encountering unexpected issues. The change improves the overall stability of the account reporting feature.
Original PR description
This commit removes the 'undeterministicTour_doNotCopy' flag from the 'account_reports_sections' tour. This indicates that the tour is now stable.
This update removes a temporary flag from the account reporting audit tour, signifying that it is now reliably functional. This ensures consistent and accurate reporting processes for users. The change improves stability and reduces potential issues with the audit tour.
Original PR description
This commit removes the 'undeterministicTour_doNotCopy' flag from the 'account_reports_audit' tour. This indicates that the tour is now stable.
This update corrects a technical issue where incorrect class names were being used in several Odoo modules. The change ensures all elements use the correct 'o_input_box_overlay_inline' class, improving the stability and consistency of the system. This resolves a potential inconsistency that could have impacted user experience.
Original PR description
In commit [1], the class 'o_input_box_overlay_inline' was introduced, but many elements were using an invalid 'o_input_box_inline' class instead of that one. This commit replaces all the wrong implementation of inline suffixes by the right one. [1]: dc8f38b1054664a0e382530bb4fc73983e2085cb
This update resolves an issue where users couldn't enter values in the 'Allocated Time' field within the planning module, particularly when a break time was scheduled. Now, the field functions correctly with a standard input box, ensuring accurate time tracking and scheduling.
7 changes
Resolved issues and error corrections
This update resolves a problem where Odoo Enterprise spreadsheets could crash when taking screenshots to save as thumbnails. The fix prevents the spreadsheet from being unexpectedly closed during the screenshot process, ensuring thumbnails are consistently saved. This improves spreadsheet reliability and data backup functionality.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update corrects a technical issue preventing electronic invoices under the RIMPE Emprendedor regime from being properly processed. The change ensures the correct string value is used for the invoice type, resolving a validation error related to the invoice's electronic signature. This ensures compliance with Ecuadorian tax regulations.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update resolves an issue preventing users with the invoicing & banks role in Odoo 19.0 from accessing key transaction management features. The change grants these users the necessary permissions to view and manage duplicate and missing transactions, improving their workflow efficiency. This fix was implemented based on previous commits to ensure proper role-based access control.
Original PR description
In 19.0 we made a fix to allow users with the invoicing & banks role, to have access to duplicate transaction and missing transaction. https://github.com/odoo/enterprise/commit/748660f7ad9ca30d59f00e69d42a24864f1764d3 https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 This commit will allow user with that role to access those menus task-5998895 Forward-Port-Of: odoo/enterprise#109941
This update corrects a calculation error in the HRA (House Rent Allowance) rules for Indian employees. It now accurately applies the HRA percentage based on employee categories, and importantly, skips the rule when the percentage is zero, ensuring consistency with standard India payroll regulations. This ensures accurate HRA payments for our Indian workforce.
Original PR description
… fields - compute HRAMN from categories['BASIC'] with result_rate = l10n_in_hra_percentage * 100 - add python condition to skip the rule when HRA percentage is zero - keeps ind_emp behavior consistent with regular India payroll rules task-5964270
This update ensures the title of the embedded account report within the annual report is displayed in the user's selected language. Previously, the report title remained in English regardless of the user interface language setting. This change improves the user experience by providing localized content.
Original PR description
### Issue before this commit: When generating the annual report, the title of the embedded account report displayed in the table of contents remained in English even when the user interface language was changed. ### Steps to reproduce the issue: 1. Install another language than english and switch to that one 2. Install Accounting app and audit modules 3. Go to Accounting > Revision > Annual Report 4. Create an Annual Report and click on it 5. Index is in the correct language but the title inside is not ### Cause of the issue: The issue occurred because the name property passed to the AccountReportComponent was not translated. Reason to introduce the fix: To translate the embedded account report title according to the user’s current language. opw-5958383
This update fixes a technical issue in the Odoo Studio view editor that was causing a crash when switching between fields. The fix ensures the sidebar accurately reflects the selected field's properties, improving the user experience and preventing errors. This resolves a stability problem within the Studio interface.
Original PR description
In studio, form editor: click on a field and check the sidebr is correct Click on another field, one that has the widget many2many_tags. Before this commit, there was a crash because the internals of the sidebar were computed with the wrong props (the old ones instead of the new ones) After this commit, there is no crash opw-6004776
This update resolves a bug where users accessing Odoo through a secondary domain were incorrectly redirected to the main domain, preventing them from viewing their documents. The fix ensures that the documents smart button correctly directs users to the appropriate domain based on their login location, improving document access for all users.
Original PR description
Steps to reproduce:
- Have two domains for your database (".odoo.com" and ".example.com")
- set the ".example.com" domain as your web base url
- login on the ".odoo.com" domain, go on an employee and click the documents smart button
-> you cannot see any documents because you are redirected on the ".example.com" domain on which you are not connected
opw-585791410 changes
Resolved issues and error corrections
This update fixes a potential error in how Odoo fetches Instagram poll IDs. Previously, attempting to retrieve the ID before a poll was fully published would cause an API error. Now, Odoo checks the poll's status first, and only requests the ID when the poll is successfully published, preventing errors and ensuring reliable poll functionality.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325
This update resolves a recurring issue where the Italian POS system generated errors when offline, specifically when printing receipts. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing crashes and improving the user experience. This ensures reliable operation even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090
This update fixes an issue where the HTML editor would reset its selection after opening the command palette. The change ensures the current selection is maintained, providing a smoother and more intuitive editing experience. This improves usability and reduces potential frustration for users.
Original PR description
Before this commit: when the whole editable regains the focus, the selection in the editable is reset to the start of it. After this commit: We create a override for hotkey service to open the command palette with an onClose to refocus the editable area without losing the current selection. For the hotkey override, we pass the area option so it's only valid in the editable area. Outside the editable, the command palette is opened in the default way. task-5949705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a confusing error message in the Odoo stock module that previously didn't identify the specific package causing the issue. By adding the package name to the error, users can quickly diagnose and resolve problems, especially during large product transfers. This improves usability and reduces support requests.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249290
This update resolves an issue where emails with attachments using the 'bin/plain' MIME type would cause the system to fail to process them. The fix now handles this attachment type by falling back to a standard format, ensuring all incoming emails, including vendor bill creation, are correctly processed.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update ensures that self-order prices are consistently calculated by the backend before payment processing. Currently, changes made to product prices via the client-side interface could lead to incorrect payment amounts without any notification. This fix guarantees accurate pricing for self-order transactions, improving financial reporting and trust.
Original PR description
The price computation is done on the backend only for combo products. This means that someone can order stuff on the self order, change the price of the products through JS on the client, and then when they go to pay the backend would generate a payment for the modified price and register everything as normal without any indication to the owner that the price was modified. This change will force the backend to recompute the price before creating the payment based on the standard prices defined on the backend. This only applies on self orders, so cashiers should still be able to modify prices on the frontend of the normal POS Task-[5864068](https://www.odoo.com/odoo/project/1737/tasks/5864068) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in the payroll batch payslip wizard where the displayed contract type was incorrectly defaulting to the first contract, regardless of its status. Now, the wizard accurately reflects the running contract type for employees with multiple active contracts, ensuring accurate payroll calculations.
Original PR description
Currently, in the batch payslip wizard, the 'Salary Structure Type' is determined by the first contract found for the employee. ### **Steps to Reproduce:** 1) Install Payroll. 2) Create an employee…
Currently, in the batch payslip wizard, the 'Salary Structure Type' is determined by the first contract found for the employee. ### **Steps to Reproduce:** 1) Install Payroll. 2) Create an employee with two contracts: - Contract A: Expired, From DEC 1st 2025 to 31st DEC 2025, salary structure as 'Employee' - Contract B: Running, Starts from Jan 1st 2026, salary structure as 'worker'. 3) Navigate to Payroll>payslips>Batches and click 'Generate Payslips'. ### **Observed Behaviour:** The column displays the Structure Type of Contract A(Expired): `Employee`. ### **Expected Behaviour:** The column should display Contract B(Running) in the Structure Type column: `Worker`. ### **Root Cause:** The `structure_type_id` field was defined as a related field on `contract_ids`. Due to this, it always fetches the first record based on the default sort order. ### **Fix:** Replace the relation of structure_type_id with `contract_id`. To ensure running contracts (state='open') are recieved, regardless of their start dates. **opw-5311933**
This update fixes several issues related to the mobile view of online orders, including missing buttons and order cancellation problems. Users can now consistently access order details and seamlessly cancel Swiggy online orders, improving the overall mobile ordering experience. This enhancement ensures a smoother and more reliable process for mobile users.
Original PR description
*: pos_restaurant_urban_piper Before this commit: ========== - "Load Order" and "Review" buttons were not visible for online orders. - The "Review" button was missing for paid online orders, preventing users from reviewing their orders. - The "Info" button was not visible for paid orders, restricting users from checking order details after payment. - A traceback occurred when cancelling a Swiggy online order. After this commit: ========== - Improved mobile view for online orders, ensuring a more consistent user experience. - Fixed the issue preventing Swiggy online order cancellations, allowing seamless cancellations. Related PR: - https://github.com/odoo/odoo/pull/213769 task-4657597
This change reverts a recent update that was causing unnecessary complexity in stock management. Previously, multiple stock transfers for the same supply chain were grouped together, streamlining the process for users. This prevents the creation of redundant pickings and reduces manual effort, particularly in scenarios like replenishing warehouses.
Original PR description
This reverts [1]. Let's quote the commit: > - `Observation`: the next transfers for both receipts are merged into a single > transfer, even though both receipts were created manually and not generated > from any common source document like PO/SO. The above behavior was and is the expected one for years and should not suddenly change on stable. Even the tests were protecting the cases but [1] have changed the `assert`. Commit [1] quickly leads to the creation of tickets. For instance, in the mentioned OPW, where the user resupplies a warehouse from another one: he now has several pickings for the same supply chain, which lead to extra work (e.g., printing all the pickings) [1] https://github.com/odoo/odoo/commit/840b42fd2365a652e53d607f38ac78ccb8dd63dc OPW-6011532
This update reverts a previous change that disrupted the initial state of quality control tests. This fix ensures that the tests are functioning correctly, preventing potential issues with product quality checks. The change is related to a previous revert and is tracked under OPW-6011532.
Original PR description
This reverts [1]. It happens because of a revert OC side, cf linked commit. [1] a01d8f0e15de973a94c360c3911e74b768a3aebc OPW-6011532
3 changes
Resolved issues and error corrections
This change corrects a naming error in the ZUGFeRD eInvoice XML file, resolving validation issues with several key e-invoice validators. Previously, the validator incorrectly flagged the file, but now the ZUGFeRD file passes validation across multiple platforms, ensuring proper e-invoice processing and compliance.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057
This update resolves an issue where appraisals marked as 'invisible to the manager' were incorrectly visible after switching companies within a multi-company setup. The fix ensures that appraisals remain hidden from managers when the employee and manager are in different companies, improving data security and user experience. This prevents managers from accessing appraisals they shouldn't see.
Original PR description
**Issue:** An employee's appraisal marked as "invisible to the manager" becomes visible to the manager when switching companies (the other company should be checked) **Steps to reproduce:** 1. Ensure the environment is configured for a multi-company setup (with both companies active). refer to the screenshot bellow  3. Create an appraisal as a user (e.g., demo): - Go to Appraisals -> New - Select an employee and a manager (e.g., Mitchell Admin) - Uncheck "Visible & Editable by Manager" - Confirm 4. Log out and log in as the chosen manager. 5. Go to the Appraisal Module. 6. Navigate to the previously created appraisal. 7. select the other company The feedback becomes visible when selecting the other company opw-4273581