Daily updates from Odoo
Wednesday, March 18, 2026
67 changes · saas-19.2
Resolved issues and error corrections
This update fixes an issue where backorders were incorrectly doubling labour costs in the accounting system. When a backorder is created, the system was inadvertently posting labour twice. The fix ensures labour costs are only recorded once per workorder time entry, 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#253689 Forward-Port-Of: odoo/odoo#250237
This update adjusts the validity period of a demo certificate used in testing for the Peruvian Electronic Invoice (PEI) module. The original certificate expired, causing a test to fail. This change extends the certificate's lifespan by ten years, ensuring accurate test results and avoiding disruption.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058 Forward-Port-Of: odoo/enterprise#110719
This update resolves an issue where dashboard loading would fail if a user lacked read access to certain data models. The fix now checks models with `sudo()` for those without user permissions, ensuring dashboards consistently load correctly for all users. This improves the overall dashboard experience.
Original PR description
## Description When opening a dashboard, `_dashboard_is_empty()` may call `search_count()` on one of the dashboard's main data models to decide whether sample data should be loaded. If the current user does not have read access to one of these models, `search_count()` raises an access error and the dashboard loading can fail, even though the user has access to the dashboard itself. To avoid this, only unreadable models are checked with `sudo()`, while readable models are still evaluated with the current user rights. This prevents the access error in `_dashboard_is_empty()` and allows the dashboard to open instead of failing early. Task: [5905166](https://www.odoo.com/odoo/project/2328/tasks/5905166) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253277 Forward-Port-Of: odoo/odoo#249784
This update resolves an issue where downpayment products weren't correctly linked to downpayment lines in sales orders. The fix ensures that downpayment products are properly added when a downpayment is made, addressing a previous reporting problem related to settlement processing. This improves the accuracy of sales order data.
Original PR description
Step to reproduce - install pos_sale - create a SO (make sure it is in draft) - open pos, make sure it has downpayment product - do a downpayment for that SO - go to backend, open SO Observation: - The downpayment product is not linked to downpayment line Cause: - After refactor [1], downpayment product is not added in sale line [1] https://github.com/odoo/odoo/commit/175daa5db6a3f16be6b636a36e2b8462306b2eb4 Fix: - Added the product when creating downpayment line **Note:** - Actual issue reported was different, and was side effect of this issue - there, the downpayment was not considered when trying to settle SO from pos opw-5934461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250548
This update resolves an issue where users couldn't select 'Other Expenses' as an option for expense accounts within the Loan module. This change now allows for greater flexibility in categorizing loan-related expenses, ensuring accurate financial reporting. It's a minor fix improving usability within the Enterprise suite.
Original PR description
Allow accounts with the "Other Expenses" type to be selected in the Expense Account field of Loans. task-5946452 Forward-Port-Of: odoo/enterprise#110085
A recent change in required field validation caused an error when starting a new pay run in the Hong Kong payroll module. This update ensures that date fields are validated before the system attempts to process them, resolving the 'value.toFormat is not a function' error. This prevents users from being unable to initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338 Forward-Port-Of: odoo/enterprise#108885
This update fixes a minor issue where the dynamic snippet carousel wasn't displaying correctly when showing a small number of items. The fix ensures a smoother, more consistent scrolling experience, particularly when the carousel contains fewer items than the visible slide slots. This improves the overall presentation of product listings.
Original PR description
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode…
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode (`o_carousel_multi_items`) and the number of fetched items is less than or equal to the visible slots per slide (`chunkSize`, typically 4 on desktop), the carousel still slides one item at a time. Cause: When `scrollMode` is single, the QWeb template generates each data item in its own `carousel-item` div. So with 3 products and 4 visible slots, we got 3 separate slides(this is the usual behavior of single scroll mode). But due to this bootstrap would slide between them one by one. Fix: If the number of fetched records is less than or equal to the number of elements per slide (chunkSize), use "all" scroll mode so that all items are grouped in a single slide instead of being split into individual carousel-items (which would cause unwanted sliding). Forward-Port-Of: odoo/odoo#251916 Forward-Port-Of: odoo/odoo#251700
This update resolves a technical issue that prevented the automated download of vendor invoices from the Polish KSeF system when rate limits were exceeded. The fix ensures the system handles these rate limit errors gracefully, preventing errors and allowing the scheduled action to continue functioning correctly. This improves the reliability of the Polish e-invoicing process.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Run scheduled action "Polish eInvoice: Download vendor bills from KSeF" 3. If the customer gets 429 Too Many Requests => A traceback error is raised as message isn't an attribute in KSeFRateLimitError object `AttributeError: 'KSeFRateLimitError' object has no attribute 'message'` This happens because `KSeFRateLimitError` does not define a `message` attribute. The message is only passed to the base Exception and stored in `args`. After this commit: Use `str(e)` to properly retrieve the exception message and avoid the AttributeError. opw-6009380 Forward-Port-Of: odoo/odoo#253549
This update resolves an issue where the icon toolbar was unexpectedly appearing in the To-Do module when inserting a Table of Contents. The fix removes a redundant check within the HTML editor that triggered this behavior, ensuring a smoother user experience. This improves overall usability and prevents unnecessary distractions.
Original PR description
Steps to Reproduce: - Go to To-Do. - Inside a list, insert a Table of Contents. - Click at the top, outside of the Table of Contents. Description of the issue - The icon toolbar appears unnecessarily. Cause: - This happens because the `icon_plugin` checks whether a node’s child contains an icon and, if so, displays the icon toolbar. Although the Table of Contents contains an icon, this condition passes, causing the toolbar to appear. - The same issue can occur with other elements that contain an icon. For example pressing enter before a star element also opens the icon toolbar. Solution: - Remove the condition that checks whether a node’s child contains an icon. task-5954459 Forward-Port-Of: odoo/odoo#250918
This update enhances the way error messages are handled within the Odoo account_peppol module. Previously, messages were based solely on error codes, making debugging difficult. Now, the system captures and uses the full server error, providing more detailed information for troubleshooting and improving client support.
Original PR description
Before this commit, all messages where mapped based on the error code and not from the server error. Schematron/XSD issues really need the full error to make easy for debugging/client. OPW-5980046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252252
This update fixes an issue where the time slot selection popup stretched unnecessarily across the screen, creating empty space. By adjusting the popup's size to fit its content, the design is now cleaner and more user-friendly. This improves the overall visual experience for users.
Original PR description
The o_modal_full class forces height: 100% on modal-content and modal-body, causing the time slot selection popup to stretch to full screen with empty white space below the content. Override height and top on modal-content and modal-body to let the dialog shrink to fit its content while staying anchored at the bottom of the screen. task-id: 5952769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure caused by an overly sensitive check for loading indicators (fa-spin). The trigger has been removed, ensuring that minor delays in the system don't incorrectly flag test failures. This improves the stability and reliability of the POS Restaurant Preparation display.
Original PR description
In this commit: = - Removed the trigger that checks for `fa-spin` as it was causing test failures when minor delays occurred between steps. - Checks for `fa-spin(Sync)` is alredy handled by the `isSynced` or `waitRequest`. Runbot-error: [198580](https://runbot.odoo.com/odoo/error/198580), [234025](https://runbot.odoo.com/odoo/error/234025) Forward-Port-Of: odoo/enterprise#87281
This update fixes a bug where the product search bar didn't function correctly on mobile devices. The issue was due to a missing configuration in the search template, which prevented the search from executing. The fix ensures that product searches work as expected across all device views, improving the user experience for mobile shoppers.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page.…
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page. - Switch to `mobile view`. - Now search for `drawer` in product search. Issue: --- - In mobile view, the search does not work. When performing a search, nothing happens, and the request is not executed. Root cause: --- - At [1], in the search template definition, the action attribute is missing in the search form. Solution: --- - Set the form action using keep(search=0) instead of leaving it undefined. - This ensures that the search behaves correctly depending on the context (global or category-scoped). [1]https://github.com/odoo/odoo/blob/51f59a293de1e86f66f30257f8fc0c419463d18c/addons/website_sale/views/templates.xml#L2239-L2259 opw-5992052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254221 Forward-Port-Of: odoo/odoo#251694
This update ensures that the 'File' constructor in Odoo correctly receives the MIME type of uploaded files. This change aligns with Chrome's latest standards, improving compatibility and preventing issues with older browser versions. It's a technical fix to ensure proper file handling.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/odoo#254154 Forward-Port-Of: odoo/odoo#253631
This update ensures that new files created within the Odoo Enterprise system correctly identify their file types (mimetypes). This fix aligns with modern web browser standards, specifically Chrome 146, and improves compatibility across different browser versions. It prevents potential issues with file handling and data processing.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/enterprise#110812 Forward-Port-Of: odoo/enterprise#110496
This update corrects a misconfiguration in the Hungarian (l10n_hu) version of Odoo. Previously, the 0% EU Goods Intra-community tax was incorrectly linked to external partners. This change ensures the tax is correctly associated with EU partners only, aligning with Hungarian tax regulations and improving data accuracy.
Original PR description
In Hungary, the 0% Goods Intra-community tax is mapped with the EU partner & Partner outside the EU, which doesn't make sense. Intra-community taxes should only be mapped with the EU partner fiscal position. This commit removes the outside EU position from this task. no-task Forward-Port-Of: odoo/odoo#253526
This update simplifies how users manage icons within the website's accordion feature. Previously, users could toggle icons inline, which was a confusing and inefficient process. This change removes the inline editing option, streamlining the process to the sidebar for better usability.
Original PR description
In the accordion snippet option, the user can set the icons as custom to choose them. He can do so in the sidebar with the options "Active / Inactive Icons", or by double clicking on them. Since clicking on the icon open / close the accordion item, switching from one icon to the other, it is not a practical way to edit them that way. It was decided to remove the possibility to edit the icon inline. task-5885917 Forward-Port-Of: odoo/odoo#246937
This update ensures the title of the embedded account report within the annual report correctly reflects the user's selected language. Previously, the report title remained in English regardless of the UI 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 Forward-Port-Of: odoo/enterprise#109962
This update resolves an issue where users with dark mode enabled in their browsers (like Brave) experienced usability problems with the self-order and point-of-sale features. A simple meta tag has been added to prevent interference from the Dark Reader extension, ensuring a smoother experience for all users.
Original PR description
Users who have enabled the dark mode option in Brave that automatically modifies website colors may experience usability issues with the self-order and point_of faile. To avoid this, a meta tag has been added to disable Dark Reader modifications . Task.6037294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253892
This update ensures that NACHA payment files accurately reflect the actual account holder's name, rather than the customer's name in Odoo. Prioritizing the bank account holder's name improves payment processing accuracy and compliance with NACHA regulations.
Original PR description
The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108414 Forward-Port-Of: odoo/enterprise#105582
This update corrects a bug that prevented users from removing external members with edit access from spreadsheets after archiving. The fix updates validation logic to distinguish between adding and deleting access rules, resolving existing warnings and preventing future issues. This ensures accurate spreadsheet access management.
Original PR description
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly…
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly prohibited. However, due to a validation error in the access rights wizard, users were unable to fix this. Cause: The validation logic in `documents_sharing.py` performed checks after any action was taken. If an illegal configuration was detected, it set a flag to hide the Save button. Because the check did not distinguish between adding an illegal rule and deleting one, users were blocked from removing the very records causing the validation failure. Solution: The validation checks have been updated to account for the operation- type (addition or deletion). This ensures that while new illegal rules are still blocked, existing illegal rules can be successfully removed to restore the system to a valid state. A test was also added to prevent this problem form happening in the future. This PR applies uses the solution to fix the state of 3 warnings, ensuring they are only displayed when actually relevant. Specifically, it covers: - The warning triggered when removing external users with edit access in `documents_spreadsheets`. - The `has_warning_no_access` warning in documents. - The `has_warning_link_with_more_rights` warning. task-5902391 Forward-Port-Of: odoo/enterprise#110668 Forward-Port-Of: odoo/enterprise#108140
This fix resolves an issue where orders created through the MPS weren't consistently grouped into single RFQs, leading to duplicate RFQs being generated. The update ensures that the system correctly handles date formats when searching for existing purchase orders, preventing the creation of new POs unnecessarily. This improves order management efficiency.
Original PR description
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2…
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2 - Order - Change the forecast to 5 - Order - Go to RFQs > There are 2 different RFQs Cause ----- When doing `_run_buy`, no existing PO is found https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102 so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15 However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB. https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10 This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime. ----- Ticket: opw-5171041 Forward-Port-Of: odoo/enterprise#106968
This update resolves a bug where a caption remained visible after replacing an image with a different media type (like an icon) within the HTML editor. The fix ensures that the caption is automatically cleared when the image is replaced, preventing errors and improving the editor's stability. This ensures a smoother user experience when switching media types.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Add a caption on an image - Click on image - Replace image by an icon using replace option from Toolbar - Putting cursor on caption input and clicking anywhere outside editable leads to traceback. This happens because after replacing image with an icon, caption is still there but there is no image inside caption. As result, in `cleanForSave` accessing image leads to traceback. **Desired behavior after PR is merged:** Now, if image is replaced by any other media than image, caption is removed. task-5950977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253723 Forward-Port-Of: odoo/odoo#249452
This update resolves an issue where clicking on partner mentions within Odoo didn't always open the partner's avatar popover. The fix ensures that all partner mentions, regardless of the 'o_mail_redirect' class, correctly trigger the avatar popover functionality. This improves the user experience when interacting with partner communications.
Original PR description
Currently, if the mention is a partner without the "o_mail_redirect" class, clicking on it does not open the partner avatar popover. This commit fixes this by also checking if the model is "res.partner" and in this case, all the links will be checked in all the cases, not only those with the "o_mail_redirect" class. task-5978136 --- 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 importing website configurations. The issue stemmed from a mismatch in required fields between modules, specifically related to the 'ecommerce_platform' setting. The fix ensures the correct module is installed based on import needs, preventing the error and allowing users to successfully import their websites.
Original PR description
This error occurs when attempting to import a website from the Website settings. Steps to reproduce: - Install `website` module - Website > Configurations > Settings > `Import Website` - `Website…
This error occurs when attempting to import a website from the Website settings. Steps to reproduce: - Install `website` module - Website > Configurations > Settings > `Import Website` - `Website URL`(eg: `https://iap-scraper.odoo.com/`) > `Import my website` Traceback: `ValueError: Invalid field 'ecommerce_platform' in 'website_generator.request'` The `ecommerce_platform` field is defined in the `website_generator_sale` module. However, when this module is not installed, we still add this field in vals/[data] from the `website_generator` module. Because of this, when importing a website, the `import_website` method is called and a `website_generator.request` [record] is created. Since the `website_generator_sale` module is not installed, the `ecommerce_platform` field does not exist on the `website_generator.request` model, which results in an error. Solution: We only install the `website_generator_sale` module if the `ecommerce_platform` and `import_products` fields is present in `kwargs`. [data]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_generator/static/src/client_actions/import_form/import_form.js#L228 [record]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_generator/models/website.py#L33 sentry-7324538798
This update resolves an issue where the Documents Activity view became unusable after exiting Studio, preventing users from filtering or adding new activities. The fix ensures the view correctly loads necessary data, restoring full functionality and preventing frustrating user experiences.
Original PR description
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch…
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch views to fix it. Specifically: - Filters can no longer be selected. - Adding new activities throws UI errors (even if technically successful). Cause: The `getSelectedFolder` method returned undefined because the `searchPanel` logic was skipped. The Activity view does not display the `searchPanel`, so the model failed to run `_fetchSections` which retrieves the data used by `getSelectedFolder`. Under normal circumstances, the view relies on data already loaded by the Kanban or List views, but that data is unavailable here. Solution: - Force the search model to load the data explicitly, ensuring the view initializes correctly regardless of the `searchPanel` visibility. We kept the dependency upon `_fetchSections` rather than removing it, as it is required by the `search_model` to maintain other features like `breadcrumbs`. - Add a test to verify the fix and prevent regression. Co-authored-by: Pierre-Yves Dufays <pydu@odoo.com> Co-authored-by: Charlier Florian <flch@odoo.com>
This update resolves an error that occurred when users attempted to change the employee within the salary simulation feature. The fix ensures the system correctly handles versioning during this process, preventing a runtime error. This improves the stability and usability of the salary simulation functionality.
Original PR description
Currently, an error occurs when user tries to change simulation employee in salary simulation. Steps to replicate: - Install `hr_contract_salary_payroll` with demo. - Open any employee (e.g.- Abigail…
Currently, an error occurs when user tries to change simulation employee in salary simulation.
Steps to replicate:
- Install `hr_contract_salary_payroll` with demo.
- Open any employee (e.g.- Abigail Peterson).
- Click `Simulation` > Change `Yearly Employer Cost` to `Gross Per Month`.
- Try to change the Employee, error will occur.
Error:
```
File '/home/odoo/odoo19/enterprise/hr_contract_salary_payroll/models/hr_contract_salary_offer.py', line 157, in _compute_offer_values_from_template
version = offer._get_version()
^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo19/enterprise/hr_contract_salary/utils/hr_version.py', line 39, in hr_version_context_wrapper
raise RuntimeError(
RuntimeError: Method '_get_version' must be called within a savepoint context. Use `hr_version_context(...)` context manager before calling this method.
```
Cause:
- The method `_get_version()` has the decorator `@requires_hr_version_context()` which makes the method to be callable within a savepoint context for `hr.version` [1] i.e. it can only be called within a `hr_version_context()` block.
- As here the method was not called under the `hr_version_context()`it raises an error from [here].
Solution:
- Used the `hr_version_context()`block instead of savepoint (similar to [this]).
[this]: https://github.com/odoo/enterprise/pull/108005/changes#diff-97aeb940d5058abc95cb617e5a2015320c37e8d50a15cffc2c08eac1839ac16dL98-R100
[here]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L39-L42
[1]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L14-L17
sentry-7335824597This update resolves an issue where clicking 'View' links after deleting a website page (like 'ContactUs') didn't function correctly. The fix ensures that links redirect to the correct records by using the model name instead of the display name in the URL, improving the user experience.
Original PR description
**Steps to reproduce:** 1. Go to the list view of website pages. 2. Select the page "ContactUs". 3. Click Delete. 4. A warning dialog appears. 5. Unfold one of the lists of records where the page is used. **Issue** Clicking on a record link (for example, "View") does not redirect anywhere. This is due to the use of the model display name in url. caused by https://github.com/odoo/odoo/commit/de302c2d36305c0d7562572a30587641eabfe914 **Fix** Use the model_name instead of the display name in the URL. task-5880458 Forward-Port-Of: odoo/odoo#245932
This update resolves an issue where default values for selection-type salary inputs weren't being correctly displayed in payslips. The fix ensures that newly added inputs are properly configured, preventing incorrect data from appearing on payrolls. This improves data accuracy and reliability for payroll processing.
Original PR description
Steps to reproduce: - Create a Salary Input of type 'selection'. - Assign a default value to this input. - Add the input to a payslip. Bug Cause: The form view is not re-comupting the values when it's assigned for the first time since the container is not changed Solution: Forcefully update the payroll_properties when we add new inputs in the payslip form task-5357904 Forward-Port-Of: odoo/enterprise#106469
This update reverts a recent change related to the Eco Voucher benefit within the Belgian payroll module. This change was causing issues with payroll calculations and has been corrected. The removal ensures accurate and compliant payroll processing for users in Belgium.
Original PR description
Forward-Port-Of: odoo/enterprise#110515
This update resolves an issue where upload widgets within dropdown menus on small screens wouldn't function correctly. The fix ensures that dropdowns remain open while users interact with these widgets, allowing uploads to complete as expected. This improves the user experience for mobile and tablet users.
Original PR description
## Issue: On small screens, when an upload widget is placed inside a dropdown (e.g., Upload Bill from a Purchase Order), the action does not work Clicking the dropdown item closes the dropdown immediately, which prevents the widget action from completing ## Cause: Widget actions require an accessible anchor element to function properly. However, dropdown items automatically close the dropdown on click As a result, the widget is triggered but immediately detached from the DOM before its action can fully execute ## Steps to reproduce: - Install `purchase_stock` (to have the Upload Bill widget available) - Create and confirm a Purchase Order (the Receive button must be available) - Reduce the browser width until the action buttons collapse into the three-dots menu - Click Upload Bill and try to upload a document opw-5918379 Forward-Port-Of: odoo/odoo#254083 Forward-Port-Of: odoo/odoo#251492
This update corrects a bug where resending invoices to MER would overwrite existing addendums, even if the invoice hadn't been sent. The fix ensures that existing addendums are updated instead of creating new ones, streamlining the invoice processing workflow and preventing data inconsistencies. This improves the reliability of invoice handling.
Original PR description
Issue: when resending an invoice already sent to MER, the existing addendum is overwritten even when the invoice is not sent to MER. Solution: updating values on the existing addendum rather than creating a new one, if it already exists. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254006 Forward-Port-Of: odoo/odoo#253281
This update resolves an issue where the copyright background color wouldn't apply correctly when the footer had no background color. The fix adds a fallback value to ensure the copyright color is consistently displayed, regardless of the footer's background setting. This improves the visual consistency of the website.
Original PR description
Before this commit, a css error would happen when the user tried to change the copyright background color if the footer had no background color.
This was due to $-footer-color not having a fallback value when neither o-color('footer-custom') nor o-color('footer') was defined.
This commit adds a fallback value to fix the issue.
task-5452457
Forward-Port-Of: odoo/odoo#248283This update prevents the Studio report editor from using Odoo's default theme colors. Previously, these colors were unintentionally available, leading to inconsistent styling. Now, the report editor has controls to manage theme color usage, ensuring reports maintain a consistent look and feel.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form `o-color-[n]` with n some integer) Those colors are a bit special (see…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form `o-color-[n]` with n some integer) Those colors are a bit special (see full discussion on the opw) - Their existence is described in module `web` - Their CSS definition is implemented in module `html_editor` - Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface. Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo. This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them. After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor. 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#253115 Forward-Port-Of: odoo/odoo#251446
This update resolves an issue where the Odoo Report Editor was unintentionally influenced by default theme colors, causing instability. The change restricts the report editor's customization options to avoid conflicts with the core Odoo theme, ensuring a more reliable and predictable report generation experience. This improves the overall stability of the Studio module.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer) Those colors are a bit special (see full…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)
Those colors are a bit special (see full discussion on the opw)
Their existence is described in module web
Their CSS definition is implemented in module html_editor
Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.
Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.
This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.
After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.
see odoo/odoo#251446
opw-5892573
Forward-Port-Of: odoo/enterprise#110164
Forward-Port-Of: odoo/enterprise#109206This update fixes an issue where creating users for employees with identical email addresses would cause an error. The change now displays a warning instead, allowing users to create multiple employees with the same email without disrupting the system. This improves user experience and data integrity.
Original PR description
Creating users for multiple employees sharing the same email address raises a traceback.
Stpes to reproduce the error:
- Install the ``hr`` module
- Create two employees with the same email
- Go to List view of employees > Select both employees > Actions > Create user
Traceback:
```py
ValueError: UniqueViolation('duplicate key value violates unique constraint "res_users_login_key"
```
https://github.com/odoo/odoo/blob/0bfd2a253781e43b0e0d16b3fd9d1df485f4fa6b/addons/hr/models/hr_employee.py#L389
The error occurs because the same email is used as the login for multiple users.
This commit ensures that when multiple employees share the same email address,
a warning notification is displayed instead of raising an error.
sentry-7324335174
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253258This update fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The solution allows users to manually specify the fulfillment channel (FBA or FBM) for each listing, resolving a known Amazon issue and improving order accuracy. This ensures correct stock management and prevents revenue loss.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update resolves a technical issue that prevented users from correctly editing transactions after multiple reconciliation lines were created. The fix ensures that the system handles reconciliation accurately, regardless of the number of reconciled lines, improving reporting reliability. This change impacts the accounting module.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879 Forward-Port-Of: odoo/enterprise#110857
This update resolves an issue where salary fold settings weren't consistently updating within the Odoo configuration interface. The fix ensures that changes made to salary fold settings are accurately reflected, improving the reliability of employee compensation management. This impacts how HR teams manage and track employee salaries.
Original PR description
Forward-Port-Of: odoo/enterprise#110950
This update resolves an issue preventing Sales users from printing quotes containing Intrastat product information. Previously, access was restricted, requiring Accounting group membership. The fix ensures all users with access to the quote can print it, streamlining the sales process and eliminating a potential roadblock for users.
Original PR description
**Steps to reproduce:** - Install Accounting, Sales and account_intrastat - Create a user with Sales rights only - Create a product with an Intrastat Commodity Code - Connect with the created user - Create a SO with the Intrastat product - Print PDF Quote **Issue:** An access error is raised while trying to access "account.intrastat.code" field. The user needs to have an Accounting group in order to access this field. **Cause:** When printing the quote, the SO is exported in a XML to be embedded in the PDF. The field is accessed at that moment. opw-5976725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254333
Previously, email attachments in Odoo were displayed as raw base64 strings instead of their actual HTML content. This change fixes a technical issue where an update to the ORM caused all binary fields to be returned as base64. This update now correctly decodes the email content, ensuring attachments are displayed properly in the kanban view and attachment viewer.
Original PR description
When opening an email document from the kanban view or the attachment viewer, the content is currently displayed as a raw base64 string rather than the actual HTML text. This happens because an ORM update standardized the `read` method to always return binary fields (including `raw`) as base64-encoded strings to prevent RPC serialization crashes. Because the frontend was still expecting raw HTML text directly from the RPC response, it failed to render the emails correctly. This change was introduced in odoo/odoo@a6de2a5f This commit updates the kanban record and attachment models to explicitly decode the base64 payload back into a UTF-8 string upon fetching, restoring the correct display of email contents. Task-6012504
This update fixes a discrepancy in invoice status after SDI validation for Italian tax invoices. Previously, the system didn't automatically update the invoice's status to reflect the Public Administration's (PA) state, leading to potential rejection issues. This change ensures accurate status tracking and prevents invoices from being incorrectly flagged as rejected.
Original PR description
### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891 Forward-Port-Of: odoo/odoo#254406 Forward-Port-Of: odoo/odoo#253525
This update ensures image galleries have truly unique IDs within Odoo, preventing conflicts when saving and refreshing pages. Previously, the same ID could be assigned to multiple galleries, leading to unexpected behavior and data inconsistencies. This fix guarantees each gallery has a distinct ID, improving page stability and data management.
Original PR description
Commit [86a3f41] called `uniqueId()` to generate the image gallery id in the builder options. However, `uniqueId()` is only unique in the course of the current client session. As a result, you could drop a gallery, save your page, refresh it, edit the page and drop another gallery with the same id as the 1st one. Steps to reproduce: - Drop an image gallery - Save - Refresh - Go back to edit - Drop another image gallery => Check their ids. It's very probable that they are the same. - Save - Click on the "Previous" or "Next" arrow of the 2nd gallery => it updates the 1st carousel, not the 2nd one. [86a3f41]: https://github.com/odoo/odoo/commit/86a3f41a71a91c656a9969a4ef251f8c2ce3a266 Forward-Port-Of: odoo/odoo#254225 Forward-Port-Of: odoo/odoo#253960
A test was failing due to inconsistencies in the timing used to verify the automated retrieval of invoices. This update ensures a consistent and reliable measurement of the retry delay, preventing future test failures. This improves the stability of the l10n_pl_edi module.
Original PR description
The test `TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after` was failing with a stack like following, because the `now()` time was taken after the cron was executed, making the time diff sometimes shorter than the required 120s.
```
FAIL: TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after
Traceback (most recent call last):
File "/data/build/odoo/addons/l10n_pl_edi/tests/test_l10n_pl_edi.py", line 619, in test_l10n_pl_edi_download_bill_retry_after
self.assertGreaterEqual(capt.records[-1].call_at, fields.Datetime.now() + timedelta(seconds=120))
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2026, 2, 21, 4, 20, 7) not greater than or equal to datetime.datetime(2026, 2, 21, 4, 20, 8)
```
runbot-241016
Forward-Port-Of: odoo/odoo#254234This update resolves an issue where Mollie payments were failing due to Odoo not consistently sending address data as strings. The change adds default empty string values to address fields, ensuring Mollie's API receives the correct data format and preventing errors.
Original PR description
When a partner has no country (or other address fields) set, accessing `partner_country_id.code` (and similar Char fields) returns `False` in Odoo instead of an empty string. This caused Mollie's API to return a 422 error because it expects a string for `billingAddress.country`. Add `or ""` fallbacks to all string fields in `_mollie_prepare_billing_address_payload` to ensure valid JSON types are always sent. opw-6037640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254187
This update corrects a bug in the DIAN invoice processing workflow. Previously, the system incorrectly deleted the original invoice document, potentially leading to data loss. This fix ensures the correct invoice document is protected during the update process, maintaining data integrity.
Original PR description
**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147 Forward-Port-Of: odoo/enterprise#110455
This update resolves an issue where users were unable to set both a start and end date for a date range field within the web_studio design tool. The fix prevents simultaneous modification of both date fields, ensuring the date range field is correctly validated and displayed. This improves the usability of the studio and prevents data entry errors.
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#110580 Forward-Port-Of: odoo/enterprise#108562
This update resolves a potential memory issue that could occur when opening the Point of Sale (POS) session. The change optimizes how product unit of measure records are retrieved, preventing excessive data loading and improving overall system performance. This ensures a smoother and more reliable POS experience for our users.
Original PR description
Before this commit, while opening a session in the POS, all the `product.uom` records were retrieved regardeless of what products were loaded. This might cause a memory error in cases where a lot of records are being retrieved. A solution for this is to retreive the records **only related to the `product.product` records being retrieved**. opw-5408586 ___ I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249044 Forward-Port-Of: odoo/odoo#240613
This update fixes an issue where time off leaves were incorrectly displaying instead of accurate return dates. The change ensures that employee profiles now show the correct return date for worked-time leaves, improving the accuracy of leave scheduling and reporting.
Original PR description
Issue: - When a time off type was configured as , adding a leave for today caused the employee form to display instead of a real date. Fix: - Compute leave dates for all validated leaves, including worked-time leaves. - Ensure the date is always computed using the first working interval after the leave end date. Impact: - Employee profiles now display a correct return date for worked-time leaves. task-5421688 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#254040 Forward-Port-Of: odoo/odoo#241329
This update fixes an issue where closing the emoji or GIF picker by clicking outside would prevent it from reopening. The change ensures the picker state is correctly reset, allowing users to reopen it immediately with a single click. This improves the user experience and avoids unnecessary clicks.
Original PR description
**Current behavior before PR:** When the GIF or emoji picker is dismissed by clicking outside, the component state remains out of sync because `props.onClose` isn't triggered. This causes the next attempt to open the picker to fail, requiring an extra click from the user. **Desired behavior after PR is merged:** Closing the picker now correctly triggers the `props.onClose`. This ensures the component state is always reset, allowing the picker to reopen immediately on the next click. task-[5953015](https://www.odoo.com/odoo/project/1519/tasks/5953015) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254051 Forward-Port-Of: odoo/odoo#250630
This update resolves an issue where users on Firefox couldn't hear incoming calls through their softphones. The fix ensures the system correctly processes incoming call tracks as soon as they're available, regardless of the session establishment timing. This improves the Odoo VoIP functionality for Firefox users.
Original PR description
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the…
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the call, answer => The caller can hear you but you cannot hear the caller. This happens since [1]. Before that commit, we had something like "when the session is established, listen to tracks being added to the call and also set up the audio". After that commit, this became "when the session is established *or is establishing*, listen to tracks being added to the call... *but don't set up the audio otherwise*". The problem is that on Firefox, the timing is such as the tracks of incoming calls are being added just before the session is establishing (or established), meaning we listen to tracks being added too late. Note that commit [1] was further diluted afterwards by commits like [2] (doing stuff with the audio before establishing) and [3] (which simply removed the "established" part, relying on "establishing" being done). Later on, commit [4] prepared some other work by moving and improving things around and it actually fixed this issue here by chance. What did the trick is listening to tracks being added from the start: as soon as SIP.js notifies that the remote stream exists. This commit fixes the issue in impacted versions (19.1 and 19.2) by backporting the relevant part: listening to tracks being added as soon as possible and not once establishing/established. A test was added. [1]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf [2]: https://github.com/odoo/enterprise/commit/71d78810ae7f6c9169912276da18e04ad4f7bef0 [3]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e [4]: https://github.com/odoo/enterprise/commit/33fc327c1c74ee874d546a98879dbbf468809850 task-5902700 Forward-Port-Of: odoo/enterprise#110833
This update fixes an issue where timesheet descriptions weren't consistently updating when values were changed within the grid view. The fix ensures that new timesheet lines created from updated values retain the original description, maintaining accurate reporting and data integrity. This improves the usability of the timesheet feature for users.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#110800 Forward-Port-Of: odoo/enterprise#108894
This update resolves issues related to physical card processing, specifically for UK users, improving the reliability of expense tracking. It includes fixes for missing ETA information and shipping status errors, ensuring accurate expense reporting and preventing test failures.
Original PR description
Forward-Port-Of: odoo/enterprise#110263
This update fixes an issue where the 'Edit Menu' button's text was overlapping within the link preview. The change ensures all buttons within the preview display correctly, providing a cleaner and more consistent user experience. This improves the visual clarity of the HTML editor.
Original PR description
Before this commit: the Edit Menu button's text stacks when the url's preview is loaded. After this commit: we make sure the button isn't wrapped for all the buttons inside the link preview. task-6036771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253646
This update removes an unwanted 'Discard' label from the AI Documents auto-form modal. The label was automatically added when a cancel button was used, creating a less intuitive user experience. This change ensures a cleaner and more straightforward interaction for users working with document automation.
Original PR description
Purpose ======= The default label "Discard" is now automatically added on button with `special="cancel"`. For the auto-form modal in document we don't want that label, and so we force the string to be empty. Task-6004879
This update resolves an issue preventing the accurate calculation of social media click KPIs due to a recent change in how UTM tracking is handled. The fix adapts the KPI computation to reflect the new 'utm_reference' logic, ensuring reports accurately reflect social engagement. Note: clicks across all companies are visible, which is a known limitation.
Original PR description
Steps to reproduce the error : ============== 1. Go to Settings -> Technical -> Digest Emails 2. Open any Digest record 3. Click `Send Now` or `Test` -> A traceback occurs. Issue ============= A…
Steps to reproduce the error : ============== 1. Go to Settings -> Technical -> Digest Emails 2. Open any Digest record 3. Click `Send Now` or `Test` -> A traceback occurs. Issue ============= A previous refactor of Social UTM tracking: - removed `source_id` from social.post and now stores post reference directly in link.tracker (utm_reference) - removed `utm_medium_id` from social.account The "Social Media Clicks" digest KPI computation still relied on `social.post.source_id` and `social.account.utm_medium_id`. Since these fields were removed, the SQL query fails with a “column does not exist” error. Fix ============= Update the KPI computation to adapt to the new utm_reference logic Note ============ If a post is posted across all companies, its clicks are visible to all companies. This is an expected limitation of the new utm_reference logic See https://github.com/odoo/enterprise/commit/0058e409cd9ae4868bc8ed974f34f29d26c1f7df for more details task-5960183
This update ensures that the 'this' field is now required in the timesheet timer form. This change improves data accuracy and consistency, preventing incomplete timesheet entries and ensuring proper tracking of employee time spent on tasks. It's a necessary step to maintain reliable timesheet reporting.
Original PR description
`this` is now mandatory
This update resolves issues where the AI chat experienced unexpected errors and crashes, providing a better user experience. Now, the AI chat displays informative messages like 'oops' or 'Connection Interrupted' when errors occur, ensuring smoother operation and preventing data loss during interruptions.
Original PR description
Steps to reproduce: 1. Open the Website Editor 2. Select some text 3. Click the AI tool from the toolbar 4. Send a message in the chat window 5. Observe a non-standard error dialog showing 500 HTTP…
Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error
The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.
This commit improves error handling for both public and internal AI chat
by:
- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.
The following behavior will now be observed during error in the UI.
- Public AI chat:
- Initial fetch failed: shows "oops" message
- Stream interrupted:
- Server handled: shows "oops" message
- Server stopped: shows "Connection Interrupted" dialog
- Internal AI chat:
- Initial fetch failed: show RPCError dialog
- Stream interrupted:
- Server handled: shows RPCError dialog
- Server stopped: shows "Connection Interrupted" dialog
We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.
TASK-ID: 5886825
Forward-Port-Of: odoo/enterprise#105875This update resolves an issue where the batch view in the Enterprise module incorrectly displayed multiple "Validate" buttons. The fix ensures that only one button is visible, streamlining the quality check process for users. This change improves user experience and prevents confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#109911 Forward-Port-Of: odoo/enterprise#107993
This update fixes an error in the calculation of the mobility budget for Belgian HR contracts. The previous calculation incorrectly treated the budget as a fixed amount instead of a percentage, leading to inaccurate cost projections. This change ensures the yearly mobility budget cost is computed correctly, providing more reliable financial reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#110827
This update resolves an issue related to currency reconciliation in stock valuation processes. The changes streamline testing for accurate valuation calculations, particularly concerning invoice and purchase order impacts, ensuring consistent and reliable financial reporting. This improves the stability and accuracy of the purchase stock module.
Original PR description
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#246101 Forward-Port-Of: odoo/odoo#245551
This update resolves an issue where the filters button disappeared when using the 'Off-screen Menu' style for shop pages. The fix ensures the button remains visible, providing consistent filter access regardless of the chosen display style. This improves the user experience for customers browsing products.
Original PR description
Versions -------- - 19.1+ Steps ----- 1. Disable all pricelists to hide pricelist filter 2. Go to shop page 3. Change Filters style to "Off-screen Menu" - Note that a "Filters" button appears next to the sort by dropdown 4. Remove the sort by from the toolbar by untoggling it Issue ----- When the filters are set to off-screen and there is no sort by dropdown or pricelist dropdown, the filters button disappears. Cause ----- The div containing the filters button, sort by dropdown, and pricelist dropdown, is set to `d-lg-none` when there is no pricelist dropdown and no sort by dropdown, causing it do disappear. Solution -------- Only allow the div to disappear when the filter button shouldn't appear (`wsale_has_filters_btn` set to False) opw-5933858 Forward-Port-Of: odoo/odoo#249750
This update resolves an issue where the batch view in the stock picking module incorrectly displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the batch creation process and improving user experience. This change corrects a visual inconsistency.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/odoo#252630 Forward-Port-Of: odoo/odoo#249581
This update prevents ribbon customizations from being lost when creating new ribbons. Previously, changes to ribbon options would reset to default values. The fix ensures the ribbon is fully saved to the database before updates are applied, improving the stability and reliability of ribbon customization within the website builder.
Original PR description
When creating a new ribbon and immediately changing its options, the title and colors would unexpectedly reset to None. This happened because the ribbon was not fully saved in the database before we tried to update its settings, causing the changes to be lost. Now we wait for the ribbon to be properly created and assigned its database identifier before applying any updates. A mapping system tracks the relationship between temporary and final identifiers to ensure changes are always applied to the correct ribbon. task-5503716 Forward-Port-Of: odoo/odoo#253727 Forward-Port-Of: odoo/odoo#227626
This update fixes a calculation error related to leave allocations that don't have a defined end date. Previously, the system incorrectly tracked taken hours when allocations were open-ended. Now, allocations without end dates are treated as continuous, ensuring accurate leave hour calculations across all reports.
Original PR description
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after…
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after each allocation start date - Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report. ### Cause: After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery. ### Fix: Following the same approach we use in if the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date opw-5474596 Forward-Port-Of: odoo/odoo#254053 Forward-Port-Of: odoo/odoo#250432
This update fixes an issue where the layout of PDF quotes generated with the Din5008 localization module was broken when sections were hidden. Specifically, the column alignment and section background positioning were misaligned. The fix adds a column span to the section names to ensure proper formatting and a consistent user experience when generating PDF quotes.
Original PR description
Steps to reproduce ================== - Install website_sale,accountant,l10n_de - Select the DE company - In the accounting settings, enable the "Show Position Column in Reports" - Go to Sales - Create a new Quotation - Select a customer - Add a product - Add a section - Click on the three dots - Click on Hide Composition - Add another section - Click on the cog menu - Click on Print > PDF Quote => The background of the first section ends before the end of the line => The columns are also not aligned Solution ======== Add a colspan of 2 to the section names opw-5427590 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#252029
This update fixes a problem in the transfer wizard tests where certain chart of accounts configurations caused errors during posting. The change filters accounts to avoid secondary currency issues, ensuring all transfer moves now post correctly and maintain the expected business processes. This improves the reliability of our testing environment.
Original PR description
Description of the issue this commit addresses: test_transfer_wizard setUpClass selected generic non-reconcile accounts. In some charts one account enforces a secondary currency causing move_1.action_post() to fail with a UserError. --- Desired behavior after this commit is merged: This commit filters accounts to those without forced account currency so setup moves always post without changing tested business flows. --- runbot-241090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254193