Monday, September 9, 2024
7 changes · saas-17.4
Resolved issues and error corrections
This fix stops successful report image conversions from being treated as problems just because they produced warning messages. It helps keep system logs cleaner and makes real conversion errors easier to spot.
Original PR description
There may have warnings on stderr, even in case of success.
This fixes an issue where duplicate device session records could cause an error when a user changed their language. The change helps keep user settings updates reliable even when multiple devices share the same session details.
Original PR description
[FIX] base: deletion of duplicate device session Steps: - Have 2 devices log with the same last_activity, platform, browser, ip, session, user - Try to change the language of the user Actual result: - Missing record The record does not exist or has been deleted. (Record: res.device(X,), user: Y) Expected result: - No error, SQL view have distinct setup See: https://github.com/odoo/odoo/pull/162168 https://github.com/odoo/odoo/pull/177233 opw-4148761 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes user device records return consistent identifiers during the same operation. It prevents intermittent errors where a device record appeared to disappear, improving reliability when editing user information.
Original PR description
Issue: ------ Within the same transaction, the ids of the `res.device` model (non-materialised view) may not be consistent. This inconsistency triggers the error: ``` Record does not exist or has…
Issue:
------
Within the same transaction, the ids of the `res.device` model (non-materialised view) may not be consistent. This inconsistency triggers the error:
```
Record does not exist or has been deleted.
```
This behaviour can occur during an onchange on the `res.user` model, for example. We will determine the ids of the `device_ids` linked to the user with the following query (A):
```
SELECT id, user_id FROM res_device WHERE user_id=<user_id> ORDER BY id
```
We will obtain the ids of the devices linked to the user. However, for a given device, it is possible to perform a fetch to retrieve the field values. A query (B) of the following form is used:
```
SELECT <field_to_fetch> FROM res_device WHERE id=<id>
```
Unfortunately, it can happen that the id is no longer present in the `res_device` table. If we look at the query plans (in the appendices), postgresql takes the decision to remove the `user_id` from the `DISTINCT ON` clause when it is used in a `WHERE` clause (which influences the internal logic of Postgresql).
In practice, we sometimes get different results because of the sorting, which can be indeterministic depending on (d.session_identifier, d.platform, d.browser, d.last_activity DESC). In fact, there is a scenario (multiple workers) in which a device will create two logs with the same `last_activity`.
Solution:
---------
Add the `id` to the `ORDER BY` to obtain a deterministic sort.
Appendices:
-----------
Query A:
```
explain select id, user_id from res_device where user_id=2;
QUERY PLAN
-------------------------------------------------------------------------------------------
Subquery Scan on res_device (cost=39.39..42.13 rows=125 width=8)
-> Unique (cost=39.39..40.88 rows=125 width=233)
-> Sort (cost=39.39..39.76 rows=149 width=233)
Sort Key: d.session_identifier, d.platform, d.browser, d.last_activity DESC
-> Seq Scan on res_device_log d (cost=0.00..34.01 rows=149 width=233)
Filter: ((NOT revoked) AND (user_id = 2))
```
Query B:
```
explain select id, user_id from res_device;
QUERY PLAN
------------------------------------------------------------------------------------------------------
Subquery Scan on res_device (cost=39.29..42.52 rows=128 width=8)
-> Unique (cost=39.29..41.24 rows=128 width=233)
-> Sort (cost=39.29..39.68 rows=156 width=233)
Sort Key: d.user_id, d.session_identifier, d.platform, d.browser, d.last_activity DESC
-> Seq Scan on res_device_log d (cost=0.00..33.61 rows=156 width=233)
Filter: (NOT revoked)
```The Point of Sale code was updated to remove an outdated date-handling method that is no longer used by the current payment flow. This reduces maintenance risk and helps keep payment-related behavior consistent without changing the cashier experience.
Original PR description
This commit removes the `getUTCString` method from PoS, as it is no longer relevant to the current implementation. opw-4109126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where saving or cancelling an edited chatter note required two clicks. Users can now complete message edits immediately, reducing confusion and extra clicks in daily communication workflows.
Original PR description
Problem: Elements inside `CANCEL_OR_SAVE_EDIT_TEXT` are created twice, which interferes with event handling. To fix this, the element is now created in the setup method. Steps to reproduce: - Open the chatter. - Log a note. - Edit the note. - Now, if you click Save or Cancel, both actions will only work on the second click. opw-4119283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting journal setup now shows wording that matches the type of journal being configured. For miscellaneous journals, email-based creation is labeled as creating entries instead of invoices, reducing confusion for users.
Original PR description
When going on a misc journal, the title of the group is "create invoices upon emails" but in the case of a misc journal we don't want to create an invoice but an entry. We will duplicate the group and change the invisible conditions to make it work. task: 4160550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Description of the issue/feature this PR addresses: When we try to send an invitation email with the pr_BR template it crashes because it tries to access the `signup_url` through `object`, but instead it should be accessed through `object.partner_id._get_signup_url()` Current behavior before PR: When you try to send an invitation email with language Portuguese (BR) / Português (BR) under Localization, it crashes. Desired behavior after PR is merged: When you try to send an invitation em
Original PR description
Description of the issue/feature this PR addresses: When we try to send an invitation email with the pr_BR template it crashes because it tries to access the `signup_url` through `object`, but instead it should be accessed through `object.partner_id._get_signup_url()` Current behavior before PR: When you try to send an invitation email with language Portuguese (BR) / Português (BR) under Localization, it crashes. Desired behavior after PR is merged: When you try to send an invitation email with language Portuguese (BR) / Português (BR) under Localization, it works. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr