Monday, September 7, 2026
6 changes · 18.0
Resolved issues and error corrections
When portal users submit a website form to create a task, their provided phone number is now saved on the task so staff can contact them. Public user submissions continue to keep the phone number in the task description, while safeguards prevent users from changing other contacts' details.
Original PR description
# How to reproduce - Install Field Service - Add a form on the Website - Set the form's action to "Create a Task" - Create a new internal/portal user - Login as that user - Submit the form with the required data and a phone number - Inspect the created task as an admin # Issue partner_phone is empty # Cause If the form alters an existing user, we prevent any edition of that user : https://github.com/odoo/odoo/blob/615e54ecd2722433953931e1d51be15b069288c3/addons/website_project/controllers/main.py#L52-L59 # Proposed Solution The PO asked for the following : - if the task is submitted by a portal user -> show the number in partner_phone - if the task is submitted by a public user -> show the number in the description BUT, for security reason, we can't let a user edit any other user. So we limit the assignation to partner_phone only when the current user correspond to the edited partner opw-6374641
The Turkish e-Ledger export now fills line numbers automatically and keeps them continuous across monthly filings within the same fiscal period. This helps businesses meet GIB expectations and ensures monthly and full-year exports use consistent numbering in chronological order.
Original PR description
Before: the `LineNumber` column of the e-Ledger CSV was always empty, left to be filled after the export. Since the ledger is filed monthly, whatever filled it restarted at 1 every month, while GİB expects the numbering to start once, at the beginning of the fiscal period, and to run unbroken until its end. Now: the column is written by the export. An export starting after the first day of the fiscal period is offset by the number of rows that period already counts, so February continues where January stopped, and a full-year export numbers the same rows identically. The lines are also read in ascending date order. They were sorted by the default order of `account.move.line`, the most recent first, so the first row of the file was the last entry of the period and could not be numbered 1. This reverses `EntryNumberCounter` as well, which now counts from the oldest entry. task-6424730 Forward-Port-Of: odoo/enterprise#127518
This fix prevents duplicate registration attempts from creating mismatched local and remote credentials for the e-invoicing proxy service. It helps keep electronic document connectivity reliable and avoids situations where a database needs manual re-registration to recover.
Original PR description
In the current flow, _register_proxy_user first calls IAP create_user, then inserts the returned credentials in account_edi_proxy_client.user. At the same time, IAP create_user_2 may replace an existing user with a new one with different credentials before local persistence settles. So Tx A calls IAP and gets credentials for remote user U1. Tx B calls IAP and gets credentials for remote user U2 and unlinks U1. Tx A persists U1 locally. Tx B fails local insert due to a unique constraint. Client DB keeps U1 credentials, but IAP now expects U2. Subsequent proxy calls from the client fail. The DB is left with stale, unusable credentials and cannot recover without re-registration. IAP: https://github.com/odoo/iap-apps/pull/1816 task-6520501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoices for customers in the Canary Islands, Ceuta, or Melilla are now reported with the correct special tax regime code instead of a generic one. This improves compliance with Spanish electronic invoicing requirements and helps avoid incorrect tax submissions.
Original PR description
… key 8 When the customer is located in Canary Islands, Ceuta or Melilla, the invoice falls under a different tax territory and the ClaveRegimenEspecialOTrascendencia should be 08. Add the regime key 08 to the clave_regimen_selection in verifactu Previously this case was not checked and invoices were reported with the generic refime code. The regime key 08 is not available in verifactu. task-6372837 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue that could stop French PDP tax extract messages from being updated and sent correctly. The change ensures tax extract and lifecycle processing only applies to relevant PDP invoices, improving reliability for French e-invoicing workflows.
Original PR description
Currently we set the `pdp_ppf_move_state` to `in_progess` if we have no info about it yet. But this prevents us from updating the status of the ppf message when importing the tax extract. Also - only compute the tax extract and lifecycle state for pdp moves. - add some docstrings task-None
Restoring or duplicating a database with neutralization enabled now completes the safety step before scheduled background jobs can detect and run on the new database. This avoids unintended automated actions, such as emails or integrations, during database copy or restore operations.
Original PR description
Before this commit: If you restore a backup or duplicate a database via /web/database/manager with "Neutralize" enabled, the cron workers had a small window between the creation of the Registry and the neutralization of the database where they could try to execute crons. Since neutralize_database does not require a full registry to run (it only does raw SQL operations), we can run it before the Registry creation (which has the effect, among other things, of making the cron workers aware of the new database). opw-6517819 Forward-Port-Of: odoo/odoo#286532