Daily updates from Odoo
Monday, July 13, 2026
164 changes
20 changes
Resolved issues and error corrections
Belgian holiday attest payslips now show the employee's private address correctly in the required places after termination. This prevents missing address details on documents for current and prior year holiday attestations.
Original PR description
[FIX] l10n_be: missing employee address on holiday attest Bug reproduction: Belgium -> create employee -> fire the employee -> look to the holiday attest payslips (N and N-1) -> private address of the employee is missing in 2 places in payslip Bug cause: o.employee_id.work_contact_id work contact id was used in report but we can just use private_street, private_city etc. instead. Bug solution: Use private_street, private_city etc. fields directly from the employee model. task - 6361457
This fixes a display issue in the Sign app where template tags could overlap the header when longer translated text made the header taller. The layout now adapts better to different languages and content lengths, improving readability and avoiding a cluttered header.
Original PR description
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and…
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings. - Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position. - Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements. - This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations. 19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486 Before fix: <img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" /> After fix: <img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" /> Forward-Port-Of: odoo/enterprise#120590 Forward-Port-Of: odoo/enterprise#118937
Fixed an issue where FedEx outbound shipping labels lost their reference field when return label creation was enabled. This ensures the original shipment label shows the expected reference information while still supporting return labels.
Original PR description
Issue ----- When setting the delivery method to create return labels aswell, the reference (`REF`) field is not present on the original outbound shipment. <img width="438" height="148" alt="image" src="https://github.com/user-attachments/assets/42acce7b-6177-4f8f-81d3-ad6dfd3e4bb2" /> Steps to reproduce ----- - Setup Fedex - Enable returns - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Open the label > REF field is empty Cause ----- Fedex doesn't include references on the label of returns. When the option for returns is enabled, the outbound shipment is marked as a "Courtesy return". It doesn't make sense to specify a return reason on the original shipment. Expected outcome (after fix) ---- <img width="428" height="146" alt="image" src="https://github.com/user-attachments/assets/0d22e147-da90-4aa4-b3ca-2d996c7cc147" /> ----- Ticket: opw-6101620 Forward-Port-Of: odoo/enterprise#118659
The Delivery Sendcloud test suite was adjusted so mocked tests run during regular continuous integration instead of only in nightly checks. This helps catch delivery integration issues earlier, including corrected expectations around multi-package shipment weight handling.
Original PR description
Test class was tagged as external although calls are mocked. This means errors were only caught in nightly and not by CI. Removing the tag requires fixing some of the tests. For `test_multicollo`, we send the average weight of packages instead of the total since 97f82442c9fee7dcb3e8c5e9bacddcd6bb864e11. Forward-Port-Of: odoo/enterprise#121665 Forward-Port-Of: odoo/enterprise#111660
This update aligns a Hong Kong payroll employee rental field so it behaves consistently across related employee records. It prevents automated payroll tests from failing and helps maintain reliability in payroll configuration handling.
Original PR description
The readonly value inconsistency between l10n_hk_rental_id field in the employee's model and the one in the version's model was provoking some tests to fail. Related runbot error: https://runbot.odoo.com/odoo/error/241956 task-6306032 Forward-Port-Of: odoo/enterprise#120673
This fixes Chilean export invoice PDFs so customs information stays in the correct columns even when origin or destination port details are missing. It prevents package quantities from appearing under the wrong heading, improving document accuracy for customers and compliance workflows.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#122906 Forward-Port-Of: odoo/enterprise#121923
This fixes an issue in the Belgian CODA cleanup module where bank statement import data could be read in the wrong format after a related update. It helps prevent import errors and ensures bank statement information is processed correctly.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
The payroll payrun chatter panel and button now appear only on the intended payrun screens. This prevents confusing extra controls from showing in other payroll views, such as Time Offs, improving clarity for users.
Original PR description
The global `PayRunChatterService` was leaking state across shared views, causing the chatter panel and button to appear on views accessed outside the PayRun layout (e.g., via the main Payroll > Time Offs menu). Fix this by introducing a `useEffect` hook in `PayRunLayout` that checks for a valid `payrun_id` or `payRunReactive` state on view render. If absent, the chatter service state is explicitly reset and closed. The control panel button is also wrapped in a contextual `t-if` check, fully isolating the feature to its intended screens. Task : 6347871
Subscription products that allow one-time purchases now correctly display the original price crossed out next to the Buy Once price. This makes discounts or pricing differences clearer to shoppers and improves price transparency on product pages.
Original PR description
Version - saas-19.1 Steps to reproduce: - Enable 'Accept One Time Sale' on a subscription product - Open the product page on the website Issue: For subscription products with one time sale enabled, the original price was not shown as a strikethrough next to the Buy Once price. Fix: - Captured and exposed the original price to the template before it gets overwritten during subscription price processing - Added the missing strikethrough element to the Buy Once section of the product page Task ID - 6260207 Forward-Port-Of: odoo/enterprise#119488
This fixes how the Belgian payroll 274 declaration shows the total exemption amount. The correction ensures the displayed amount matches the underlying payroll calculation, reducing confusion when reviewing declarations.
Original PR description
The total exemption amount (only used for display) was wrongly computed. Forward-Port-Of: odoo/enterprise#123965 Forward-Port-Of: odoo/enterprise#123714
This fix reverts a previous Belgian payroll change that caused an item to appear twice on the employee form. It keeps employee records cleaner and helps payroll users avoid confusion when reviewing benefit information.
Original PR description
- A previous change has been reverted to avoid appearing twice. Forward-Port-Of: odoo/enterprise#123906
The Odoo Box point of sale module is now included in the translation setup. This allows the module’s text to be translated for users in different languages, improving localization coverage.
Original PR description
In odoo/enterprise#118646 the `obox_point_of_sale` module was added in stable, but the `.weblate.json` file wasn't updated, meaning it cannot be translated. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#124037
Payslip email activity now records a neutral sent-by-email message instead of incorrectly saying a payslip was re-sent the first time it is sent. The note is also added only once per payslip, avoiding duplicate chatter entries when sending payslips for multiple employees.
Original PR description
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when…
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when the payslip is being sent for the first time. The log call also runs inside the loop over the employees and goes through all the payslips of the wizard on each pass, so when the wizard sends payslips of several employees every payslip gets the same note once per employee. This started with the rework of the wizard in https://github.com/odoo/enterprise/commit/39e0488a7e076ee648b47cc3d1cad41cadfd692e **Fix:** The wizard cannot tell a first send from a resend. There is no field on the payslip that keeps track of a previous send, and the chatter cannot be used for that either because the mail sent automatically on validation can be deleted after sending. The fix changes the log in action_send() to say the payslip has been sent by email, which is true in both cases, and moves it out of the employee loop so each payslip gets exactly one note. **Steps to reproduce:** 1. In Payroll > Configuration > Settings, set "Send payslips to employees" to When Paid and save 2. In Payroll > Payslips, create an off-cycle payslip for an employee, click Compute, then Validate 3. Go back to the settings and set "Send payslips to employees" to When Confirmed 4. On the payslip, click Pay, then Mark as Paid 5. Click Print so the payslip document is generated 6. Click Send By Email and send the mail 7. Check the payslip chatter => The chatter shows "The payslip has been re-send to the employee." while the payslip was never sent before Ticket [link](https://www.odoo.com/odoo/project.task/6324204) opw-6324204 Forward-Port-Of: odoo/enterprise#123298
Draft planning entries in My Planning now display with the expected hatched styling instead of looking like confirmed entries. This makes it easier for users to distinguish draft plans at a glance and avoid confusion when reviewing schedules.
Original PR description
Issue: Calendar entries appear plain even when they should appear hatched. (ex. while in draft status) Steps to reproduce: If you create any planning and set it to draft. Then go to Planning > Planning > My Planning, the newly created plan should be in hatched but it becomes plain. Cause: In the view planning.slot.my.calendar there was missing the element that causes the views to become hatched when in draft status. Solution: Added said element. opw-6260055 Forward-Port-Of: odoo/enterprise#119153
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 Description of the issue/feature this PR a
Original PR description
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 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#275791 Forward-Port-Of: odoo/odoo#274019
This update fixes a situation where the 'Invoice' button was incorrectly displayed in the repair module. Now, the button will only appear after a repair has been successfully completed, ensuring users only see relevant options. This change is part of the v19.4 release and will be cleaned up in subsequent versions.
Original PR description
This button should appear only when a repair is done. Note: the existing mechanism wil be cleaned post v19.4 release task: 6379961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor issue where pressing the Tab key within a link preview in Odoo would cause a technical error. The fix ensures smooth navigation within link previews, improving the user experience. This change was part of a larger effort to maintain stability and usability.
Original PR description
Since [1] elements within the link preview can be focused. However, when pressing tab an error is raised. This commit prevents this error from happening. [1]: https://github.com/odoo/odoo/commit/34db19f4a2b42d7e41205d7d793f5b3f408c19af task-6366337 Forward-Port-Of: odoo/odoo#275638 Forward-Port-Of: odoo/odoo#274682
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment handling for invoices sent via UBL and other methods. This improves the reliability of invoice delivery.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the process of verifying EU VAT numbers when creating new companies. Previously, a redundant verification step was performed twice, impacting performance. This change consolidates the verification to a single call, optimizing the system and reducing potential delays.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update corrects a visual inconsistency in the website's accordion controls. A previous change unintentionally created duplicate styling rules, leading to different colors when the accordion was open or closed. This fix ensures a consistent and professional look across all accordion elements.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
20 changes
Resolved issues and error corrections
Fixed an issue where Chilean export invoice PDFs could show customs information under the wrong column when origin or destination port details were missing. The printed export document now keeps blank cells in place so package quantities and port information remain correctly aligned.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#122906 Forward-Port-Of: odoo/enterprise#121923
This fix ensures Belgian CODA bank statement files are read correctly after a prior change added an extra returned value. It prevents import failures or incorrect statement data handling, helping accounting teams continue processing bank statements reliably.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
This fixes an incorrect display of the total exemption amount in Belgian payroll declaration 274. The change helps payroll teams review declarations with accurate displayed totals, without changing the underlying payroll process.
Original PR description
The total exemption amount (only used for display) was wrongly computed. Forward-Port-Of: odoo/enterprise#123714
Fixed FedEx label creation so enabling return labels no longer marks the original outbound shipment as a return. This keeps the expected reference field visible on outbound shipping labels, helping teams identify shipments correctly.
Original PR description
Issue ----- When setting the delivery method to create return labels aswell, the reference (`REF`) field is not present on the original outbound shipment. <img width="438" height="148" alt="image" src="https://github.com/user-attachments/assets/42acce7b-6177-4f8f-81d3-ad6dfd3e4bb2" /> Steps to reproduce ----- - Setup Fedex - Enable returns - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Open the label > REF field is empty Cause ----- Fedex doesn't include references on the label of returns. When the option for returns is enabled, the outbound shipment is marked as a "Courtesy return". It doesn't make sense to specify a return reason on the original shipment. Expected outcome (after fix) ---- <img width="428" height="146" alt="image" src="https://github.com/user-attachments/assets/0d22e147-da90-4aa4-b3ca-2d996c7cc147" /> ----- Ticket: opw-6101620 Forward-Port-Of: odoo/enterprise#118659
The payroll payrun warning for missing payslips now checks the right information after an older filter was removed. This helps payroll teams notice incomplete payruns reliably before processing payroll.
Original PR description
The missing payslip in a payrun warning wasn't triggered correctly because we were filtering on the schedule pay of the payrun and this field was removed in a previous PR. task-6329134
This fixes a commission subscription test so it correctly clears currency rate data across companies when demo data is present. It helps keep automated checks reliable and prevents false failures in subscription commission calculations.
Original PR description
Steps to reproduce: 1- Initialize a new database with demo data 2- Run the test `test_sub_commission_no_currency_rate` Issue: `AssertionError: 0 != 10 : Regular invoice, 10 percent of 100` Why this happens: The test used to delete all rows in the res_currency_rate table for the current company only. When we load the database with demo data, the query in `_get_subscription_currency_rates` would find entries for the other companies and wouldn't resort to the default. Later when joining, it would find no rates for the current company and the test fails. runbot-243440 Forward-Port-Of: odoo/enterprise#116197
The Odoo Box Point of Sale module is now included in the translation setup. This allows the module's text to be translated for users in different languages, improving localization coverage.
Original PR description
In odoo/enterprise#118646 the `obox_point_of_sale` module was added in stable, but the `.weblate.json` file wasn't updated, meaning it cannot be translated. This commit fixes the issue.
Payslip email activity now records a neutral sent-by-email note instead of incorrectly saying the payslip was re-sent. This avoids misleading payroll chatter entries and prevents duplicate notes when emailing payslips for multiple employees.
Original PR description
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when…
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when the payslip is being sent for the first time. The log call also runs inside the loop over the employees and goes through all the payslips of the wizard on each pass, so when the wizard sends payslips of several employees every payslip gets the same note once per employee. This started with the rework of the wizard in https://github.com/odoo/enterprise/commit/39e0488a7e076ee648b47cc3d1cad41cadfd692e **Fix:** The wizard cannot tell a first send from a resend. There is no field on the payslip that keeps track of a previous send, and the chatter cannot be used for that either because the mail sent automatically on validation can be deleted after sending. The fix changes the log in action_send() to say the payslip has been sent by email, which is true in both cases, and moves it out of the employee loop so each payslip gets exactly one note. **Steps to reproduce:** 1. In Payroll > Configuration > Settings, set "Send payslips to employees" to When Paid and save 2. In Payroll > Payslips, create an off-cycle payslip for an employee, click Compute, then Validate 3. Go back to the settings and set "Send payslips to employees" to When Confirmed 4. On the payslip, click Pay, then Mark as Paid 5. Click Print so the payslip document is generated 6. Click Send By Email and send the mail 7. Check the payslip chatter => The chatter shows "The payslip has been re-send to the employee." while the payslip was never sent before Ticket [link](https://www.odoo.com/odoo/project.task/6324204) opw-6324204 Forward-Port-Of: odoo/enterprise#123298
This fix reverts a previous change in the Belgian payroll employee form to prevent the same information from appearing twice. It keeps the employee record screen clearer and avoids confusion for HR users.
Original PR description
- A previous change has been reverted to avoid appearing twice.
The Colombian DIAN invoicing flow now correctly hides the Reset to Draft option for credit notes that have already been accepted by DIAN. This prevents accepted documents from being accidentally reverted, helping maintain compliance and data consistency.
Original PR description
Issue: The reset button would still appear for credit notes that were already accepted by the DIAN. Steps to reproduce: Create a credit note, confirm it and send it to DIAN. You will be able to select Reset to Draft even though it shouldn't be possible to convert to draft after accepted by DIAN. Cause: The function to compute if the reset button would appear or not was only taking into account Invoices. Solution: Added credit notes, to the function that verifies if the reset button should appear. opw-6219265 Forward-Port-Of: odoo/enterprise#119696
This fixes an issue where payroll rule settings reused by the system could be accidentally changed during calculations. The change helps prevent hard-to-trace payroll inconsistencies by ensuring each calculation works with its own safe copy of the setting data.
Original PR description
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc. It could lead to very obscure bugs such as: ```python def…
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.
It could lead to very obscure bugs such as:
```python
def some_innocent_code():
category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
incapacity_codes = category_dict['partial_incapacity']
incapacity_codes |= category_dict['total_incapacity']
# ... then use incapacity_codes
def print_rule_param():
print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])
print_rule_param() # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param() # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```
The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.
task-6329380Fixed a payroll correction action so it consistently applies the chosen popup option to every affected payslip in a batch. This helps payroll teams avoid missed corrections when processing multiple payslips at once.
Original PR description
**What:** - Corrected the method logic 'action_keep_wrong_version' to make sure that it works for both option in the view popup. task-6356957 Forward-Port-Of: odoo/enterprise#122625
The POS now loads only the Kenya e-invoicing classification records that are actually used by products. This avoids unnecessary data loading, helping improve POS startup performance and reduce resource usage.
Original PR description
Before `product.unspsc.code` and `l10n_ke_edi_oscu.code` records were loaded without domain, which could lead to loading all records of these models in POS, which is not necessary. This commit adds a domain to the loading of these records, so that only the records that are actually used in the products are loaded in POS. Forward-Port-Of: odoo/enterprise#123992 Forward-Port-Of: odoo/enterprise#123684
This update resolves a problem preventing users from successfully downloading files through the FileViewer feature in Odoo. The previous issue stemmed from an incorrect port configuration, which has now been corrected. This ensures reliable file downloads for all users.
Original PR description
fix bad forward port 9a7ebe96750 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Load Demo Data' button in the Employee app would overflow text when the app was set to French or Arabic. The fix automatically adjusts the button's width to fit the text, ensuring a cleaner and more user-friendly experience. This improves readability and usability for all users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment identification. This improves the reliability of UBL invoice sending.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the verification of EU VAT numbers during company creation. Previously, a redundant check was performed twice, impacting performance. This change consolidates the verification process to a single call, optimizing efficiency and reducing potential issues with external service limitations.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update fixes several issues within the HTML editor's file box functionality, specifically within the Todo module. It now correctly handles plain text pasting, prevents unexpected cursor movement, and eliminates a scrollbar that appeared when the file box was empty. These changes ensure a smoother and more reliable editing experience.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This update corrects a bug where clickable carousel slides linked to 'odoo.com' would incorrectly redirect users to a website URL followed by 'odoo.com'. The fix ensures that carousel links function as intended, directing users to the correct Odoo domain. This resolves a potential usability issue for website visitors.
Original PR description
Steps to reproduce: - Drop any carousel - Set any slide to clickable - Set the link to "odoo.com" (without https://) - Save => On click, you are redirected to "yourwebsite.url/odoo.com" task-5949973
This update corrects a visual inconsistency in the website's accordion controls. A previous change caused the accordion to display two different colors depending on whether it was open or closed. This fix ensures a consistent color scheme across all accordion states, improving the overall user experience.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
16 changes
Resolved issues and error corrections
Audit reports now update the number of invalid records when an audit check is reviewed and no longer finds issues. This prevents users from seeing outdated anomaly counts after a check has passed, making audit results clearer and more reliable.
Original PR description
Problem: Sometimes after an audit check passes (gets reviewed successfully), the count of invalid records in the audit report is not updated. Steps to reproduce: 1. Add a check for an audit cycle 2. Make sure the check's domain is satisified by at least one record 3. Check the audit report and see the check you added 4. The check status should show an anomaly and the count of invalid records will be greater than 0 5. Now, edit the check so that the domain is not satisfied by any record 6. Check the audit report again and see the check you edited 7. The check status should show "Reviewed" but the count of invalid records will still be greater than 0, which is not correct Cause: When updating the status of an audit check, the count of invalid records is not updated, only the status gets updated. opw-6264177 Forward-Port-Of: odoo/enterprise#123751 Forward-Port-Of: odoo/enterprise#119227
A new automated test verifies that overtime is calculated correctly when a flexible employee takes leave. This helps prevent payroll or time-tracking mistakes from reappearing in future updates.
Original PR description
For PR: https://github.com/odoo/odoo/pull/274831 This commit adds a test case to ensure that overtime is correctly calculated for the flexible employee opw-6259328,6284145
Chilean export invoice PDFs now keep customs details in the correct columns even when origin or destination ports are left blank. This prevents package quantities and other export information from appearing under the wrong headings, improving document accuracy for customers and compliance workflows.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
FedEx outbound shipment labels now keep their reference field when return labels are enabled. This prevents normal shipments from being incorrectly treated as returns, making labels clearer for shipping and order tracking.
Original PR description
Issue ----- When setting the delivery method to create return labels aswell, the reference (`REF`) field is not present on the original outbound shipment. <img width="438" height="148" alt="image" src="https://github.com/user-attachments/assets/42acce7b-6177-4f8f-81d3-ad6dfd3e4bb2" /> Steps to reproduce ----- - Setup Fedex - Enable returns - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Open the label > REF field is empty Cause ----- Fedex doesn't include references on the label of returns. When the option for returns is enabled, the outbound shipment is marked as a "Courtesy return". It doesn't make sense to specify a return reason on the original shipment. Expected outcome (after fix) ---- <img width="428" height="146" alt="image" src="https://github.com/user-attachments/assets/0d22e147-da90-4aa4-b3ca-2d996c7cc147" /> ----- Ticket: opw-6101620 Forward-Port-Of: odoo/enterprise#118659
This fix prevents the timesheet assistant from crashing when away-time activity is processed without a matching group already present. Users can continue reviewing and categorizing timesheet suggestions reliably, even when some activity data is incomplete or unmatched.
Original PR description
Before this commit, when the unmatched group is not found in events before processing afk event, a traceback occurs saying `Cannot read properties of undefined (reading 'Away (afk status 1)')` This commit moves the code checking the group key exists in `this.state.grouped` after processing afk event and before adding the afk event in unmatched group.
The POS now loads only the Kenya e-invoicing classification records that are actually used by available products. This avoids pulling unnecessary data into the POS, helping reduce load times and resource usage without changing user workflows.
Original PR description
Before `product.unspsc.code` and `l10n_ke_edi_oscu.code` records were loaded without domain, which could lead to loading all records of these models in POS, which is not necessary. This commit adds a domain to the loading of these records, so that only the records that are actually used in the products are loaded in POS. Forward-Port-Of: odoo/enterprise#123684
A Belgian CODA bank statement import fix now correctly uses the statement data returned by the parser. This prevents import failures or malformed statement data after a prior change added extra return information.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
This fixes a test setup issue in subscription commissions by ensuring currency rate records from all companies are removed before validating fallback behavior. It prevents demo data from other companies from causing incorrect commission calculations during automated checks.
Original PR description
Steps to reproduce: 1- Initialize a new database with demo data 2- Run the test `test_sub_commission_no_currency_rate` Issue: `AssertionError: 0 != 10 : Regular invoice, 10 percent of 100` Why this happens: The test used to delete all rows in the res_currency_rate table for the current company only. When we load the database with demo data, the query in `_get_subscription_currency_rates` would find entries for the other companies and wouldn't resort to the default. Later when joining, it would find no rates for the current company and the test fails. runbot-243440 Forward-Port-Of: odoo/enterprise#116197
The Colombian electronic invoicing flow now hides the Reset to Draft option for credit notes that have already been accepted by DIAN. This prevents users from accidentally reverting documents that should remain finalized for compliance reasons.
Original PR description
Issue: The reset button would still appear for credit notes that were already accepted by the DIAN. Steps to reproduce: Create a credit note, confirm it and send it to DIAN. You will be able to select Reset to Draft even though it shouldn't be possible to convert to draft after accepted by DIAN. Cause: The function to compute if the reset button would appear or not was only taking into account Invoices. Solution: Added credit notes, to the function that verifies if the reset button should appear. opw-6219265 Forward-Port-Of: odoo/enterprise#119696
This update fixes several issues within the HTML editor's file box functionality, specifically within the Todo module. It now correctly handles plain text pasting, prevents unexpected cursor movement, and eliminates a scrollbar that appeared when the file box was empty. These changes ensure a smoother and more reliable editing experience.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This update fixes an issue where duplicated printers lost their configured IP addresses, causing printing problems. The fix ensures that when a printer is duplicated, it retains the original IP address, simplifying setup and improving the Point of Sale functionality. This prevents disruptions to sales operations.
Original PR description
Steps to reproduce: ==== - Configure a printer from printers menu. - Duplicate the printer. Issue: ==== - The duplicated printer's IP address is reset to `0.0.0.0`. Cause: ==== - copy_data()` unconditionally overrides `printer_ip` with `0.0.0.0`. Fix: ==== - Stop overriding `printer_ip` so the duplicated printer inherits the original IP address by default. task-6365809
This update fixes an issue where the 'Load Demo Data' button in the Employee app would overflow text when the app was set to French or Arabic. The fix automatically adjusts the button's width to fit the text, ensuring a cleaner and more user-friendly experience. This improves readability and usability for all users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment identification. This improves the reliability of UBL invoice sending.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the verification of EU VAT numbers during company creation. Previously, a redundant check was performed twice, impacting performance. This change consolidates the verification process to a single call, optimizing efficiency and reducing potential service limitations.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update fixes an issue where a new database index wasn't being utilized by Odoo's internal queries. The change ensures the index works correctly with both custom queries and those generated by the Odoo ORM, leading to faster data retrieval. This improves overall system performance.
Original PR description
The index added by 778c09f4ffb4 works for the specific query it was meant to improve. Unfortunately, it cannot be used by ORM-generated queries, which is unfortunate. The reason is that the ORM generates queries with `IS TRUE` or `IS NOT TRUE` for boolean fields. Because `=` and `IS` do not have the same semantics, postgresql cannot use the index for ORM-generated queries. = -> eval(NULL = True) -> NULL IS -> eval(NULL IS TRUE) -> FALSE By changing both the index and the query to use `IS TRUE`, the index is now used by both the specific query and the ORM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual inconsistency in the website's accordion controls. Previously, the accordion's color was applied inconsistently between its expanded and collapsed states. This fix ensures a consistent and professional appearance for all users.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
15 changes
Resolved issues and error corrections
Fixed an issue where Chilean export invoice PDFs could show customs details in the wrong columns when origin or destination port information was missing. The invoice now keeps the table layout consistent, helping avoid confusion in printed export documentation.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
FedEx outbound shipping labels now keep their reference information when return labels are enabled. This prevents original shipments from being incorrectly treated as return shipments, making labels clearer and easier to reconcile.
Original PR description
Issue ----- When setting the delivery method to create return labels aswell, the reference (`REF`) field is not present on the original outbound shipment. <img width="438" height="148" alt="image" src="https://github.com/user-attachments/assets/42acce7b-6177-4f8f-81d3-ad6dfd3e4bb2" /> Steps to reproduce ----- - Setup Fedex - Enable returns - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Open the label > REF field is empty Cause ----- Fedex doesn't include references on the label of returns. When the option for returns is enabled, the outbound shipment is marked as a "Courtesy return". It doesn't make sense to specify a return reason on the original shipment. Expected outcome (after fix) ---- <img width="428" height="146" alt="image" src="https://github.com/user-attachments/assets/0d22e147-da90-4aa4-b3ca-2d996c7cc147" /> ----- Ticket: opw-6101620 Forward-Port-Of: odoo/enterprise#118659
This update corrects a subscription commission test so it reliably clears currency-rate data across companies when demo data is present. It helps prevent false test failures and improves confidence that subscription commission calculations remain correct.
Original PR description
Steps to reproduce: 1- Initialize a new database with demo data 2- Run the test `test_sub_commission_no_currency_rate` Issue: `AssertionError: 0 != 10 : Regular invoice, 10 percent of 100` Why this happens: The test used to delete all rows in the res_currency_rate table for the current company only. When we load the database with demo data, the query in `_get_subscription_currency_rates` would find entries for the other companies and wouldn't resort to the default. Later when joining, it would find no rates for the current company and the test fails. runbot-243440 Forward-Port-Of: odoo/enterprise#116197
Colombian electronic credit notes accepted by DIAN will no longer show the option to reset them to draft. This prevents users from accidentally changing documents that are already officially accepted, helping maintain compliance and data integrity.
Original PR description
Issue: The reset button would still appear for credit notes that were already accepted by the DIAN. Steps to reproduce: Create a credit note, confirm it and send it to DIAN. You will be able to select Reset to Draft even though it shouldn't be possible to convert to draft after accepted by DIAN. Cause: The function to compute if the reset button would appear or not was only taking into account Invoices. Solution: Added credit notes, to the function that verifies if the reset button should appear. opw-6219265 Forward-Port-Of: odoo/enterprise#119696
This update improves the reliability of India payroll testing by using separate test data for percentage calculations. It prevents existing sample employee values from influencing the test results, without changing payroll behavior for users.
Original PR description
Use a dedicated employee/version for the percentage computation test instead of Rahul, whose existing payroll values affect copied version data. Define the test amounts in common and reuse `employee.version_id` in the test, so percentages are derived from amounts without changing payroll behavior. task-6340923 Forward-Port-Of: odoo/enterprise#121918
This update corrects how Belgian CODA bank statement import data is read after a previous compatibility change. It prevents import failures or incorrectly structured statement data, helping accounting teams process bank files reliably.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
This fixes a small reliability issue in field service reporting tests and updates a related field service sales view reference. It helps installations and upgrades complete more reliably by matching subtasks correctly and using the current subtask button target.
Original PR description
_* = industry_fsm_sale Steps to Reproduce --- 1. Install industry_fsm_report. 2. Run test_subtasks_worksheet_template_id_duplicate. 3. Install or upgrade industry_fsm_sale. Issue --- The test relies on the order of child_ids, which is no longer stable, causing copied subtasks to be matched against the wrong original records. The inherited xpath also targets the old action-based subtask button, causing it to fail. Fix --- Sort the original and duplicated subtasks and update the inherited xpath to target action_open_subtasks. task-5966684 Forward-Port-Of: odoo/enterprise#123035
Obox modules are now included in the translation setup so their text can be translated for supported languages. This helps users work with Obox in their preferred language and avoids untranslated labels or messages.
Original PR description
When the Obox modules were added in odoo/enterprise#110834 they were not also added to `.weblate.json`, meaning they will not be translated. This commit fixes the issue.
Delivery labels sent through Sendcloud now correctly keep dots in street numbers, such as 12.345. This prevents incomplete house numbers from being sent to Sendcloud and helps ensure shipping labels match the customer’s full delivery address.
Original PR description
Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123266
This update resolves several issues within the HTML editor's file box functionality. Specifically, it prevents the powerbox from opening within file boxes, ensures plain text is pasted correctly, and corrects a visual bug related to scrollbars. These changes enhance usability and stability when working with files in the editor.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This update fixes an issue where the 'Load Demo Data' button in the Employee app would overflow text when the app was set to French or Arabic. The fix automatically adjusts the button's width to fit the text, ensuring a clean and consistent user experience. This improves readability and usability for all users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment identification. This improves the reliability of UBL invoice sending.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update fixes an issue where the HTML editor was incorrectly triggering font size checks even when users applied other formatting styles. Now, list item font size checks are limited to font size formatters only, ensuring a smoother and more reliable editing experience. This improves the overall stability and usability of the HTML editor.
Original PR description
#### Description of the issue this PR addresses: - Fully selected list items could go through font size checks even when applying unrelated formatters. #### Desired behavior after PR is merged: - Restrict list item font size checks to font size formatters only. task-6329161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275096 Forward-Port-Of: odoo/odoo#272104
This update corrects a visual inconsistency in the website's accordion controls. A previous change caused the accordion to have different colors when expanded versus collapsed. This fix ensures a uniform and professional appearance for all users, regardless of the accordion's state.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
This update fixes an issue where template tasks were incorrectly counted in task lists and views. The change ensures that task counts and views accurately reflect only real subtasks, improving the clarity and accuracy of project task management, particularly for tasks created using templates.
Original PR description
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab,…
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab, check the subtask view as well. - Create a template parent task with one normal sub-task and one template sub-task, then repeat the same checks. Issue --- - Task templates are handled like regular subtasks in the subtask count, notebook, and subtask view, without taking the parent task type into account. Current Behaviour --- - For a normal parent task, both the normal sub-task and the template sub-task are counted and shown in the opened subtask view and notebook. - For a template parent task, the same filtering is applied, even though template subtasks should remain accessible in that context. Expected Behaviour --- - For a normal parent task, only real sub-tasks should be counted and shown in the subtask view and notebook, and on the project kanban card. - For a template parent task, template subtasks should remain available in the subtask view and notebook according to the parent template context. - In the project kanban card, tasks must not be counted when their parent task is a template, even if the child task itself is not a template. Fix --- - Apply template-aware filtering to subtask counting,project kanban task count and subtask view behavior, depending on whether the parent task is a normal task or a template task. task-5966684 Forward-Port-Of: odoo/odoo#274590 Forward-Port-Of: odoo/odoo#252403
4 changes
Resolved issues and error corrections
Delivery labels sent through Sendcloud now keep full house numbers that include a dot, such as 12.345. This prevents incorrect address data on shipping labels and helps avoid delivery issues for affected customers.
Original PR description
Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123266
Signing certificates for recruitment offers now show the applicant's actual email address instead of a generic placeholder. This helps HR teams keep accurate signed offer records and avoids confusion when reviewing certificates.
Original PR description
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170** Forward-Port-Of: odoo/enterprise#123901 Forward-Port-Of: odoo/enterprise#123767
This fix removes a reference to an employee access group that does not exist in the Belgian payroll fleet module. It helps prevent configuration errors and keeps payroll-related fleet fields aligned with valid access settings.
Original PR description
The group hr_group_user does not exist and shouldn't be linked to these fields. task-6369268
Chilean export invoice PDFs now keep customs information in the correct columns even when origin or destination ports are not provided. This prevents package quantities and other export details from appearing under the wrong headings, improving document accuracy for customers and customs use.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
5 changes
Resolved issues and error corrections
Delivery labels sent through Sendcloud now keep full house numbers that include a dot, such as 12.345. This prevents incorrect label data and helps ensure shipments use the customer's complete address.
Original PR description
Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123266
This fixes a printing issue on Chilean export invoices where missing origin or destination port information could shift customs details into the wrong columns. The invoice PDF now keeps the table aligned even when optional port fields are left blank, reducing confusion in export documentation.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment handling within the account EDI process. This improves the reliability of sending invoices.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update clarifies the terminology used in Odoo's overtime reporting by renaming confusing labels like 'Difference' and 'Balance' to 'Worked Extra Hours' and 'Validated Extra Hours'. This change ensures consistent and understandable reporting across all views, improving data accuracy and user experience.
Original PR description
The reporting labels "Difference" and "Balance" are confusing because "Difference" tracks system-qualified overtime while "Balance" represents accepted overtime hours. There is also a lack of consistency across views. This commit renames these fields to "Worked Extra Hours" and "Validated Extra Hours" to harmonize the naming everywhere task-6352142 Description of the issue/feature this PR addresses: Confusing and inconsistent naming for extra hours Current behavior before PR: - Reporting uses "Difference" and "Balance". - Views use inconsistent labels. Desired behavior after PR is merged: Labels are consistently named "Worked Extra Hours" and "Validated Extra Hours" everywhere. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274097 Forward-Port-Of: odoo/odoo#273631
This update corrects a visual inconsistency in the website's accordion controls. A recent change improved the design by using icons instead of background images, but a specific rule was overriding the intended color styling. This fix ensures the accordion has a consistent color appearance regardless of whether it's expanded or collapsed, improving the overall user experience.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274016
1 change
Resolved issues and error corrections
This update corrects how Belgian CODA bank statement data is read after a recent compatibility change. It prevents import errors or incorrectly structured statement data, helping accounting teams continue processing bank files reliably.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
11 changes
Resolved issues and error corrections
Chilean export invoice PDFs now keep customs information in the correct columns even when origin or destination port details are missing. This prevents package quantities and other export details from appearing under the wrong headings, improving document accuracy for customers and compliance workflows.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
This change stops Sendcloud delivery shipments from including tax numbers in customs information by reverting a previous update. It helps ensure customs data sent to the carrier matches the intended requirements and avoids sharing unnecessary tax details.
Original PR description
Revert of c696339. ----- Ticket: opw-6384570
This fix corrects how Belgian CODA bank statement data is read after a related compatibility change. It prevents import errors and ensures the correct statement details are used when processing bank files.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id
This fixes an issue where companies using Peru localization could not create a certificate when Chile localization was also installed. The Chile-specific serial number requirement now applies only where appropriate, preventing unnecessary setup errors for other Latin American companies.
Original PR description
With a l10n_pe company and having a l10n_cl company installed: - Try to create a certificate in the settings, there is a missing field error. The template certificate_certificate_view_form have a required subject_serial_number field in l10n_cl but it shouldn't in other latam localization. opw-6274126
Demo social feed comments now use the correct standard demo user data after older demo partner data was removed. This ensures comments in demo mode show the right author image, making demo feeds look consistent and accurate.
Original PR description
Bug === Since ce264a2 , we remove the demo partner in the social_demo module, but we didn't update the code to use the demo data in base. Task-6293738
This update adds the Belgian CODA extension module to the translation configuration. It helps ensure the module can be included in the normal translation workflow, with no direct change to day-to-day user behavior.
Original PR description
This commit will add l10n_be_coda_extension_number in the weblate json file. no task id
Printing an appraisal form from the action menu now waits briefly so the menu can close before the browser print dialog opens. This prevents the menu from appearing on printed appraisal documents, improving the professionalism and clarity of the output.
Original PR description
When printing the appraisal form from the action (cog) menu, the drop down menu itself was incorrectly showing up in the printed document. This happened because the browser started printing immediately before the menu had time to close. By adding a small delay before triggering the print action, the menu now has time to completely close, so it no longer appears in the final print. task-6369240
This update makes the database authentication module available for translation work, helping improve language coverage for users. It also corrects minor wording mistakes and adjusts an internal error check that users would not encounter directly.
Original PR description
The aim of this commit is to allow the translator to work on this module translation and fix a typo that was made. Task-id: None
This fix prevents an error when users clear the start or end date on a Mexican payroll payslip. The system now checks that dates are present before running salary-limit warning calculations, so payroll users can edit payslip periods without disruption.
Original PR description
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI`…
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI` company - Go to `Payslips`, create a payslip. - Set an `employee`, and remove either the `start date` or the `end date` from Period.. `TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'` After the [recent commit] adding a warning about the employee exceeding the salary limit, when the user removes the dates from the payslip, the compute method attempts to compute the warning from [1], and when it adds relativedelta to date_from, which is False, it raises the error [2]. This commit ensures that the payslip dates are checked first before adding relativedelta to the date and performing the comparison. [recent commit]: https://github.com/odoo/enterprise/commit/6abfa47dafe439f9328d606ef6ac5126ec6eb1f6 [1]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/hr_payroll/models/hr_payslip.py#L1446 [2]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L272-L276
Signed recruitment offer certificates now show the applicant's actual email address instead of a placeholder. This prevents confusion when reviewing signature certificates and keeps recruitment records accurate.
Original PR description
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170** Forward-Port-Of: odoo/enterprise#123901 Forward-Port-Of: odoo/enterprise#123767
Sendcloud shipping labels now correctly keep dots in address numbers, such as “12.345”, instead of shortening them. This prevents incorrect house number data being sent to Sendcloud and helps ensure delivery labels match the customer address.
Original PR description
Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123266
4 changes
Resolved issues and error corrections
This update fixes an issue where pressing 'Enter' within a code block nested in a list would incorrectly create a new list item. Now, 'Enter' will simply add a new line within the existing code block, providing a smoother and more intuitive editing experience for code snippets.
Original PR description
Current behavior before PR: - When the cursor was placed within the text of a code block that was a child of a list, pressing enter create a new list item containing a code block. Desired behavior after PR is merged: - Now, if the cursor is positioned within the text of a code block that was child of a list, pressing enter will insert a new line within the code block instead of creating a new list item. task:4240721
This update addresses a technical issue where a report was failing when analytic plans were not available. The fix ensures the system gracefully handles missing plans, preventing errors and maintaining data accuracy. This resolves a previously reported problem (OPW-6383774, OPW-6383787) and improves report stability.
Original PR description
After this commit 403d9d7, current_plans is being used to get the column name but not always have a analytic plan. To fix this issue we review if is empty or not. OPW-6383774 OPW-6383787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the DSO (Days Sales Outstanding) data on the Invoice Dashboard was misaligned. The problem stemmed from a discrepancy in how fiscal years were handled, leading to inaccurate reporting. This change ensures the DSO data accurately reflects invoice performance.
Original PR description
Invoice dashboard data, specifically DSO, was incorrectly aligned due to a mismatch in the fiscal year structure. Task-6049887
This update corrects a crash that occurred when the system attempted to merge partners using UUID-formatted access tokens. The fix ensures the system correctly handles both the older numeric partner ID format and the newer UUID format, preventing errors and improving stability.
Original PR description
The SQL query in _update_foreign_keys was casting access_token to integer unconditionally, but website_visitor.access_token is a Char field that uses two formats: - Legacy: partner_id stored as a numeric string (e.g. '105249') - Current: 32-char UUID hex string (e.g. 'b0dd4bfd041f4b42957357ba7e067dda') The ::int cast raises InvalidTextRepresentation on UUID-format tokens. Fix: guard the cast with a regex so only rows with numeric access_tokens are processed; UUID-format rows are left untouched. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
This fix registers the WhatsApp Identifiers translation template so it is included in the translation workflow. It helps ensure translated text for this module can be properly managed and kept up to date.
Original PR description
pot files must be registered there. See 9966b160972a053e051f2213846acc64d133f2a3
The Dutch reports module information no longer shows an outdated website link that now points to unrelated content. This avoids sending users to the wrong external site and keeps module details accurate.
Original PR description
The URL leads to a website that has nothing to do with what it used to be so it needs to be removed. Task-6360682
This fix ensures payroll rule parameter data stays consistent when reused by the system. It prevents one payroll calculation or process from unintentionally changing cached values used elsewhere, reducing the risk of hard-to-trace payroll issues.
Original PR description
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc. It could lead to very obscure bugs such as: ```python def…
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.
It could lead to very obscure bugs such as:
```python
def some_innocent_code():
category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
incapacity_codes = category_dict['partial_incapacity']
incapacity_codes |= category_dict['total_incapacity']
# ... then use incapacity_codes
def print_rule_param():
print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])
print_rule_param() # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param() # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```
The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.
task-6329380This update ensures that the default placeholder in the Klipy search feature displays "Search KLIPY", as required by Klipy's attribution guidelines. This change maintains proper compliance and enhances the user experience when using Klipy within Odoo. It's a minor fix to improve consistency.
Original PR description
Klipy requires attribution with "Search KLIPY" as the default placeholder [1]. This commit complies these guidelines. [1]: https://docs.klipy.com/attribution