Daily updates from Odoo
Tuesday, May 5, 2026
38 changes · saas-19.1
Resolved issues and error corrections
A small typo in the quality module caused new quality alert records to be incorrectly grouped as 'None'. This update corrects the typo, ensuring records are properly assigned to the correct stages when created. This resolves a potential issue with data accuracy.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update corrects a technical issue that was causing unwanted options to appear in the email marketing builder. Specifically, it ensures the image transform option is hidden, and adds visibility to the Background Color and Border options. This improves the user experience and consistency within the mass mailing builder.
Original PR description
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced…
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced the `OptionComponent` with some modified version. As the `OptionComponent` is no longer present in the base option, patching the same won't use the modified option. Hence, the option became visible in the mass mailing builder. This commit adapts the mass mailing builder with the refactoring of the options API to keep the image transform option hidden. [commit]: https://github.com/odoo/odoo/commit/179480d996a19dff4d56265a610259b1c6e33f99 Commit 2 ------------------- ### Steps to reproduce 1. Open Email Marketing 2. Open/Create a Mailing 3. In the editor, insert an `Alert` block. --------> Some options won't be visible. ### Technical The [commit] restructured the `Alert` snippet, therefore, for the builder to identify the mass mailing's alert block, we need to adapt the selector of the option to `.s_mail_alert`. After this commit, the following options will become visible (which were invisible before the commit): - Background Color - Border Option Note: 1. mass_mailing's `Alert` option now correctly uses the mass mailing's option template. Which included different size options, but those are now already added by `size_option_plugin`. Therefore this commit also removes those redudant size options from the alert option. 2. The width option for the `Alert` block is already added by original `width_option_plugin`, therefore we remove the patch of the selector inside mass mailing to avoid redundancy. [commit]: https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6 Task-5999942 Forward-Port-Of: odoo/odoo#260923
This update resolves an issue preventing the `sale_stock` and `purchase_stock` modules from installing correctly on databases with existing sale or purchase orders that include non-stock items like downpayments. The fix filters out these lines during the installation process, preventing a software error and ensuring proper module functionality.
Original PR description
## Summary When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:…
## Summary
When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:
ValueError: Expected singleton: uom.uom()
## Root Cause
The `post_init_hook` (`_create_pickings_for_open_sale_orders` / `_create_pickings_for_open_purchase_orders`) filters order lines to create pickings:
```python
empty_lines = open_sale_orders.order_line.filtered(
lambda l: l.product_uom_id.is_zero(l.qty_delivered)
)
```
This accesses product_uom_id without checking if it exists. Lines with:
- display_type set (sections, notes)
- is_downpayment = True (downpayments)
...don't have a product_id or product_uom_id, causing the error.
Fix
Add filters to skip non-stock lines before accessing product_uom_id:
```
empty_lines = open_sale_orders.order_line.filtered(
lambda l: not l.display_type and not l.is_downpayment and l.product_uom_id.is_zero(l.qty_delivered)
)
```
Steps to Reproduce
1. Create a fresh database (without sale_stock/purchase_stock)
2. Create a sale order with a downpayment line or section/note
3. Install sale_stock module
4. Error: ValueError: Expected singleton: uom.uom()
Reproduction Reference
- purchase_stock issue: https://drive.google.com/file/d/1aKw-ago-pMds_-x_y9f8nJZyZsLqGJ67/view?usp=sharing
- sale_stock issue: https://drive.google.com/file/d/1I9fY8UZZZ3ULcairl3YGZTi_KttsYLNR/view?usp=sharing
opw-6179073
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prAn error prevented users from importing emissions data through the Emitted Emissions menu. This fix restricts imports to manual emissions, resolving a database conflict issue related to journal entry emissions. This ensures data integrity and stability within the ESG reporting functionality.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587 Forward-Port-Of: odoo/enterprise#115856 Forward-Port-Of: odoo/enterprise#115306
This update ensures that 'Final Consumer' records are correctly created as individuals, not companies, within the Odoo system. The previous issue stemmed from incorrect test assertions related to anonymous document creation. This fix resolves the problem by explicitly setting the 'Final Consumer' type to 'individual' and updating associated tests.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751
This update simplifies the process for Dutch companies to manage their digipoort certificates. Previously, users had to navigate between separate menus to create and select a certificate. Now, users can directly create and edit digipoort certificates within the main Accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update resolves an issue where users couldn't access equity information for partners linked to companies they didn't have access to. The change adds a 'company_id' field to equity models, allowing the system to correctly identify and display equity data for all partners, regardless of their associated company.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771 Forward-Port-Of: odoo/enterprise#110724
This update resolves an issue where the survey module would fail to load background images due to an outdated reference to a component that was no longer used. The fix ensures the background image loading process is correctly implemented, preventing the error and improving the survey experience. This ensures surveys load correctly and reliably.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update resolves visual issues with Saudi document layouts by dynamically updating VAT information and ensuring the correct paper format is applied to all Saudi companies. This improves the accuracy and presentation of invoices and other financial documents for our Saudi customers.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where translations for the Dutch returns module (l10n_nl_returns) were missing in the system's configuration. Adding these translations ensures accurate and localized functionality for our Dutch-speaking customers. This resolves a potential problem with incorrect display or functionality.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update corrects a setting for Thai WHT (Withholding Tax) taxes, ensuring they don't automatically generate closing entries. WHT uses separate accounts, simplifying reporting and aligning with local tax regulations. This change improves the accuracy of WHT financial reporting.
Original PR description
Set tax closing entry to False by default for WHT taxes, as WHT uses separate payable accounts and does not require closing entries. task-6146195 Forward-Port-Of: odoo/odoo#262464
This update resolves a visual glitch where the user status icon on the dashboard displayed a grey question mark instead of the correct work location. The fix standardizes the data format used for user status, ensuring the icon accurately reflects the user's location setting. This improves the user experience and consistency.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `hr_homeworking` module 2. Go to User > Calendar Tab 3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun) 4. Go back…
Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload
Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.
Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.
Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format
`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons
opw-6064997
Forward-Port-Of: odoo/odoo#258829This update fixes a technical issue that caused a traceback when canceling an empty order in the Point of Sale (POS) system, specifically when loyalty programs were active. The fix ensures the POS dialog is closed before order deletion, preventing a re-render and the resulting error. This improves stability and prevents unexpected errors during order cancellation.
Original PR description
Steps to reproduce: = - Enable loyalty in the POS configuration. - Add an eWallet program for this POS. - Open a table and cancel the (empty) order using the "Cancel Order" control button. Issue: = - A traceback occurs: `TypeError: Cannot read properties of undefined (reading 'getTotalWithTax')` Reason: = - When clicking "Cancel Order", the order is deleted and `currentOrder` becomes `undefined`. - During the re-render of `ControlButtons` on the product screen, there is no active order, which leads to the traceback. Fix: = - Ensure the `ControlButtons` dialog is closed before deleting the order to prevents the re-render of `ControlButtons` without an active order and avoids the traceback. task-6030182 Forward-Port-Of: odoo/odoo#261775 Forward-Port-Of: odoo/odoo#254337
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we
Original PR description
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.…
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`. - When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678` ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6148039) opw-6148039 Forward-Port-Of: odoo/odoo#262339 Forward-Port-Of: odoo/odoo#261964
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_ka
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259305
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render incorrectly. Steps to produce: --- - Install the `website_sale` module. - Go to Settings and enable `Prevent Sale of Zero Priced Products`. - Create a product with a sales price of `0` and publish it. - Open the product on the website. - Open the editor and change the purchase style to `Box`. Iss
Original PR description
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render…
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render incorrectly. Steps to produce: --- - Install the `website_sale` module. - Go to Settings and enable `Prevent Sale of Zero Priced Products`. - Create a product with a sales price of `0` and publish it. - Open the product on the website. - Open the editor and change the purchase style to `Box`. Issue: --- - The price text renders incorrectly inside the box. Root Cause: --- - At [1], the `<span>` element responsible for rendering the price text does not check whether zero-price sale prevention is enabled, causing the price string to appear regardless. - At [2], after hiding the price span, the `o_wsale_cta_wrapper` element still renders an empty box because no corresponding guard exists there either. Solution: --- - Add a conditional check on the price `<span>`: apply `d-none` when zero-price sale prevention is active, so the price string is not displayed. - Also, add the same zero-price sale prevention check on `o_wsale_cta_wrapper` to avoid rendering an empty box when no price is shown. [1]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2233 [2]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2221 Before: --- <img width="1488" height="689" alt="image" src="https://github.com/user-attachments/assets/5b3a565f-5ced-4d75-b538-63abc3690e09" /> After: --- <img width="1457" height="612" alt="image" src="https://github.com/user-attachments/assets/1e04fe54-98b6-4e1c-bd26-4d56bb34b90e" /> opw-5994812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261313 Forward-Port-Of: odoo/odoo#252666
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
Original PR description
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
This update resolves an issue where Amazon order-related stock movements incorrectly showed 'False' as their reference. The code has been updated to use the `reference` field instead of `name`, ensuring accurate tracking of these movements within the Odoo system. This prevents reporting errors and improves the reliability of Amazon order fulfillment data.
Original PR description
Issue ----- Commit d0c1e78 removed the `name` field of `stock.move`. Instead, we now use the `reference`field, which is computed in `_compute_reference` https://github.com/odoo/odoo/blob/2ec714b19e2c56bff965ab32f7e6a4485df2d247/addons/stock/models/stock_move.py#L357-L369 The problem is that there is no picking linked to the move, so `move.reference` is set to `False`. This means that, after we go through the override in `sale_amazon`, we end up with `Amazon move: False` https://github.com/odoo/enterprise/blob/596d8c1216b33c1f73feb8f60eef1b69a2164579/sale_amazon/models/stock_move.py#L10-L14 ----- Ticket: opw-5969357 Forward-Port-Of: odoo/enterprise#114345
This update simplifies the process for creating Unsplash attachments, reducing complexity and potential security risks. Previously, broad access rights were required, but now only the necessary permission to set the attachment URL is granted, improving efficiency and maintainability. This change ensures secure and streamlined image uploads.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
This update resolves an issue where the 'delete' action was unexpectedly removed after installing the 'data_cleaning' module for attachments. The change prevents the module from overriding the standard attachment view, restoring the original functionality. This ensures users can consistently delete attachments through the standard interface.
Original PR description
Steps: - Enable debug mode - Go to Attachments view (list) - Select several items - Actions -> You have delete - Install `data_cleaning` - Do the same - Actions -> You don't have delete anymore Context: - `IrUiView` has 16 by default for `priority` field and order set as `priority,name,id`. - `IrAttachment` has a default view with no name, so `ir.attachment` is taken by default. - `data_cleaning` creates a view named `Storage Detail` with no priority specified (so 16 by default) on model `ir.attachment`. That makes the `ir.attachment` view from `data_cleaning` before the original one if we use the order "priority,name,id", as both of them have 16 in priority and `Storage Detail` is before `ir.attachment`. This commit restore the previous behaviour by preventing `data_cleaning` from overriding original `ir.attacmhent` view. opw-6149907 Forward-Port-Of: odoo/enterprise#115421
This update fixes a potential issue where errors during holiday creation wouldn't be properly handled. The code was adjusted to ensure that errors related to holiday data are caught and addressed, leading to a more reliable and stable holiday management process. This improves the overall user experience.
Original PR description
this commit, in this PR:https://github.com/odoo/odoo/pull/242299 the create method was refactored to wrap only the _create_all_new_leave call in a try/except block, ensuring that ValidationError is caught at the correct. Task-6179171 Forward-Port-Of: odoo/odoo#262175
This update corrects a technical error in the l10n_ch_hr_payroll module that was causing a system error. The change replaces an outdated function (`get_param`) with a more modern approach (`get_bool`), ensuring the payroll module functions correctly within the new saas-19.1 environment.
Original PR description
ref commit: https://github.com/odoo/odoo/commit/142eab81dad3f88afa18c0db99007db2288a85df `get_param` is no longer available in saas-19.1 and above, and it was causing a traceback.
This update fixes an issue where warning messages from the IoT blackbox were incorrectly treated as errors. Now, warning messages are displayed as notifications, providing clearer visibility into the status of IoT data processing. This improves the user experience and helps identify potential issues more effectively.
Original PR description
Before this commit, all errors returned by the iot after a call to the blackbox were considered as errors. Actually, the errors are only the ones that do not start with 0 (no error) or 1 (warning). This commit changes the behaviour when handling warning. We now show a notification. task-id: 5062178 Forward-Port-Of: odoo/enterprise#109251 Forward-Port-Of: odoo/enterprise#93896
This update resolves an issue preventing non-admin internal users from accessing the website generator import feature. The fix grants read-only access to a broader group of users, ensuring a smoother import process without impacting system security. The website generator systray now functions correctly for all users.
Original PR description
Steps to reproduce: =================== 1. On a 19.1, launch a website import as admin 2. Log in as a non-admin internal user => AccessError on website_generator.request Cause: ====== The website generator systray polls `website_generator.request` on every page load: https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/website_generator/static/src/systray_items/generator_request.js#L48 Only `base.group_system` had access on the model, so any non-admin user hit an AccessError as soon as an import request existed (session_info sets show_scraper_systray=True for everyone based on the last request's notified flag). Solution: ========= Grant read-only access to `base.group_user`; writes/creates stay restricted to system so the import flow itself is unchanged. => Systray loads silently, shows status indicator opw-6092411
This update fixes a restriction that prevented users from deleting time off requests after a payslip had been validated. Previously, the system incorrectly blocked deletion, even if the time off wasn't included in the payslip. This change ensures the system correctly handles time off requests regardless of payslip validation status.
Original PR description
## Issue After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved. ##…
## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
- Date: anywhere during March
- **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**
## Cause
The condition to raise the error message does not take into account the state of the leave:
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204
This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.
(related to)
opw-6089990
Forward-Port-Of: odoo/enterprise#115765This update fixes an issue where users were encountering errors when authorizing multiple Shopee shops through a Shopee Account. Now, the system correctly reuses authorization tokens, streamlining the process and preventing duplicate requests. This ensures smoother onboarding and access for users connecting multiple shops.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
This update resolves an issue where users were encountering a 'Missing Required Fields' error when unchecking 'Registered Under GST' for Indian VAT settings. The fix ensures the GST username field is only required when the relevant VAT features are enabled, preventing the error and allowing users to correctly configure their settings.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001 Forward-Port-Of: odoo/enterprise#114423
This update resolves an issue in our testing environment where a key field, `route_ids`, was hidden, causing test failures. The change ensures this field is visible during testing by enabling a necessary setting, allowing the test setup to function correctly and accurately reflect product routing. This improves the reliability of our automated tests.
Original PR description
The setup in `TestMultistepManufacturingWarehouse` was failing with: ``` AssertionError: field 'route_ids' is not visible ``` This happens because the `route_ids` field on the product form view is only visible when `has_available_route_ids` is True, which depends on having at least one `product_selectable` route. This commit enables `product_selectable` on those routes in the test setup, so that `route_ids` becomes visible and the Form helper can access it safely. [RB-232576](https://runbot.odoo.com/odoo/error/232576) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237293
This update resolves an issue where incorrect pivot IDs were used in purchase and vendor dashboards. The fix ensures accurate data reporting by updating the pivot identifiers within the dashboard's JSON configuration file. This improves the reliability of the purchase and vendor data displayed in the dashboard.
Original PR description
This commits fixes the pivot id in some formulas. Task: 5875749 Forward-Port-Of: odoo/enterprise#114559
This update resolves an issue where tour flows for purchase and stock modules didn't function properly in community builds. The fix leverages an existing utility function to ensure the tours correctly open the relevant apps, regardless of whether the enterprise version is installed. This ensures a consistent user experience for community users.
Original PR description
The tours: - `test_basic_purchase_flow_with_minimal_access_rights` - `test_basic_stock_flow_with_minimal_access_rights` fail to perform the first step if enterprise is not in the addons path since the app icons are not in the the main view. Fortunately, a general util is already present to perform the task of opening the app in both community and enterprise builds: https://github.com/odoo/odoo/blob/e258de4235b4872e0427017e22b46495080c25dc/addons/web_tour/static/src/tour_utils.js#L81-L101 https://github.com/odoo/odoo/blob/e258de4235b4872e0427017e22b46495080c25dc/addons/web_tour/static/src/tour_utils.js#L36-L43 runbot-240934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262559
This update resolves a bug in the Hong Kong payroll calculations. The system's date calculations were incorrectly referencing the current year, leading to inaccurate payslip periods. This fix ensures payslips accurately reflect the correct fiscal year, particularly for January 2026 payslips, regardless of the test environment.
Original PR description
ir56b._compute_period depends on year_of_employer_return, which is derived from submission_date (defaults to today). If tests are run in a different year (mocked time or different environment), the period won't cover the January 2026 payslip.
This update ensures discounts are correctly applied to vendor bills when a product's price is set to $0.00, even if charges are also included. Previously, products with a zero price prevented discount calculations. This change corrects a discrepancy between the imported invoice total and the Odoo total, ensuring accurate financial reporting.
Original PR description
Allowances for Product with price as 0.00 aren't applied Step to reproduce: - import vendor bill from an XML having a product: - price: 0.00 - charge: any positive amount - allowance: any positive amount Current behavior: - allowance isn't apply resulting in a difference between the XML total and Odoo total Cause of the issue: Before this commit the discount was applied as a percent of price only. Having a price as 0 prevent doing so. opw-5499525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247938
This update resolves a technical issue where attaching images to invoices could cause system crashes. The fix prevents the system from incorrectly syncing orphaned attachment files, ensuring invoices and PDF generation work reliably. This improves overall invoice processing stability.
Original PR description
Steps to reproduce: - Install documents_account and account_accountant. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Install documents_account and account_accountant. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: When attaching an image via a log note, the file becomes the main attachment but is intentionally unlinked (res_model=False) by the system to avoid UI clutter. Downstream modules unknowingly sync this orphaned file. Later, when "Send & Print" generates the real PDF, the system attempts to update the orphaned downstream record, causing model linkage conflicts and eventually a crash. Solution: Add `no_document=True` to the context during `_message_post_after_hook` for invoices. Previously, for incoming emails or log notes, the mail framework would trigger document creation immediately before the core accounting module could evaluate and orphan invalid files (like images). This change suppresses that premature sync, allowing downstream modules to explicitly handle the sync after the attachment's final state is resolved. opw-5930888 Forward-Port-Of: odoo/odoo#262344 Forward-Port-Of: odoo/odoo#258307
This change prevents errors when posting vendor bills in LATAM purchase journals, where document numbers are assigned by the vendor. The 'Secure Posted Entries with Hash' option was causing issues due to Odoo's strict sequential numbering requirement. This update simplifies the process for LATAM users by removing the problematic setting.
Original PR description
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure…
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure Posted Entries with Hash". 4. Create and post a vendor bill with a high document number (e.g. 00001-00009999). 5. Create another vendor bill with a lower document number (e.g. 00001-00000100) and try to post it. Issue Posting the second vendor bill fails with: "This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it." The hashing logic in account_journal.py enforces a strict continuous sequential chain per journal: https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678 In LATAM countries, vendor bill document numbers are assigned by the vendor, not by Odoo. A bill with a lower number can legitimately be entered after one with a higher number, which breaks the sequential assumption the hash chain relies on. Allowing it would produce a hash that no longer represents a proper chain, giving users a false sense of security. Sales journals are unaffected because Odoo controls their sequence. Solution Hide the "Secure Posted Entries with Hash" field on purchase journals that have "Use Documents?" enabled, preventing users from enabling an option that cannot work correctly for vendor-assigned document numbers. Sales journals keep the option available since Odoo controls their sequence. opw-6076673 Forward-Port-Of: odoo/odoo#261664 Forward-Port-Of: odoo/odoo#259206
This update resolves a minor typo within the project management module for our SaaS offering. The change corrects a labeling inconsistency, ensuring accurate data display and functionality. This ensures a consistent and reliable user experience.
Original PR description
There is a typo issue which `pos_enterprise_hr_todo` should be `project_enterprise_hr_todo`.
A bug in our testing process was causing tests to fail when demo data was loaded. This was due to a duplicate 'Shop' IoT Box record – one created in the tests and another present in the demo data. This fix resolves the conflict, ensuring tests run correctly and reliably.
Original PR description
We define an IoT Box record in tests with name "Shop". Another IoT Box with this name is defined in the demo data of the module. As a result, when tests are started with demo data loaded, we tend to click on the first IoT Box record with whis name, which correspond to the one from demo data. Some tests are then failing as they can't find device record defined in the test setup. related: odoo/enterprise#96760
This update resolves an issue where users could unintentionally create links within inline code or code blocks when using the Ctrl+K shortcut in the HTML editor. The change ensures that the editor correctly handles selections within code blocks, preventing the creation of unwanted links and improving the editor's stability and usability. This resolves a reported bug impacting the HTML editor's functionality.
Original PR description
Description of the issue this PR addresses: This commit ensures that links are not created when the selection is inside inline code or a code block, even when using the Ctrl+K shortcut. task-5489870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262397
This update resolves an issue where the payroll system incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a problematic field lookup with a stored employee flag, ensuring accurate document ownership validation during background processes like payroll generation. This prevents errors and ensures proper access control.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti) Forward-Port-Of: odoo/enterprise#115570