Tuesday, May 5, 2026
54 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 optimizes appointment scheduling by only calculating availability for the current month instead of pre-computing all slots. This change significantly reduces the system's workload and improves response times when users are booking appointments, leading to a smoother user experience. It addresses a performance bottleneck related to appointment slot generation.
Original PR description
Generate all slots and compute only availabilities for the display month instead of pre-computing all slots for the whole booking period. task-4144524 Forward-Port-Of: odoo/enterprise#115986
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
This update resolves an issue that occurred when changing chart templates, specifically when switching between company and association localization settings. The fix ensures that related cash rounding records are properly removed during the template update process, preventing database errors. This improves stability and avoids disruptions during localization changes.
Original PR description
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account"…
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account" violates RESTRICT setting of foreign key constraint "account_cash_rounding_profit_account_id_fkey" on table "account_cash_rounding" DETAIL: Key (id)=(1919) is referenced from table "account_cash_rounding" ``` **Steps to reproduce:** 1) install l10n_be module 2) make a new belgium company 3) go to accounting > configurations 4) change the fiscal localization package to "Belgium- Associations and Foundations" **Cause:** `account.cash.rounding` was not included in the chart template cleanup models. As a result, old `account.account` records were unlinked while still referenced by cash rounding records with `ondelete='restrict'` **Solution:** Include `account.cash.rounding` in `TEMPLATE_MODELS` so cleanup removes cash rounding records before deleting old accounts. And Add an assertion in `test_change_coa` to ensure old cash rounding records are deleted during COA switch. opw-6165374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 payroll XML files for Mexican businesses were being rejected by the SAT (tax authority) due to incorrect data formatting. The fix ensures that TotalPercepciones is omitted when only OtrosPagos (other payments) are present, aligning with Mexican tax regulations and preventing rejection errors.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
This update resolves an issue where the 'delete' action was unexpectedly removed after installing the 'data_cleaning' module for attachments. The change 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.