Saturday, November 1, 2025
7 changes · saas-18.4
Resolved issues and error corrections
Users importing Indian IRN invoice files no longer need extra company record permissions for the import to work. This prevents an access error and lets the invoice import process complete successfully for affected users.
Original PR description
When importing an IRN JSON as an invoice, users without sufficient access rights to `res.company` fields encountered an access error on `l10n_in_edi_production_env`. This commit uses `sudo()` to safely read the company’s EDI environment configuration without requiring extra permissions. Before this PR: Import failed with error: `You do not have enough rights to access the field 'l10n_in_edi_production_env' on Companies (res.company)` After this PR: Import proceeds successfully for users without `res.company` read rights. Forward-Port-Of: odoo/enterprise#98528
This fix prevents Point of Sale session numbers from being skipped when cash detail posting fails. Session names now advance only after the operation succeeds, keeping records easier to track and audit.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/enterprise/pull/98157 opw-5180712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233784 Forward-Port-Of: odoo/odoo#233183
Belgian POS session names now stay continuous when cash posting fails. The session number is only used after a successful operation, helping keep point-of-sale records consistent and easier to audit.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/odoo/pull/233183 opw-5180712 Forward-Port-Of: odoo/enterprise#98468 Forward-Port-Of: odoo/enterprise#98157
The Planning app now shows the recurrence banner only after recurring shifts have actually been created. This avoids confusing users with a banner that appears too early and has no practical effect yet.
Original PR description
**Steps to reproduce:** --------- 1. Create a shift. 2. Save the shift. 3. Open the shift and enable the recurrence. 4. Observe that the recurrence banner is immediately displayed. **Issue:** ----- The recurrence banner is shown as soon as a shift is marked recurring, even though no recurring shifts have been generated yet. This is misleading since the banner has no effect until the actual recurrence slots exist. **Cause:** ------- The banner visibility was based on repeat and id, so it appeared too early, before any recurring shifts were actually created. **Fix:** -------- Update the banner visibility condition to check for both repeat and recurrency. Now, the recurrence banner only appears once the recurrence record exists and recurring shifts are generated: task-5163851 Forward-Port-Of: odoo/enterprise#97245
Downloading document folders now avoids creating unintended subfolders when document names contain slashes. Slashes in downloaded file names are replaced with underscores, making extracted zip files easier and more predictable to use.
Original PR description
Bug === If you download a folder that has documents in it, with `/` in their names, then after extracting the zip, it will create folders for the part on the left of `/`. To solve that issue, we replace the `/` with `_`. Task-5109681 Forward-Port-Of: odoo/enterprise#96087
Adding multiple contacts to a mailing list through the wizard now records the subscription date correctly. This ensures marketing teams see complete and consistent mailing list history regardless of how contacts are added.
Original PR description
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List…
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List button 5. From wizard select the newly created list and click on Add button 6. Open one of the contact added in step 4 Observation: ------------------------- In the Mailing Lists tab of the contact, the newly added list does not show a Subscription Date. However, if we add the same through Add a line, the subscription date is shown correctly. Issue: ------------------------- When adding contacts to a mailing list through the wizard, the code https://github.com/odoo/odoo/blob/1e6ba783fcd898875dadb47924147688685707cf/addons/mass_mailing/wizard/mailing_contact_to_list.py#L34-L39 adds the contact using a direct database operation. This bypasses the ORM record creation for `mailing.subscription`, so the `create_date` (subscription date) is never set. Solution: ------------------------- Use `Command.create` on the `subscription_ids` field to properly create the `mailing.subscription` records and ensure the Subscription Date is set. opw-5055372 Forward-Port-Of: odoo/odoo#230284
This fix prevents archived bank account records from being counted when checking whether multiple contacts share the same bank account. Users will no longer see misleading duplicate bank account warnings on contact pages when the only matching records have been archived.
Original PR description
If a res_partner_bank record shares an acc_number with other res_partner_bank records, even archived ones, the field duplicate_bank_partner_ids still includes partners from those archived records. As…
If a res_partner_bank record shares an acc_number with other res_partner_bank records, even archived ones, the field duplicate_bank_partner_ids still includes partners from those archived records. As a result, the contact page shows a banner indicating other partners use the same bank account, even though those res_partner_bank records have been archived. Steps to reproduce the issue: 1. Create a new bank account which has the same bank account number as another bank account already associated to a partner 2. Assign this new bank account to another partner 3. Archive this new bank account 4. Go to the contact page of the partner (from step 1) which has a bank account with the same bank account number as the new bank account just created 5. A banner will pop up at the top of the contact saying that this partner uses the same bank account as the partner you set on the bank account in step 2 Solution: Add a condition to the JOIN clause that checks “other.active = TRUE” to ensure that other res_partner_bank records to search for that have the same account number are active. Also add a condition to the WHERE clause that checks “this.active = TRUE” to ensure that the current res_partner_bank record doing the search is active itself. opw-4967083 Forward-Port-Of: odoo/odoo#232018 Forward-Port-Of: odoo/odoo#231585