Wednesday, August 21, 2024
5 changes · saas-17.4
Resolved issues and error corrections
Restores the online shop behavior that recalculates a product's displayed price when a customer changes the quantity. This prevents shoppers from seeing stale or incorrect pricing before adding items to their cart.
Original PR description
This change reverts part of 3e2e607ad4b8d6add1003ce9469782d4c2fc3853 which incorrectly deleted the `onChangeAddQuantity` method, which recomputes the price of a product when its quantity is changed. opw-4126123
Users can no longer send a chat or discussion message while an attachment is still uploading. This prevents cases where the attachment was uploaded but the written message was lost, improving reliability when networks are slow.
Original PR description
Before this commit, when attempting to post a message that contains text and had a file uploading, this fails to send the message. Steps to reproduce: - Use slow network (e.g. "Slow 4g") - Type some text in composer - Copy-paste a file with CTRL-V in input - Send message with ENTER => The attachment is sent but the text failed to post. Even though clicking on error can attempt to resend the textual message, it never works because it is linked to uploading attachment but it doesn't exist anymore, so the message is permanently lost. There is in fact some code that should prevent posting a message while there are file that are still uploading. This was not working because typing some text was wrongfully a condition enough to not put alert. This commit fixes the issue by properly preventing sending message while attachment is being uploaded. 
This update improves how Odoo retrieves a user's recent device activity so the database can use the right lookup path. User profile pages that show device information should load much faster, especially on systems with many device logs.
Original PR description
Explanation: ------------ To retrieve the last log from a device, keys (session_identifier, platform, browser) are sufficient. But in order to encourage postgresql (when it optimises costs) to use…
Explanation:
------------
To retrieve the last log from a device, keys (session_identifier, platform, browser)
are sufficient. But in order to encourage postgresql (when it optimises costs)
to use the index placed on `user_id`, it is a good idea to add it as a key
in the `DISTINCT ON` and `ORDER BY`.
In theory, adding `user_id` does not change the result of the view, due to the fact
that a `session_identifier` should match only a unique ``user_id``. This cannot be
guaranteed in practice (and it will depend on the order) but the risk of collision
is very low, i.e. several `user_id` who match a `session identifier`.
It makes sense to add this constraint in order to optimise performance when loading
the user profile view during which a `WHERE` clause on the user is added.
Analyze:
--------
`res_device`: before commit
`res_device_2`: after commit
```
explain analyze select * from res_device where user_id=<ID>;
Subquery Scan on res_device (cost=67659.10..74221.39 rows=504 width=153) (actual time=484.820..671.743 rows=8 loops=1)
Filter: (res_device.user_id = 13)
Rows Removed by Filter: 279564
-> Unique (cost=67659.10..72962.57 rows=100705 width=153) (actual time=483.679..653.555 rows=279572 loops=1)
-> Sort (cost=67659.10..68984.97 rows=530347 width=153) (actual time=483.677..565.894 rows=530442 loops=1)
Sort Key: d.session_identifier, d.platform, d.browser, d.last_activity DESC
Sort Method: quicksort Memory: 165461kB
-> Seq Scan on res_device_log d (cost=0.00..17232.18 rows=530347 width=153) (actual time=0.009..84.712 rows=530442 loops=1)
Filter: (NOT revoked)
Rows Removed by Filter: 75
Planning Time: 0.107 ms
Execution Time: 686.165 ms
(12 rows)
```
```
explain analyze select * from res_device_2 where user_id=<ID>;
Unique (cost=10.72..10.81 rows=9 width=153) (actual time=1.333..1.338 rows=8 loops=1)
-> Sort (cost=10.72..10.74 rows=9 width=153) (actual time=1.332..1.333 rows=12 loops=1)
Sort Key: d.session_identifier, d.platform, d.browser, d.last_activity DESC
Sort Method: quicksort Memory: 28kB
-> Index Scan using res_device_log__user_id_index on res_device_log d (cost=0.42..10.57 rows=9 width=153) (actual time=1.299..1.320 rows=12 loops=1)
Index Cond: (user_id = 13)
Filter: (NOT revoked)
Planning Time: 0.117 ms
Execution Time: 1.358 ms
(9 rows)
```This fix ensures IoT devices can access the needed communication channel when at least one printer is configured to print a report. It prevents report printing from being blocked by an incorrect channel check, improving reliability for businesses using IoT-connected printers.
Original PR description
Before this fix: An IoT won't be able to get the IoT channel except if the report company does not match the websocket channel company ID. See: https://github.com/odoo/enterprise/pull/68308 After this fix: Get the websocket channel as long as at least one printer is set to print report
Users can now connect and sync Google Calendar even when older appointment events reference someone who was later removed from the appointment. This prevents one outdated event from blocking calendar synchronization for all attendees.
Original PR description
Before this commit, users could encounter an access error when attempting to connect to Google Calendar. If a user was removed from an appointment but an existing calendar event still belonged to that user, all attendees of that event would be unable to sync their calendar with Google, resulting in an access error. The error message displayed was: Sorry, Marc Demo (id=6) doesn't have 'read' access to: - Appointment Type, Test Demo (appointment.type: 3). opw-4109304