Monday, February 5, 2024
41 changes · saas-17.1
Miscellaneous changes
In the context of the bookkeeping act in denmark, we need to record all the modification and delete of all the input, so we should by default install the audit_trail module. Since they need this in 17.0 we will make a bridge module. Also correcting a clash of labels and exporting the pot of the l10n_in module task: 3627720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145149
Original PR description
In the context of the bookkeeping act in denmark, we need to record all the modification and delete of all the input, so we should by default install the audit_trail module. Since they need this in 17.0 we will make a bridge module. Also correcting a clash of labels and exporting the pot of the l10n_in module task: 3627720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145149
Current behavior before PR: While applying font color, when multiple picture snippet is selected the color was not properly applied to the selection. It was observed that the font gets unintentionally applied around the figure which was preventing the proper application of selected color. Desired behavior after PR is merged: It has been made sure that whenever the figure element is encountered it should not be appended inside font tag. task-3640901 Forward-Port-Of: odoo/odoo#152248
Original PR description
Current behavior before PR: While applying font color, when multiple picture snippet is selected the color was not properly applied to the selection. It was observed that the font gets unintentionally applied around the figure which was preventing the proper application of selected color. Desired behavior after PR is merged: It has been made sure that whenever the figure element is encountered it should not be appended inside font tag. task-3640901 Forward-Port-Of: odoo/odoo#152248 Forward-Port-Of: odoo/odoo#147733
**Current behavior before PR:** - Emoji picker opened at an incorrect position. **Desired behavior after PR is merged:** - The Emoji picker now opens precisely at the cursor location task-3569967 Forward-Port-Of: odoo/odoo#140038
Original PR description
**Current behavior before PR:** - Emoji picker opened at an incorrect position. **Desired behavior after PR is merged:** - The Emoji picker now opens precisely at the cursor location task-3569967 Forward-Port-Of: odoo/odoo#140038
Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Cover" snippet into an empty page. - Sets the "Height" option of this snippet to "100%". - Drag and drop a "Media List" snippet into the page. - Drag and drop a "Popup" snippet into the page. - Save the page. - Scroll quickly the page to the bottom before the popup appears. - When the popup is open, resize the window to trigger a "resize" event. - Close the popup. - Scroll the page to the top. - Bug: the height o
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Cover" snippet into an empty page. - Sets the "Height" option of this snippet to "100%". - Drag and drop a "Media List" snippet…
Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Cover" snippet into an empty page. - Sets the "Height" option of this snippet to "100%". - Drag and drop a "Media List" snippet into the page. - Drag and drop a "Popup" snippet into the page. - Save the page. - Scroll quickly the page to the bottom before the popup appears. - When the popup is open, resize the window to trigger a "resize" event. - Close the popup. - Scroll the page to the top. - Bug: the height of the "Cover" snippet is a way too high. This bug occurred because the height of the snippet with the "Height: 100%" option enabled is calculated based on the scrollable element it is in (since this commit [1]). However, when a popup is opened, the detected scrollable element was incorrect due to the "overflow: hidden" rule added to "#wrapwrap" by the "modal-open" class on the `<body>`. [1]: https://github.com/odoo/odoo/commit/b371cb42cb67115692464c102813b7ebd54785d9 opw-3643498 Forward-Port-Of: odoo/odoo#152402 Forward-Port-Of: odoo/odoo#150838
Prevent an infinite loop when the cycle in the parents does not contain the starting id: `3->2->1->2->1...` Example: ``` >>> m=self.env['ir.module.category'] >>> c1,c2,c3 = map(m.browse,[1,2,3]) >>> c2.parent_id = False >>> c3.parent_id = False >>> c1.parent_id = c2 >>> (c3|c2).parent_id = c1 # this never ends ``` With current patch the call to `_check_recursion` successfully detects the new cycle. Description of the issue/feature this PR addresses: Current behavior before P
Original PR description
Prevent an infinite loop when the cycle in the parents does not contain the starting id: `3->2->1->2->1...` Example: ``` >>> m=self.env['ir.module.category'] >>> c1,c2,c3 = map(m.browse,[1,2,3]) >>> c2.parent_id = False >>> c3.parent_id = False >>> c1.parent_id = c2 >>> (c3|c2).parent_id = c1 # this never ends ``` With current patch the call to `_check_recursion` successfully detects the new cycle. 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#152080 Forward-Port-Of: odoo/odoo#151294
**Current behavior before PR:** - Inserting a banner after already existing content it's impossible to go to the next line of the banner. - Inserting a banner did not set focus inside the banner; instead, focus was placed after the banner. - Performing Ctrl+A and backspace inside a banner would unintentionally remove Its first element, which could be a block tag - When a banner was inserted at the first line and Ctrl+A and backspace is performed, nothing happens. **Desired b
Original PR description
**Current behavior before PR:** - Inserting a banner after already existing content it's impossible to go to the next line of the banner. - Inserting a banner did not set focus inside the banner; instead, focus was placed after the banner. - Performing Ctrl+A and backspace inside a banner would unintentionally remove Its first element, which could be a block tag - When a banner was inserted at the first line and Ctrl+A and backspace is performed, nothing happens. **Desired behavior after PR is merged:** - It's now possible to navigate to the next line of the banner. - Now, upon creating a banner, focus is now correctly set inside the banner. - Now performing Ctrl+A and backspace inside the banner will no longer remove its first element if it's a block tag. - Now, all the content except banner will be selected and removed. task-3432167 Forward-Port-Of: odoo/odoo#151735 Forward-Port-Of: odoo/odoo#129874
Before this commit, discrepancies between leaves and allocations for an specific employee and a specific time off type would have prevented the employee from taking any time off for that time off type. It would also affect their dashboard. __How to reproduce the issue:__ - time off type without negative amount - create 2 allocations: last year and this year - create a leave last year - remove last year allocation from DB - you cannot take leaves this year - dashboard amount is affe
Original PR description
Before this commit, discrepancies between leaves and allocations for an specific employee and a specific time off type would have prevented the employee from taking any time off for that time off…
Before this commit, discrepancies between leaves and allocations for an specific employee and a specific time off type would have prevented the employee from taking any time off for that time off type. It would also affect their dashboard. __How to reproduce the issue:__ - time off type without negative amount - create 2 allocations: last year and this year - create a leave last year - remove last year allocation from DB - you cannot take leaves this year - dashboard amount is affected by last year's leave __Changes brought with this commit:__ This commit keeps the logic identical for negative time off types. However, for the others, the check ensuring the allocation validity for the leave will now check the discrepancies before and after a time off creation or modification. The error will be thrown if the discrepancies have changed, meaning that the leave had an effect on it. This way, any other issue will not prevent leave creation. Those leaves are still noticeable through the warning though, meaning that they can be noticed and dealt with accordingly. Perf fix: ======= Before  After  Forward-Port-Of: odoo/odoo#152311
Before, the tax tag invert is computed based on the entry type if the entry type is different from "entry" or based on the tax set and the balance of aml for entries with type "entry". This is fine in most cases but we can reach a wrong tag invert if we use cash basis and down-payment. Here are the steps to reproduce: - Create a company with cash basis tax (ex: "TVA 20% (Services)" for l10n_fr) - Make sure no "base tax received account" is set in the cash basis settings - Create a produ
Original PR description
Before, the tax tag invert is computed based on the entry type if the entry type is different from "entry" or based on the tax set and the balance of aml for entries with type "entry". This is fine…
Before, the tax tag invert is computed based on the entry type if the entry type is different from "entry" or based on the tax set and the balance of aml for entries with type "entry". This is fine in most cases but we can reach a wrong tag invert if we use cash basis and down-payment. Here are the steps to reproduce: - Create a company with cash basis tax (ex: "TVA 20% (Services)" for l10n_fr) - Make sure no "base tax received account" is set in the cash basis settings - Create a product with a cash basis default tax and an income account which is not the default one - Create an sale order with this product for 100€ + 20% tax - Create a down payment for 30€ + 20% tax (add the tax to downpayment) - Create the final invoice with deduction of down payment - Register a payment on both to create the caba entries => Tax report will show 160€ of base instead of 100€ To have the issue, it's important that the income account of the product line differs from the account used on the down payment line in the final invoice because the issue involved having a negative base line in the resulting caba move. If the same account is used for invoice down/product line the caba base lines will be grouped in one non negative line. For the same reason, the "base tax received account" must remain empty. The deduction aml on the cash basis entry of final invoice have an tag invert at False instead of True. So it's computed as -30€ instead of +30€. If we reproduce the case with a non cash basis tax, it will work because the move type will be different from "entry" and tag invert will be computed only based on the type. To solve this issue, we now compute the tag invert based on caba origin move if any to improve the tag invert computation for cash basis entries. opw-3597141 Forward-Port-Of: odoo/odoo#148448
**steps to reproduce:** - create an ir.rule on res.users and write a domain with a typo **before this commit:** - users can't log into odoo **after this commit:** - an error is raised to prevent saving a bad domain opw-3653746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151992 Forward-Port-Of: odoo/odoo#147763
Original PR description
**steps to reproduce:** - create an ir.rule on res.users and write a domain with a typo **before this commit:** - users can't log into odoo **after this commit:** - an error is raised to prevent saving a bad domain opw-3653746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151992 Forward-Port-Of: odoo/odoo#147763
In this commit we add the ability to toggle between showing and not showing product and category images in the pos ui. Because this change is done in stable, we store the user's selection in `ir.config.parameter`. In the forward port, this will be removed and the settings will be stored in `pos.config` Task 3704416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151823
Original PR description
In this commit we add the ability to toggle between showing and not showing product and category images in the pos ui. Because this change is done in stable, we store the user's selection in `ir.config.parameter`. In the forward port, this will be removed and the settings will be stored in `pos.config` Task 3704416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151823
[FIX] sale: ensure widget is alive before executing code Steps to reproduce the bug: - Add a delay (for example 10 seconds) at the beginning of the `/sale/get_combination_info_website` route. - Go on a product page and enter edit mode. Note that the `websiteSaleCarouselProduct` is destroyed. - Click on the the product image. Note that the "Replace" button appears. - Wait for the added delay to finish. -> If you click on the product image, the "Replace" button does not appear. In
Original PR description
[FIX] sale: ensure widget is alive before executing code Steps to reproduce the bug: - Add a delay (for example 10 seconds) at the beginning of the `/sale/get_combination_info_website` route. - Go on…
[FIX] sale: ensure widget is alive before executing code Steps to reproduce the bug: - Add a delay (for example 10 seconds) at the beginning of the `/sale/get_combination_info_website` route. - Go on a product page and enter edit mode. Note that the `websiteSaleCarouselProduct` is destroyed. - Click on the the product image. Note that the "Replace" button appears. - Wait for the added delay to finish. -> If you click on the product image, the "Replace" button does not appear. In this situation, the added delay represents a slow rpc answer. Let's analyse the flow of instructions in order to better understand the problem: - When you go on a product page, the `WebsiteSale` public widget is started. `_getCombinationInfo` of `VariantMixin` is then called through the `start()` of the public widget. As the rpc is taking time to answer, `_onChangeCombination()` is not directly called. - When entering edit mode, the `WebsiteSale` public widget is destroyed. Due to the edit mode, the `o_editable` class has been added on editable elements. - After the added delay and thanks to the rpc answer, `_updateProductImage()` is called through `_onChangeCombination()`. The `_updateProductImage()` replaces some elements of the DOM and by doing so, removes the `o_editable` class of some elements. Consequently, the snippet option linked to the image is not displayed. The problem here is that the `_updateProductImage` method is called even if its associated public widget has been destroyed. To solve the problem, we first check that the associated widget is alive before handling the result of the rpc answer in the `VariantMixin` mixin. Note that the first idea was to use `this._rpc()` instead of `ajax.jsonRpc()` in the mixin. Indeed, the advantage of using `this._rpc()` is that it already ensures that the associated widget is alive before handling the result of the rpc answer. The problem is that some widgets that use the `VariantMixin` are created in such a way that `this._rpc()` can not be used on them (for example `OptionalProductsModal`). Related to runbot-28700 Forward-Port-Of: odoo/odoo#148716
Since 857c4851754dcddf9e6dc7b39585914beaf89c88, rates are not truncated anymore. The stored rate value on SO, between SO currency and company currency was not adapted and was still truncated, leading to invalid values after rates conversion. See also 5a621cea4c5a16998a3b83890144f81a3880244b where the same solution was appied to pos orders. opw-3638199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152460 Forward
Original PR description
Since 857c4851754dcddf9e6dc7b39585914beaf89c88, rates are not truncated anymore. The stored rate value on SO, between SO currency and company currency was not adapted and was still truncated, leading to invalid values after rates conversion. See also 5a621cea4c5a16998a3b83890144f81a3880244b where the same solution was appied to pos orders. opw-3638199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152460 Forward-Port-Of: odoo/odoo#152296
The address displayed as 'Invoicing address' was the main SO address and not the invoicing one. Also, the pencil icon link to update the customer main address was always displayed next to the invoicing address, even if: * the so does not belong to the customer * the invoicing address is different than the customer main address This commit fixes those two issues. opw-3653190 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
The address displayed as 'Invoicing address' was the main SO address and not the invoicing one. Also, the pencil icon link to update the customer main address was always displayed next to the invoicing address, even if: * the so does not belong to the customer * the invoicing address is different than the customer main address This commit fixes those two issues. opw-3653190 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152298
### Steps - Go to website and edit - Add an event block - Change the template of the block from picture to card layout. - Replace the image of one card by a 4k image. ### Issue The custom cover is blurry. ### Reason By default the custom cover is resized to 256x256 (but not the default one because it uses a static image path). opw-3390459 Forward-Port-Of: odoo/odoo#145898
Original PR description
### Steps - Go to website and edit - Add an event block - Change the template of the block from picture to card layout. - Replace the image of one card by a 4k image. ### Issue The custom cover is blurry. ### Reason By default the custom cover is resized to 256x256 (but not the default one because it uses a static image path). opw-3390459 Forward-Port-Of: odoo/odoo#145898
The new ActionableErrors widget new widget is meant to be a warnings header for wizards and forms, where flows like EDI can list a series of errors and actions for the users to fix the roadblocks. The HTML result is a `<div>` list with a point for each warning and a link to a given action. Clicking the link will fire the execution of a Python method on the backend, also passing back to it a series of parameters the component has stored on setup time. During setup, ActionableErrors accepts
Original PR description
The new ActionableErrors widget new widget is meant to be a warnings header for wizards and forms, where flows like EDI can list a series of errors and actions for the users to fix the roadblocks.…
The new ActionableErrors widget new widget is meant to be a warnings header for wizards and forms, where flows like EDI can list a series of errors and actions for the users to fix the roadblocks.
The HTML result is a `<div>` list with a point for each warning and a link to a given action. Clicking the link will fire the execution of a Python method on the backend, also passing back to it a series of parameters the component has stored on setup time.
During setup, ActionableErrors accepts this structure as incoming data:
```py
{
'error_key' : {
'message': _("Description of the warning"),
'action_text': _("Text of the link"),
'action': {
'type': 'ir.actions.act_window',
'res_model': 'model.to.be.opened',
'views': [(False, 'list'), (False, 'form')],
'target': 'current',
'res_id': res_ids[0],
},
}, ...
}
```
A map is used instead of an array, so that the Owl framework could be more precise in rendering changes in future development, thanks the `t-foreach`'s `t-key` check. (i.e. remove a warning after clicking the action link without re-rendering the whole widget)
In `l10n_it_edi`'s Send&Print flow, we removed the old code from the view, we changed the compute from HTML to Json, and adapted the compute function's output to fit the ActionableErrors widget format.
All the pre-sending checks that were done on the before sending are now split by model, so that there's more separation.
The actions will get created by `base/ir_ui_view.py/Model`.[get_records_action](https://github.com/odoo/odoo/pull/142596/commits/48bb284b33f9939eb68bfb9a8484dc588e2fa0df#diff-dfebe5a93e1b8880e88268b024be4c6f106d144b20298d7bb6c4ae09a18bafd0R2703), which will enable us to **remove a lot of action-building methods** scattered through Odoo.
<details><summary><b>Images preview ←←←←← </b></summary>
<p>
Before:
After:
</p>
</details>
Forward-Port-Of: odoo/odoo#142596Steps to reproduce ================== - Use a laptop with touch or apply the following patch ```diff diff --git a/addons/web/static/src/core/browser/feature_detection.js b/addons/web/static/src/core/browser/feature_detection.js index 21c6294b1b0e..64c4bc9b899c 100644 --- a/addons/web/static/src/core/browser/feature_detection.js +++ b/addons/web/static/src/core/browser/feature_detection.js @@ -62,6 +62,7 @@ export function isDisplayStandalone() { } export function hasTouch() {
Original PR description
Steps to reproduce
==================
- Use a laptop with touch or apply the following patch
```diff
diff --git a/addons/web/static/src/core/browser/feature_detection.js b/addons/web/static/src/core/browser/feature_detection.js
index 21c6294b1b0e..64c4bc9b899c 100644
--- a/addons/web/static/src/core/browser/feature_detection.js
+++ b/addons/web/static/src/core/browser/feature_detection.js
@@ -62,6 +62,7 @@ export function isDisplayStandalone() {
}
export function hasTouch() {
+ return true;
return browser.ontouchstart !== undefined || browser.matchMedia("(pointer:coarse)").matches;
}
```
- Enable debug mode
- Go to contacts
- Hover the mouse over a question mark next to a field
=> Nothing happens
Cause of the issue
==================
The function `shouldCleanup` returns true when the device has touch and the popover has been triggerd with the mouse
opw-3694156
Forward-Port-Of: odoo/odoo#151156The opportunity is taken to fix an issue where removing a record from assign would not update the inverse. Forward-Port-Of: odoo/odoo#152442
Original PR description
The opportunity is taken to fix an issue where removing a record from assign would not update the inverse. Forward-Port-Of: odoo/odoo#152442
Before this commit, it was possible for users to drop website snippets (e.g., the "Badge" block) inside the inline form of payment acquirers. At least for Adyen, it would prevent payments because the payment inputs within the inline form wouldn't load anymore. As inline forms are part of the payment form widget, which itself is not customizable by users, this commit blocks the website editor inside the entire payment form and its children elements. opw-3607719 Forward-Port-Of: odoo/odoo#1
Original PR description
Before this commit, it was possible for users to drop website snippets (e.g., the "Badge" block) inside the inline form of payment acquirers. At least for Adyen, it would prevent payments because the payment inputs within the inline form wouldn't load anymore. As inline forms are part of the payment form widget, which itself is not customizable by users, this commit blocks the website editor inside the entire payment form and its children elements. opw-3607719 Forward-Port-Of: odoo/odoo#152469 Forward-Port-Of: odoo/odoo#152306
This PR provides a localization for the eCommerce workflow in Ecuador. Changes * A new localization module l10n_ec_website_sale adapting the eCommerce workflow for Ecuadorr * Make zip code not required * Provide access to latam identifaction types to "public users" (non-portal / non-internal shop users) so that it can be used in the checkout process of the eCommerce (billing information) ### l10n_ec_website_sale details main adaptions: * Identification type and number in the
Original PR description
This PR provides a localization for the eCommerce workflow in Ecuador. Changes * A new localization module l10n_ec_website_sale adapting the eCommerce workflow for Ecuadorr * Make zip code not…
This PR provides a localization for the eCommerce workflow in Ecuador.
Changes
* A new localization module l10n_ec_website_sale adapting the eCommerce workflow for Ecuadorr
* Make zip code not required
* Provide access to latam identifaction types to "public users" (non-portal / non-internal shop users) so that it can be used in the checkout process of the eCommerce (billing information)
### l10n_ec_website_sale details
main adaptions:
* Identification type and number in the checkout process (in the billing address)
* SRI Payment Method in the eCommerce Payment Method
SRI Payment Method
* The SRI Payment Method value is required for the EDI
* In the payment method form view the SRI Payment Method field is hidden
if the list of fiscal countries of the selected companies does not include Ecuador.
* Payment methods which do not have an associated SRI Payment Method cannot be used in the eCommerce of an Ecuadorian company.
* When creating an invoice from a sales order we try to compute the SRI Payment Method as follows:
We consider all the SRI Payment Methods of the payment methods of the payment transactions associated with the sales order.
If there is exactly 1 such SRI Payment Method we use this on the invoice.
This should ensures that we can always set the SRI Payment Method on invoices created through the eCommerce flow.
### task info
task-3585823
Forward-Port-Of: odoo/odoo#142730[Commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) introduced necessary change to resolve a layout issues on the caret icon in the Search Bar menus. But at the same time, it introduced a layout issue on dropdowns in the Pivot view: carets were no longer placed on the right. But since [commit [2]](https://github.com/odoo/odoo/commit/976491e01272336bc34abcdcec2718f83e19c5fc), the Search Bar menus have become accordions instead of dropdown menus. The chang
Original PR description
[Commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) introduced necessary change to resolve a layout issues on the caret icon in the Search Bar menus. But at the…
[Commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) introduced necessary change to resolve a layout issues on the caret icon in the Search Bar menus. But at the same time, it introduced a layout issue on dropdowns in the Pivot view: carets were no longer placed on the right. But since [commit [2]](https://github.com/odoo/odoo/commit/976491e01272336bc34abcdcec2718f83e19c5fc), the Search Bar menus have become accordions instead of dropdown menus. The change made in [commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) is therefore no longer necessary. We can now remove it to fix dropdown menus in the Pivot view. task-3718186 | Before | After | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152417
Issue: When adding a new field to the website form of the "Extra Info" page in the eCommerce, a traceback is raised `OwlError: Missing template: "website.form_field_json"`) when the customer selects the type "Delivery Point Address"(`sale.order.access_point_address`). Explanation: JSON fields are not supported as selectable types in website forms, and they should not be because customers would not be able to properly fill them out. Fix: Filter out all JSON fields from the list of
Original PR description
Issue: When adding a new field to the website form of the "Extra Info" page in the eCommerce, a traceback is raised `OwlError: Missing template: "website.form_field_json"`) when the customer selects the type "Delivery Point Address"(`sale.order.access_point_address`). Explanation: JSON fields are not supported as selectable types in website forms, and they should not be because customers would not be able to properly fill them out. Fix: Filter out all JSON fields from the list of authorized fields in website forms; they will not appear anymore in the list of selectable types. opw-3596713 Forward-Port-Of: odoo/odoo#152382 Forward-Port-Of: odoo/odoo#152290
Appending strings within a `t-out` for a website template makes it so that it can never be translated. Instead the string should be written like normal text so that it is correctly seen as to be translated and `t-out` only the next step so that it's also correctly matched as to be translated. opw-3700815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152312
Original PR description
Appending strings within a `t-out` for a website template makes it so that it can never be translated. Instead the string should be written like normal text so that it is correctly seen as to be translated and `t-out` only the next step so that it's also correctly matched as to be translated. opw-3700815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152312
we execute a subprocess without checking if an error occurs so we place the subprocess.call() in a try except 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#152212
Original PR description
we execute a subprocess without checking if an error occurs so we place the subprocess.call() in a try except 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#152212
In https://github.com/odoo/odoo/commit/e0297bdac4eac165a79680de3b1139c2f554d5f5, the creation of a new record always patches the inverse fields of relational fields in order to make the cache of those inverse fields consistent. For instance, when creating a new record like ```py user = model.new({'group_ids': [Command.link(group.id)]}) ``` The inverse of field `group_ids` on the new record having `group` as origin is patched so that its value includes `record`. A side effect of this mech
Original PR description
In https://github.com/odoo/odoo/commit/e0297bdac4eac165a79680de3b1139c2f554d5f5, the creation of a new record always patches the inverse fields of relational fields in order to make the cache of…
In https://github.com/odoo/odoo/commit/e0297bdac4eac165a79680de3b1139c2f554d5f5, the creation of a new record always patches the inverse fields of relational fields in order to make the cache of those inverse fields consistent.
For instance, when creating a new record like
```py
user = model.new({'group_ids': [Command.link(group.id)]})
```
The inverse of field `group_ids` on the new record having `group` as origin is patched so that its value includes `record`. A side effect of this mechanism is that it fetches `group.user_ids` in order to patch the value of `new_group.user_ids`, where `new_group` is the new record having `group` as origin.
The side effect described above is problematic when that inverse field has huge cardinality, like hundreds of thousands of records, and this performance overhead is unacceptable when the inverse field is actually not used at all.
We address this performance issue by patching the value of x2many fields only when they are used. If the value of the field is not in cache yet, the patch is applied once a value is put in cache. If the field is not used, the patch is simply never applied.
Forward-Port-Of: odoo/odoo#149624Create an automation rule for a field for which there's no onchange yet. The rule type is "on_change" (on UI change). This type of automation rule adds an onchange method on the selected fields, which thus involve the onchange mecanism: the "on_change" attribute will be set on that field nodes in views, s.t. when the user changes it, onchange rpcs are done. However, views are cached, and creating such a rule didn't clear the cache. So if the view was already in cache, the rule seemed not t
Original PR description
Create an automation rule for a field for which there's no onchange yet. The rule type is "on_change" (on UI change). This type of automation rule adds an onchange method on the selected fields,…
Create an automation rule for a field for which there's no onchange yet. The rule type is "on_change" (on UI change). This type of automation rule adds an onchange method on the selected fields, which thus involve the onchange mecanism: the "on_change" attribute will be set on that field nodes in views, s.t. when the user changes it, onchange rpcs are done. However, views are cached, and creating such a rule didn't clear the cache. So if the view was already in cache, the rule seemed not to work, because the client still received the old version of the view, without the "on_change" attribute. This commit clears the cache when such a rule is created, s.t. after a client reload, the feature gets enabled as expected. opw 3701125 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#152498
Confirming a repair order with parts assign moves quantities. Ending it without any of the picked flags automatically pick them. But ending it with some non-picked parts does not cancel the moves. Now they are. task: 3679247 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149157
Original PR description
Confirming a repair order with parts assign moves quantities. Ending it without any of the picked flags automatically pick them. But ending it with some non-picked parts does not cancel the moves. Now they are. task: 3679247 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149157
Before this commit, there was a race condition with the statusbar field, and more specifically with the useRecordObserver. The issue could be reproduced in the form view of project.task. In an existing task, belonging to a project with some stages, change the project to another project with its own stages. It might happen that the displayed stages weren't the one of the newly set project. If this didn't happen directly, this happened upon saving (i.e. the correct stages are displayed just aft
Original PR description
Before this commit, there was a race condition with the statusbar field, and more specifically with the useRecordObserver. The issue could be reproduced in the form view of project.task. In an…
Before this commit, there was a race condition with the statusbar field, and more specifically with the useRecordObserver. The issue could be reproduced in the form view of project.task. In an existing task, belonging to a project with some stages, change the project to another project with its own stages. It might happen that the displayed stages weren't the one of the newly set project. If this didn't happen directly, this happened upon saving (i.e. the correct stages are displayed just after switching the project, but as soon as the user saves the record, the former stages are back). This happens because of useRecordObserver used an outdated version of the props to get the domain (i.e. the props of the component have been updated, but useRecordObserver still used the old version, in particular the old props.domain). This commit fixes the issue by ensuring that we always use the last version of the props. opw 3693113 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#152433
On behalf of: https://github.com/innovyou [info@innovyou.co](mailto:info@innovyou.co) Description of the issue/feature this PR addresses: Added corporate signature for Innovyou (innoviù Srl). Old PR: odoo/odoo#152404 Forward-Port-Of: odoo/odoo#152414
Original PR description
On behalf of: https://github.com/innovyou [info@innovyou.co](mailto:info@innovyou.co) Description of the issue/feature this PR addresses: Added corporate signature for Innovyou (innoviù Srl). Old PR: odoo/odoo#152404 Forward-Port-Of: odoo/odoo#152414
Before this patch, if you once had one module available and, later, remove it, you'd be getting an exception when browsing its form view and trying to get its icon image: <details> ``` RPC_ERROR Odoo Server Error Traceback (most recent call last): File "/opt/odoo/custom/src/odoo/odoo/api.py", line 886, in get return field_cache[record._ids[0]] KeyError: 1508 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/op
Original PR description
Before this patch, if you once had one module available and, later, remove it, you'd be getting an exception when browsing its form view and trying to get its icon image: <details> ``` RPC_ERROR Odoo…
Before this patch, if you once had one module available and, later, remove it, you'd be getting an exception when browsing its form view and trying to get its icon image:
<details>
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 886, in get
return field_cache[record._ids[0]]
KeyError: 1508
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'ir.module.module(1508,).icon_image'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
result = request.dispatch()
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 687, in dispatch
result = self._call_function(**self.params)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 359, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/service/model.py", line 94, in wrapper
return f(dbname, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 348, in checked_call
result = self.endpoint(*a, **kw)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 916, in __call__
return self.method(*args, **kw)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 535, in response_wrap
response = f(*args, **kw)
File "/opt/odoo/auto/addons/web/controllers/main.py", line 1342, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/web/controllers/main.py", line 1334, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 464, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 451, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3227, in read
return self._read_format(fnames=fields, load=load)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3247, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5893, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1106, in __get__
self.compute_value(recs)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 2139, in compute_value
super().compute_value(records_no_bin_size)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1265, in compute_value
records._compute_field_value(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 4255, in _compute_field_value
getattr(self, field.compute)()
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_module.py", line 254, in _get_icon_image
with tools.file_open(path, 'rb') as image_file:
File "/opt/odoo/custom/src/odoo/odoo/tools/misc.py", line 198, in file_open
path = file_path(name, filter_ext=filter_ext)
File "/opt/odoo/custom/src/odoo/odoo/tools/misc.py", line 179, in file_path
raise FileNotFoundError("File not found: " + file_path)
Exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 643, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 301, in _handle_exception
raise exception.with_traceback(None) from new_cause
FileNotFoundError: File not found: /base/static/description/icon.png
```
</details>
Now it gets the base module icon image, just like it should.
@moduon MT-1524 OPW-3082012
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#151870
Forward-Port-Of: odoo/odoo#105532Before this commit ================== It was not allowed to cancel the invoice, an error message was displayed, response as False was returned as it was always moving inside else condition After this commit ================= After changes the error message has been removed and response as True is returned, and allowed to cancel the invoice task-3258582 Forward-Port-Of: odoo/odoo#151517 Forward-Port-Of: odoo/odoo#117592
Original PR description
Before this commit ================== It was not allowed to cancel the invoice, an error message was displayed, response as False was returned as it was always moving inside else condition After this commit ================= After changes the error message has been removed and response as True is returned, and allowed to cancel the invoice task-3258582 Forward-Port-Of: odoo/odoo#151517 Forward-Port-Of: odoo/odoo#117592
If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while connecting the database "500 internal server error" is raised as below. To resolve this issue, This PR will help to fetch only those records which have url in website_menu. ``` 500: Internal Server Error [Traceback](https://43.test.upgrade.odoo.com/en#error_traceback) Traceback (most recen
Original PR description
If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while…
If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while connecting the database
"500 internal server error" is raised as below.
To resolve this issue, This PR will help to fetch only those records which have
url in website_menu.
```
500: Internal Server Error
[Traceback](https://43.test.upgrade.odoo.com/en#error_traceback)
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1866, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/17.0/addons/website/controllers/main.py", line 97, in index
top_menu = request.website.menu_id
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2886, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/website/models/website.py", line 181, in _compute_menu
menus.mapped('is_visible')
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6066, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1280, in mapped
self.__get__(first(remaining), type(remaining))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in _compute_visible
helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in <lambda>
helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
TypeError: 'bool' object is not subscriptable
```
Forward-Port-Of: odoo/enterprise#55037**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month and annual periods as configured. This only happens in 17.0 and higher. The problem was happening because this patch wasn't calling. https://github.com/odoo/enterprise/blob/4c577804b4f6fadb1d606896a3c124909b85ab6b/website_sale_subscription/static/src/js/variant_mixin.js#L14-L28 That's because o
Original PR description
**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month…
**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month and annual periods as configured. This only happens in 17.0 and higher. The problem was happening because this patch wasn't calling. https://github.com/odoo/enterprise/blob/4c577804b4f6fadb1d606896a3c124909b85ab6b/website_sale_subscription/static/src/js/variant_mixin.js#L14-L28 That's because of the file with the patch needs to be loaded before this one https://github.com/odoo/odoo/blob/bfe857db1dd5408af57f46aa51eae8be82a4c6f9/addons/website_sale/static/src/js/website_sale.js#L15 **Steps to Reproduce**: 1. Create a new subscription product in the `Subscriptions` app. 2. In the `Attributes & Variants` tab, add a new attribute `periods` with values such as `Monthly`, `6 Months`, `Yearly`. 3. In the `Recurring Prices` tab, add each variant of the product (`Monthly`, `6 Months`, `Yearly`) along with their corresponding `Recurring Plan` and `Recurring Price`, then save. 4. Click the `Go to Website` smart button and try to change the product variants. 5. Observe that the product is always labeled as "per month" regardless of the selected variant. **Proposed Solution**: To resolve this, ensure that the mixin is patched before its usage. This can be achieved by forcing the load order of the scripts. This adjustment ensures the correct script loading sequence, allowing the patch to apply before the mixin is used. opw-3654134 Forward-Port-Of: odoo/enterprise#55194
Forward-Port-Of: odoo/enterprise#55735
Original PR description
Forward-Port-Of: odoo/enterprise#55735
Steps to reproduce: - Go to planning app at top button are not consistent - Some have rounded edges while others have sharp edge Issue: - planning app > the planning app's top button are not consistent. Some have rounded edges while others have sharp edge. Solution: - adding the bootstrap class 'rounded' to round edges of buttons task-3549328 Forward-Port-Of: odoo/enterprise#55507 Forward-Port-Of: odoo/enterprise#49587
Original PR description
Steps to reproduce: - Go to planning app at top button are not consistent - Some have rounded edges while others have sharp edge Issue: - planning app > the planning app's top button are not consistent. Some have rounded edges while others have sharp edge. Solution: - adding the bootstrap class 'rounded' to round edges of buttons task-3549328 Forward-Port-Of: odoo/enterprise#55507 Forward-Port-Of: odoo/enterprise#49587
**Steps to reproduce:** - Schedule activity on a .pdf document and also on a .png document. - Apply Image/Video filter. (Only the .png file will be visible now) - Select and replace the .png document with another image. **Issue:** - Both .pdf and .png documents are now visible in the view instead of just the image/video type documents. This issue is faced as an empty domain is received by the 'load' method of the activity model. **Fix:** - This PR fixes the issue by passing
Original PR description
**Steps to reproduce:** - Schedule activity on a .pdf document and also on a .png document. - Apply Image/Video filter. (Only the .png file will be visible now) - Select and replace the .png document with another image. **Issue:** - Both .pdf and .png documents are now visible in the view instead of just the image/video type documents. This issue is faced as an empty domain is received by the 'load' method of the activity model. **Fix:** - This PR fixes the issue by passing props in the 'load' method call to ensure that the default data remains as it is, and the existing domain is still applied. Task: [3718403](https://www.odoo.com/web#id=3718403&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#55716
Before this commit: During the execution of this tour, at a specific step, we are required to click a document to open its preview. But the prompt to close the preview is missing as the preview opens. After this commit: The user is prompted to close the preview. task-3537521 Forward-Port-Of: odoo/enterprise#54920 Forward-Port-Of: odoo/enterprise#48917
Original PR description
Before this commit: During the execution of this tour, at a specific step, we are required to click a document to open its preview. But the prompt to close the preview is missing as the preview opens. After this commit: The user is prompted to close the preview. task-3537521 Forward-Port-Of: odoo/enterprise#54920 Forward-Port-Of: odoo/enterprise#48917
…rvice tasks Steps to Reproduce: - install website, field service module - in website, click on tasks - open field service tasks Issue: - it does not showing the customer's address anymore only (name, phone and email) is visible. Cause: - there is no such condition ,that the address should be visible. solution: - By default the phone and email will be visible for all the tasks, because those two fields mentioned in portal. To make the address visible only for field service task
Original PR description
…rvice tasks Steps to Reproduce: - install website, field service module - in website, click on tasks - open field service tasks Issue: - it does not showing the customer's address anymore only (name, phone and email) is visible. Cause: - there is no such condition ,that the address should be visible. solution: - By default the phone and email will be visible for all the tasks, because those two fields mentioned in portal. To make the address visible only for field service tasks we need to give xpath. By giving xpath the issue will be solved task-3683976 Forward-Port-Of: odoo/enterprise#54284
When totals below section option is set, there is a redundancy in the display of data. Indeed, the amount will be displayed once on the line itself and once again in the total line. For now on, if the total below section is set and the total line is displayed (unfolded), the amount will only on the total line. task-3642826 Forward-Port-Of: odoo/enterprise#55416 Forward-Port-Of: odoo/enterprise#52966
Original PR description
When totals below section option is set, there is a redundancy in the display of data. Indeed, the amount will be displayed once on the line itself and once again in the total line. For now on, if the total below section is set and the total line is displayed (unfolded), the amount will only on the total line. task-3642826 Forward-Port-Of: odoo/enterprise#55416 Forward-Port-Of: odoo/enterprise#52966
To reproduce ============ - Go to Appraisal select an employee and send by email - the url in the email is wrong Problem ======= - the body of the request is rendered twice with qweb, but the template wasn't designed for that, as we have `t-att-href="ctx.get('url')"` that will be `href="ctx['url']"` after first render and expecting to be rendered again and replace `ctx['url']` with the real url but qweb has no way to know that without a `t-att-` prefix. Solution ======== - before se
Original PR description
To reproduce
============
- Go to Appraisal select an employee and send by email
- the url in the email is wrong
Problem
=======
- the body of the request is rendered twice with qweb, but the template wasn't designed for that, as we have `t-att-href="ctx.get('url')"` that will be `href="ctx['url']"` after first render and expecting to be rendered again and replace `ctx['url']` with the real url but qweb has no way to know that without a `t-att-` prefix.
Solution
========
- before second render, add `t-att-` prefix to `href` so qweb will know that it should be rendered again and replace `ctx['url']` with the real url.
opw-3687928
Forward-Port-Of: odoo/enterprise#55780
Forward-Port-Of: odoo/enterprise#55464With the refactor of the Peruvian electronic invoicing [1], we missed a valid use case where the currency of the SPOT amount must always be PEN and not the same as the currency of the related invoice. [1] 12b9effea5a763483d86477e27c7bc8261bcb4f0 Forward-Port-Of: odoo/enterprise#55323
Original PR description
With the refactor of the Peruvian electronic invoicing [1], we missed a valid use case where the currency of the SPOT amount must always be PEN and not the same as the currency of the related invoice. [1] 12b9effea5a763483d86477e27c7bc8261bcb4f0 Forward-Port-Of: odoo/enterprise#55323
**Steps:** - Open Timesheet > All Timesheets -Add values for multiple projects for any employee on a particular date. - Now group by Employee. - Try to change the value for that employee on that particular date. **Issue:** - Traceback occurs and user is unable to change the values for existing timesheets. **Cause:** - 'line.project_id' is expected to be a single record (singleton), but it appears to be a set or a list of records. The allow_timesheets attribute is then attempted to b
Original PR description
**Steps:** - Open Timesheet > All Timesheets -Add values for multiple projects for any employee on a particular date. - Now group by Employee. - Try to change the value for that employee on that particular date. **Issue:** - Traceback occurs and user is unable to change the values for existing timesheets. **Cause:** - 'line.project_id' is expected to be a single record (singleton), but it appears to be a set or a list of records. The allow_timesheets attribute is then attempted to be accessed directly on the set or list, which results in a ValueError. **Fix:** - By incorporating the 'all' function and the explicit iteration over line.project_id, you avoid attempting to access the allow_timesheets attribute directly on the collection, which is what causes the 'singleton error'. This fix correctly handles cases where line.project_id may contain multiple records. **Task**-3613014 Forward-Port-Of: odoo/enterprise#55596 Forward-Port-Of: odoo/enterprise#51741