Thursday, January 29, 2026
6 changes · 18.0
Resolved issues and error corrections
This update resolves an intermittent issue where event registrations would fail with a 500 error when the 'Mail Scheduler' cron job was running. The fix prevents a database conflict by skipping the automatic commit during registration, ensuring registrations are reliably processed.
Original PR description
Registering for an event while the mail scheduler cron was running could lead to a PostgreSQL serialization failure, leading to a 500 error and the failure of the registration. ### Reproduction Steps…
Registering for an event while the mail scheduler cron was running could lead to a PostgreSQL serialization failure, leading to a 500 error and the failure of the registration. ### Reproduction Steps 1. Configure an Event with a "Mail Scheduler" set to trigger "After each registration" with an interval of "Immediately". 2. Ensure the "Event: Mail Scheduler" cron job is active and running. 3. As a public user or portal user, attempting to register for this event will intermittently fail with an HTTP 500 error. 4. The server logs will show `psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update`, followed by `psycopg2.errors.InFailedSqlTransaction`. 5. The registration is not created. ### Cause When a user registers for an event, the system immediately attempts to process any "on-registration" emails. The method used (`_execute_attendee_based`) forces a database `commit()`. When this `commit()` is executed, the Postgres database attempts to finalize the user's transaction. However, if the concurrent background cron job has modified the same event/mail records while the user's request was processing, Postgres detects a serialization conflict. Consequently, the commit itself fails and raises `SerializationFailure`. Because the commit failed, the user's transaction is rolled back, and the registration record is never persisted to the database (explaining the missing attendees). Critically, the exception handling logic in `_update_mail_schedulers` catches this `SerializationFailure` (preventing odoo from retrying the transaction) but then attempts to perform further database operations (to log the error). Since the transaction is already in an aborted state due to the failed commit, this triggers a secondary `InFailedSqlTransaction` error. This secondary error is not recognized as a concurrency error by Odoo's automatic retry mechanism (`odoo.service.model.retrying`), resulting in a hard crash instead of a retry. ### Fix The logic now checks the execution context using `event_mail_registration_ids`. If triggered by a user registration (indicated by the presence of specific registration IDs in the context), the explicit `commit()` is skipped. opw-5355116
This update fixes a potential issue where users re-registering through PEPPOL wouldn't be properly reset. The change ensures that proxy user accounts are archived when a participant's status changes, allowing for a smoother and more reliable re-registration process. This improves the overall user experience for PEPPOL integration.
Original PR description
Currently, if the participant_status gets a client_gone, we call the _reset_peppol_configuration method. But while we reset, we don't archive the proxy_user. We should do so, so the user can re-register --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request addresses several stability issues within the Hoot system, primarily focused on improving test coverage and error handling. Specifically, it expands the mocked API to better simulate real-world XHR requests and fixes a misleading error message during testing, ensuring more reliable test results.
Original PR description
### [FIX] Hoot fixes This PR contains several fixes for the Hoot system. See each commit description for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances Odoo's compliance with Saudi Arabian tax regulations (ZATCA) by making the 'Additional Buyer ID' visible for non-Saudi partners when operating in Saudi Arabia. It ensures that VAT is used as the primary buyer ID when available, and falls back to the Additional Buyer ID if VAT is missing, streamlining ZATCA XML generation. This change supports accurate tax reporting for our non-Saudi customers.
Original PR description
This commit makes l10n_sa_additional_identification_number visible for non-Saudi individuals and company partners when the active company is in Saudi Arabia and keeps the identification scheme fixed to OTH, keeping it invisible. When generating ZATCA XML for non-Saudi partners, VAT is used as the primary buyer ID if present, and fall back to the additional identification number when VAT is missing. task-4525956
This update fixes a misclassification of account 649 in the French Profit and Loss report. The change aligns with French accounting standards (PCG 2025 & 2026) ensuring accurate reporting of wages and social security charges. This improves the report's compliance and reliability for French businesses.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105474This update ensures that users mentioned in sub-channels, even if they aren't direct members, receive ping notifications and the sub-channel appears in their sidebar. Previously, this caused missed notifications, which has now been resolved to improve communication and collaboration within the system.
Original PR description
Before this commit, when a user was mentioned in a sub-channel they were not member of, the sub-channel would not appear in their sidebar. This could lead to some missed pings. This commit fixes the issue by automatically adding mentioned users to the sub-channel, ensuring it is pinned to their sidebar. task-5233958