Daily updates from Odoo
Monday, July 8, 2024
21 changes · saas-17.2
Resolved issues and error corrections
This update brings the spreadsheet component to a newer version with several fixes for common spreadsheet actions. It improves reliability when deleting rows, pasting content, using number formats, charting cumulative data, and working with broad cell references, reducing user-facing errors in spreadsheet workflows.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/acfb3e71e [REL] 17.2.15 Task: 0 https://github.com/odoo/o-spreadsheet/commit/6ea19c264 [FIX] border: bottom sheet…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/acfb3e71e [REL] 17.2.15 Task: 0 https://github.com/odoo/o-spreadsheet/commit/6ea19c264 [FIX] border: bottom sheet borders removed on DELETE_ROWS Task: 3911695 https://github.com/odoo/o-spreadsheet/commit/6497e8c6a [FIX] locale: handle undefined thousands separator Task: 0 https://github.com/odoo/o-spreadsheet/commit/c2d6eab35 [FIX] chart: cumulative not working for linear charts Task: 4028957 https://github.com/odoo/o-spreadsheet/commit/f00e760ee [FIX] grid: prevent paste default Task: 3949903 https://github.com/odoo/o-spreadsheet/commit/a59ed517f [FIX] parser: `parse` should handle unbounded references Task: 4010920 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix stops the web interface from registering the same template extension more than once. It reduces the risk of unexpected crashes when duplicate frontend assets are loaded, improving stability for users.
Original PR description
Before that commit, it was possible to register several times the same template extension. This can lead to crash in some occasions. For example consider the template
```xml
<t t-name="A">
<div attr="a" />
</t>
```
and its extension
```xml
<t t-name="B" t-inherit="A" t-inherit-mode="extension">
<xpath expr=".//div[@attr='a']" position="attributes">
<attribute name="attr">b</attribute>
</xpath>
</t>
```
In that case, when building the template A with B registered twice, the first application of B to A will succeed while the second application will cause a crash (no target found for the xpath).
Here we prevent multiple registering of the same template extensions. Note that this is similar to what happens when the same js module is received several times: odoo.define has no effect after the first registering.The message composer now displays recipient names and joining words with proper spacing in the chatter. This makes the recipient list easier to read and avoids a small visual glitch when sending messages.
Original PR description
Before this commit the recipients list displayed when sending a message on the chatter missed spacing between the recipients and conjunctions. This happens because the container has display flex which removes whitespace from child elements. This commit fixes the issue by wrapping the list in a div tag so to preserve the whitespace. task-4032550 Before:  After: 
Miscellaneous changes
### To merge in 17.0 to master -.1 Bugs: ----- 1. both: -go to time off and click on "New Allocation Request" -change the allocation type to any other 2.a -> the number of days or hours is set to 0 where it should be 1 day or 8 hours/ressource callendar of the employee 2.b -> if you have selected an allocation where the unit is "half_day" or the number of days and the title doesn't corresponds to each other First introduction: ------------------- task: 3084
Original PR description
### To merge in 17.0 to master -.1 Bugs: ----- 1. both: -go to time off and click on "New Allocation Request" -change the allocation type to any other 2.a -> the number of days or hours is set to 0…
### To merge in 17.0 to master -.1
Bugs:
-----
1.
both: -go to time off and click on "New Allocation Request"
-change the allocation type to any other
2.a
-> the number of days or hours is set to 0 where it should be 1 day
or 8 hours/ressource callendar of the employee
2.b
-> if you have selected an allocation where the unit is "half_day" or
the number of days and the title doesn't corresponds to each other
First introduction:
-------------------
task: 3084232
PR: https://github.com/odoo/odoo/pull/116472
Reasons:
--------
a. We where using the fields where were made for the front-end only
and where not computed properly and thus resetting the value to 0
when changing the allocation type
b. The title was using the unit of the allocation type in db and not
Labels or the unit of the allocation duration
Fixes:
------
Not use the display fields for the computation of the title and make labels corresponding to the actual unit of the allocation duration
task-3852940
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#161035An indeterministic error was present in the pos_loyalty module. This was due to the fact that when the user changed the partner a request to retrieve the loyaltyCards already existing for this partner was made by a different series of function calls. In fine, the call was not awaited, so when another method wanted to retrieve the loyaltyCards for the same partner, a new card was created and then overridden to null by the result of the call to the server. To correct this error, the cal
Original PR description
An indeterministic error was present in the pos_loyalty module. This was due to the fact that when the user changed the partner a request to retrieve the loyaltyCards already existing for this partner was made by a different series of function calls. In fine, the call was not awaited, so when another method wanted to retrieve the loyaltyCards for the same partner, a new card was created and then overridden to null by the result of the call to the server. To correct this error, the call to the server to retrieve the cards is made when the partner is changed. At this point the request is awaited. Runbot Error: [57047](https://runbot.odoo.com/web/#id=57047&view_type=form&model=runbot.build.error&menu_id=405&cids=1) Forward-Port-Of: odoo/odoo#171226
Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used. Steps to reproduce: ------------------- * Install and configure an IoT box * Go to **Point of Sale** * Select the Shop, edit it * Check `IoT Box` * Configure `Customer Display` * Now go to the settings of the Shop * Enable `Customer Display` if not already done previously * Upload a background image, save * Open the Shop
Original PR description
Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used. Steps to reproduce:…
Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used. Steps to reproduce: ------------------- * Install and configure an IoT box * Go to **Point of Sale** * Select the Shop, edit it * Check `IoT Box` * Configure `Customer Display` * Now go to the settings of the Shop * Enable `Customer Display` if not already done previously * Upload a background image, save * Open the Shop session * Select the customer display > Observation: The background image is not shown. Why the fix: ------------ When using the customer display feature with the IoT box, the request is done with a Public User: https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L171-L176 Since Public Users don't have reading access on the `pos.config` model, access rights & rules are triggered: https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/odoo/addons/base/models/ir_binary.py#L52-L58 Since we failed the try block, we end up loading the placehorder image by default: https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L185 We want the field `iface_customer_facing_display_background_image_1920` to be available to public user. In the case we are trying to access it with a public user, we make the request in sudo. Sudo environment stops existing once the request is made. opw-3873765 Forward-Port-Of: odoo/odoo#171994 Forward-Port-Of: odoo/odoo#169808
[IMP] l10n_tr: improve turkey's tax structure Adding new accounts Adding entirely new taxes Restructure the tax and tax group Create new tax report Reason: Enhance the user-experience in turkey Task-3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172056 Forward-Port-Of: odoo/odoo#167258
Original PR description
[IMP] l10n_tr: improve turkey's tax structure Adding new accounts Adding entirely new taxes Restructure the tax and tax group Create new tax report Reason: Enhance the user-experience in turkey Task-3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172056 Forward-Port-Of: odoo/odoo#167258
Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray. task-4036988 Forward-Port-Of: odoo/odoo#172069
Original PR description
Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray. task-4036988 Forward-Port-Of: odoo/odoo#172069
Issue: - when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot). Steps To Reproduce: - configure the sale app to have the discount&loyalty and free shipping options enabled. - create a product that cost 100$. - create a new discount/loyalty where type is promotions and set rule to if minimum 300$ spent the reward is free shipping max to 75$. - create a shipping method based on rules where the deliv
Original PR description
Issue: - when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot). Steps To Reproduce: - configure the sale app to…
Issue: - when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot). Steps To Reproduce: - configure the sale app to have the discount&loyalty and free shipping options enabled. - create a product that cost 100$. - create a new discount/loyalty where type is promotions and set rule to if minimum 300$ spent the reward is free shipping max to 75$. - create a shipping method based on rules where the delivery product is a service that costs 100$. - in your shipping mehtod pricing add a line with if quantity >= 3.0 then fixed price 100.0 and publish it. - in your website shop select 3 items from the product you created. and select your delivery method. - notice the prices not updating correctly. Solution: - Before the fix we always assumed that free_shipping_lines are equal to 0. - free_shipping_lines might be shipping discounts not actual free shipping.so I adjusted update_eshop_carrier method to make it handle the case of discounted shipping. opw-3718885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168917 Forward-Port-Of: odoo/odoo#154487
In a receipt picking, you can automatically set the Serial/Lots with 3 actions: 'Generate Serial/Lots' / 'Import Serial/Lots' / 'Assign Serial Numbers'. However, if 'use_existing_lots' is True on the picking type, the resulting move lines will appear without lots on the frontend. This is because these actions only set the lot_name, not the lot_id. After this commit, these 3 actions will use lot_id instead of lot_name if 'use_existing_lots' is True. They will either assign an existing 'stoc
Original PR description
In a receipt picking, you can automatically set the Serial/Lots with 3 actions: 'Generate Serial/Lots' / 'Import Serial/Lots' / 'Assign Serial Numbers'. However, if 'use_existing_lots' is True on the picking type, the resulting move lines will appear without lots on the frontend. This is because these actions only set the lot_name, not the lot_id. After this commit, these 3 actions will use lot_id instead of lot_name if 'use_existing_lots' is True. They will either assign an existing 'stock.lot' or create a new one in the correct company. --- ## BEFORE https://github.com/odoo/odoo/assets/29302288/f571d68d-86cb-42bf-bf8b-5e918c2ca2c2 ## AFTER https://github.com/odoo/odoo/assets/29302288/325c7870-a24a-4094-b0c0-5ff8274712d8 --- OPW-3983532 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171741 Forward-Port-Of: odoo/odoo#171388
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836). Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP. This is performed by upd
Original PR description
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP…
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836). Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP. This is performed by updating the _cron_peppol_get_participant_status cron to include EDI users that are not yet verified. When the user has been verified on the IAP side, the state 'verified' will be returned when making a call to the participant status endpoint, for which the most accurate mapping to a client state is 'pending'. Note that when managing users from versions 17.0 to 17.2 (inclusive) the support staff responsible for verifying the user should also take the steps to ensure that they are registered on the SMP too (since users of these versions will otherwise remain in the 'pending' state indefinitely until they are manually registered on the SMP). Forward-Port-Of: odoo/odoo#171823
Replace Sales Analysis By Customers with Sales Analysis Per Customers opw-3999628 Forward-Port-Of: odoo/odoo#171286
Original PR description
Replace Sales Analysis By Customers with Sales Analysis Per Customers opw-3999628 Forward-Port-Of: odoo/odoo#171286
Forward-Port-Of: odoo/odoo#172070
Original PR description
Forward-Port-Of: odoo/odoo#172070
Multiple fixes related to Audit Trail: * track more fields: * <account.move.line>.balance * <account.move.line>.tax_tag_ids * <account.tax>.l10n_de_datev_code * <res.company>.l10n_de_widnr * Track newly created lines once the move has been posted * Prevent deleting tracking messages/values linked to the audit trail [task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1) Forward-Port-Of: odoo/odoo#172193 Forward-Port-Of: odoo/odoo#171244
Original PR description
Multiple fixes related to Audit Trail: * track more fields: * <account.move.line>.balance * <account.move.line>.tax_tag_ids * <account.tax>.l10n_de_datev_code * <res.company>.l10n_de_widnr * Track newly created lines once the move has been posted * Prevent deleting tracking messages/values linked to the audit trail [task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1) Forward-Port-Of: odoo/odoo#172193 Forward-Port-Of: odoo/odoo#171244
Steps to reproduce the bug: - Create a storable product “P1”: - Create a reorder rule: - Min qty: 5 - Route: Buy - Click the “To order” button Problem: The button does not become invisible; the page must be refreshed to see the update. This can lead to user error if the user clicks the “order once” button a second time. opw-3994600 Forward-Port-Of: odoo/odoo#171968
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Create a reorder rule:
- Min qty: 5
- Route: Buy
- Click the “To order” button
Problem:
The button does not become invisible; the page must be refreshed to see the update. This can lead to user error if the user clicks the “order once” button a second time.
opw-3994600
Forward-Port-Of: odoo/odoo#171968Forward-Port-Of: odoo/odoo#172203
Original PR description
Forward-Port-Of: odoo/odoo#172203
Problem: When you click on the On Hand smart button from a product variant, it will show the on hand quantity for all of the product's variants. Purpose: Clicking on the On Hand smart button from a product variant should show only the on hand quantity for that specific product variant. Steps to Reproduce on Runbot: 1. Create a storable product with an attribute that has two values to create two product variants 2. Purchase stock for both product variants 3. Receive the purchased produ
Original PR description
Problem: When you click on the On Hand smart button from a product variant, it will show the on hand quantity for all of the product's variants. Purpose: Clicking on the On Hand smart button from a product variant should show only the on hand quantity for that specific product variant. Steps to Reproduce on Runbot: 1. Create a storable product with an attribute that has two values to create two product variants 2. Purchase stock for both product variants 3. Receive the purchased products 4. Enable Storage Locations in Settings > Inventory 5. Navigate to one of the product variants and click on the On Hand smart button 6. Observe that it shows the on hand quantity for both product variants opw-3988374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171306
When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users. This commi
Original PR description
When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users. This commit adds such attributes. This is similar to what was done on 9764e6f7 for the command palette to handle search results on the home screen. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170291 Forward-Port-Of: odoo/odoo#165903
Purpose ======= Considering that the user isn't admin, has enough karma to delete a post comment but not enough karma to delete a post. When the user deletes a comment, fix the warning alert saying that he doesn't have enough karma even though he has. Specification ============= Changing the condition to display the warning in the xml to use the comment unlink required karma instead of the post one. There is no comment can_unlink field so rebuilding the can_unlink condition. Task-4001
Original PR description
Purpose ======= Considering that the user isn't admin, has enough karma to delete a post comment but not enough karma to delete a post. When the user deletes a comment, fix the warning alert saying that he doesn't have enough karma even though he has. Specification ============= Changing the condition to display the warning in the xml to use the comment unlink required karma instead of the post one. There is no comment can_unlink field so rebuilding the can_unlink condition. Task-4001283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172167 Forward-Port-Of: odoo/odoo#170130
Issue --> When editing the account code for an `account.account` record with a large number of related `account.move.lines`, the method `_compute_always_tax_exigible` get called down the compute tree on all related `account.move` records. This leads to a MemoryError as the underlying field_cache expands beyond the allocated memory limit. Solution --> Disable the prefetcher in the loop to reduce the number of allocations made to the field_cache. Benchmarks --> Memory utiliz
Original PR description
Issue --> When editing the account code for an `account.account` record with a large number of related `account.move.lines`, the method `_compute_always_tax_exigible` get called down the compute tree on all related `account.move` records. This leads to a MemoryError as the underlying field_cache expands beyond the allocated memory limit. Solution --> Disable the prefetcher in the loop to reduce the number of allocations made to the field_cache. Benchmarks --> Memory utilization before PR -->  Reference flamegraph --> https://drive.google.com/file/d/1ptI8mOfvaACFmuwIEiN5f0rFRueu9h46/view?usp=drive_link After PR -->  Reference flamgraph --> https://drive.google.com/file/d/1dcaLz3jrDmkX96WagAylkL1V--dz9jNQ/view?usp=drive_link opw-3957975 Forward-Port-Of: odoo/odoo#171122
When mail totp is enforced, users are required to perform the MFA step after signup, before signin. The authentication is partial and the user is set to None. This causes the signup request to fail at the mail template rendering step with an access right error even though the registration is actually successful. Steps to reproduce: - Install apps `auth_totp_mail_enforce` and `website` - Login with admin user - In Settings: - Enable "Enforce two-factor authentication", set it to "All
Original PR description
When mail totp is enforced, users are required to perform the MFA step after signup, before signin. The authentication is partial and the user is set to None. This causes the signup request to fail at the mail template rendering step with an access right error even though the registration is actually successful. Steps to reproduce: - Install apps `auth_totp_mail_enforce` and `website` - Login with admin user - In Settings: - Enable "Enforce two-factor authentication", set it to "All users" - Set "Customer Account" to "Free sign up" - In a clean session (private browsing), try to sign up an account Old behavior: 403 error New behavior: 2FA page opw-3968129 Forward-Port-Of: odoo/odoo#169594