Daily updates from Odoo
Friday, December 13, 2024
7 changes · 18.0
Resolved issues and error corrections
This fix prevents Odoo workers from repeatedly reloading internal data or clearing caches when requests use read-only database replicas. It improves stability and resource usage for deployments using database replication, while keeping normal request handling on the intended database mode.
Original PR description
The PostgreSQL streaming physical replication notably does not synchonize sequence data[^1]. For sequences that are only used to generate unique IDs (for primary keys), this is not a concern because…
The PostgreSQL streaming physical replication notably does not synchonize sequence data[^1].
For sequences that are only used to generate unique IDs (for primary keys), this is not a concern because those IDs *will be* replicated correctly.
However it's a different story for sequences that are used directly. For us it means that on read-only cursors targeting database replicas, the registry and cache generation numbers (`base_registry_signaling` and `base_cache_signaling_*`) will remain fixed and out of sync with the values on the read-write master database.
As a consequence, workers serving alternating read-write and read-only requests will keep reloading the registry or discarding caches, because they will jump between the progressing master sequences, and the fixed sequences on the replica.
For HTTP workers this causes a peformance hit and suboptimal usage of resources, as the registry will be needlessly reloaded after a "sequence jump", or caches discarded.
For Gevent workers it may be much worse, because the registry reloading will *yield* and may be started by hundreds of different greenlets, blocking as many database connections, until the connection pool is exhausted. Repeat and rinse...
Note that the problem could manifest even for a worker that only ever processes read-write requests (like Gevent), because the registry and signaling checks were explicitly done in read-only mode.
As a mitigation, this patch forces the cursor mode to "read-write" during the registry loading and signaling checks, regardless of the actual request mode. This causes some minimal extra load on the master database, but ensures that the signaling checks will always use the correct sequences. The actual request handling, which is the costly part, will still be executed in the dynamically selected cursor mode.
PS: this patch does not change the possibility of having a pure read-only server, with a replica connection used for both the read-write and read-only database connections in the config. One should however be aware that the signaling sequences will never advance, so the replica will not receive the signals.
-----
Note: in master we could overcome this limitation by defining an explicit append-only `base_signal` table, with an `id` PK column driven by a sequence, like all tables. Then, whenever we want to trigger a signal, we would simply insert a row in the table with the corresponding signal:
```sql
CREATE TABLE base_signal (
id SERIAL PRIMARY KEY,
signal VARCHAR
);
-- increment signal `registry`
INSERT INTO base_signal (signal) VALUES ('registry')
-- check current signal `registry`:
SELECT max(id) FROM base_signal WHERE signal = 'registry';
```
The `base_signal` table would be properly synchronized and visible on replicas, and could be trivially garbage collected by the autovacuum system. As a bonus, it would also make signaling transactional, in the sense that a transaction would be unable to trigger a signal and then rollback due to a later error. The sequence ID might advance, but the row won't be inserted.
Cfr task-4399456
[^1]: https://www.postgresql.org/docs/16/logical-replication-restrictions.htmlThe Discuss sidebar now visually de-emphasizes inactive conversations so the active chat remains easier to focus on. Unread conversations still stand out enough to be noticed, improving usability without changing functionality.
Original PR description
Discuss sidebar items are too catchy, which is distracting when the core part of Discuss app is the conversation itself. As much as possible, conversation should be very visible while other elements are slightly less visible. This problem is even more pronunced when the sidebar is compact, because the avatars in sidebar are next to avatars of conversation, which is even more distracting. This commit fixes the issue by reducing opacity slightly on non-active sidebar items. Conversation that are unread and unactive have an in-between opacity so they are more visible than other read and non-active conversations but still have reduced opacity so that this is less distracting than the conversation itself. Backport of https://github.com/odoo/odoo/pull/190071
This fixes an error that could occur when adding image icons to email templates. Users can now save templates with icons reliably, reducing interruptions when preparing branded or visual email communications.
Original PR description
Currently, an error occurs when using an image icon in the email template. Step to produce: - Install the ```mail``` module. - Go to Settings / Technical / Email / Email Templates, and open any templates. - Insert any image icon, and save the record. ValueError: `unknown color specifier: '1x1'` An error occurred when attempting to retrieve computed styles for the element during inlining converting. Specifically, when the system tries to fetch the color code and other CSS properties, it returns empty values because `getComputedStyle` fails to properly access the full set of styles from the cloned element. This is because `getComputedStyle` cannot retrieve styles from an element when it is detached from DOM (a cloned element not in a DOM). To resolve this issue, The cloned element is temporarily added to the DOM,So `getComputedStyle` access the required style properties. Ref:- https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle Sentry-5747299019
The HTML editor now correctly enables the remove formatting button when any selected content includes formatting, even if other selected text is plain. This makes editing formatted content more predictable and prevents users from being blocked from clearing styles in mixed selections.
Original PR description
When the selection contains formatted nodes among unformatted nodes, the remove format toolbar button should be available. This is not the case currently because the `hasAnyFormat` method, which is used to determine whether the button should be disabled, checks if **every** node in the selection is formatted. This commit fixes the issue by checking if **any** node in the selection is formatted instead. task-4385246
Fixes an error that occurred when users clicked the “Same payment” link after duplicating a confirmed payment. The payment screen now opens the related business document correctly, preventing an unexpected interruption in accounting workflows.
Original PR description
In the payment view, he `x2many_buttons` widget on `duplicate_payment_ids` calls the `action_open_business_doc`, but this method is not implemented on `account.payment`. This was not not a problem before 01b87f1230beac0568f4e3b1b76e547909506892 since a payment was always linked to a move, therefore we were calling the method from `account.move`. With this commit, we implement the `action_open_business_doc` in `account.payment`. Step: - Create a payment and confirm - Duplicate it - Click on the 'Same payment' hyperlink -> Error: "The method 'action_open_business_doc' does not exist on the model 'account.payment'" opw-4363907
Fleet contract status changes now use the same internal actions whether they are triggered automatically or by date updates. This makes custom behavior for opening or closing contracts easier to maintain and reduces the risk of inconsistent contract handling.
Original PR description
Since there are two mechanism that changes the status of a contract (a cron and the write of a date), we have to override 2 different places when we want to add a behavior on closing or opening of contracts. As there are already functions (action_expire, ...) that exist and are use in the write part, we also use them in the cron, so we'll have only one place where we need to override it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Documents where opening a folder could fail after previewing a file, closing the preview, and switching views. Users can now continue navigating folders normally without encountering an error.
Original PR description
Steps to reproduce the traceback: - preview a file from the kanban view - close the preview - switch to list view - open a folder To Be: The folder should open correctly. Technical: The traceback happens because the 'getSelectedDocumentsElements' calls a querySelectorAll on the component root element without checking if it exists. Fixing the issue by making sure the component effectively have a root element before calling the method. Task-4373626