Tuesday, July 21, 2026
16 changes · saas-19.4
Resolved issues and error corrections
Shop Floor now lists manufacturing orders with planned work orders before unplanned ones, matching the expected work order priority. This helps production teams see scheduled work in the right order and avoid missing planned jobs behind unscheduled items.
Original PR description
## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will…
## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end. ## Steps to reproduce (runbot 19) 1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B. 2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id 3. Go back to MO B and plan it. This should give it precedence in Shop Floor 4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list. opw-6303323 Forward-Port-Of: odoo/enterprise#121993 Forward-Port-Of: odoo/enterprise#121693
Argentine electronic invoices now show a proper user warning when a final consumer contact uses an unsupported identification type. This prevents an unexpected system error during invoice confirmation and helps users correct customer data before submitting invoices.
Original PR description
After applying the community fix, a new issue appears in enterprise. **Steps to reproduce:** - Install the `l10n_ar_edi` module. - Go to Customers and create a new customer with: - Country: Argentina…
After applying the community fix, a new issue appears in enterprise. **Steps to reproduce:** - Install the `l10n_ar_edi` module. - Go to Customers and create a new customer with: - Country: Argentina - Identification Type: `Passport` - Identification Number: `1234567890a` - AFIP Responsibility Type: `Consumidor Final` - Create a new invoice for this customer with: - Journal: `Electronic Invoice (FE)` - Document Type: `(6) INVOICES B` - Try to confirm the invoice. **Error:** ValueError: invalid literal for int() with base 10: '1234567890a' **Expected behaviour:** For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, the identification type must be `DNI` or `CUIL/CUIT`. If another identification type is used, the user should receive a proper warning instead of a traceback. (see [1]) **Root Cause:** After the community fix, `_get_id_number_sanitize()` can return an alphanumeric value, which is later converted with `int()` at [2] and [3], causing an error. **Fix:** This commit adds an explicit validation for Argentinean contacts with AFIP Responsibility Type Consumidor Final before converting the identification number to an integer, ensuring the user receives the proper warning message. [1]: https://www.odoo.com/mail/message/1118392033 [2]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798 [3]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931 Related community PR: https://github.com/odoo/odoo/pull/272651 opw-6333998 Forward-Port-Of: odoo/enterprise#124789 Forward-Port-Of: odoo/enterprise#123729
Indian GST reports have been adjusted so imports of services no longer appear in GSTR-2B, matching legal reporting requirements. GSTR-3B handling for imports of goods and services has also been updated to align with revised reporting sections, helping businesses file more accurate returns.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737 Forward-Port-Of: odoo/enterprise#124316 Forward-Port-Of: odoo/enterprise#121925
VoIP call recordings made from Apple mobile devices will no longer produce silent audio files. The recording quality setting was adjusted for Apple mobile browsers so recorded calls play back correctly.
Original PR description
Before this commit, recording a VoIP phone call from an Apple mobile device generated a silent audio file. This issue happened because the configured 8000 `audioBitsPerSecond` value was too low. Apple mobile browsers strictly respect this value, while other browsers ignore it and default to a higher bitrate to 128000. Increasing `audioBitsPerSecond` to 32000 on WebKit browsers fixes the issue on Apple mobile devices. How to reproduce: - Set up a DIDWW user. - Enable call recording. - Make a call. - Open the call and play the recording. opw-6046534 Forward-Port-Of: odoo/enterprise#117885
Swiss QR-IBAN payment references are now cleaned before bank file validation, removing unsupported characters such as the degree symbol. This helps prevent ISO 20022 payment files from being rejected by Swiss banks while keeping valid QR references intact.
Original PR description
**Steps to reproduce:** * Configure a Swiss company with the Swiss accounting localization. * Install `account_sepa`. * Configure a bank journal with a valid Swiss **QR-IBAN**. * Create a vendor with…
**Steps to reproduce:** * Configure a Swiss company with the Swiss accounting localization. * Install `account_sepa`. * Configure a bank journal with a valid Swiss **QR-IBAN**. * Create a vendor with a valid Swiss bank account. * Under **Accounting -> Configuration -> Settings** enable QR Payments. * Go to the vendor and enter the correct QR-IBAN number under the Accounting Section. * Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the account number of QR-IBAN. * Create and post a vendor payment using the bank journal. * Set the payment reference (`ref`) to contain the `°` character. * Add the payment to a batch payment and generate the ISO 20022 payment file. * Inspect the generated XML. **Observed Behaviour:** The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that may be rejected by Swiss banks because it does not comply with the EPC minimum character set. **Cause:** The QR-IBAN branch validates the structured reference before sanitizing it, allowing unsupported characters to remain in the generated XML. **Fix:** Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters are removed while preserving valid QR references. opw - 6350931 Forward-Port-Of: odoo/enterprise#125049 Forward-Port-Of: odoo/enterprise#123267
Fixes an issue where duplicating certain Sign templates with multiple documents, signers, and fields could fail. This helps users reliably reuse existing signing templates without manual rebuilding or interruption.
Original PR description
Issue: This [loop](https://github.com/odoo-dev/enterprise/blob/55bb2cc570451361701d53583f019ed832a5e5d3/sign/models/sign_item.py#L59-L63) runs multiple times with the same approvers(sign.item.role), but doesn't take into account the already 'seen map' inside the base copy function for batching. If they are already seen they will return a non-iterable [None]. To replicate: 1) Sign -> Template -> upload PDF 2) Go into the template 3) Add 2 Documents, with 2 signers and multiple fields on both documents 4) Save -> gear Icon -> make into template 5) Go back to the list view of templates 6) Select the template -> Gear Icon -> Duplicate Fix: add an already seen check to skip if already seen. opw-6352408 Forward-Port-Of: odoo/enterprise#123814 Forward-Port-Of: odoo/enterprise#122667
A redundant test step was removed to prevent an artificial timing issue during automated checks. This makes the restaurant appointment testing process more reliable without changing how users use the system.
Original PR description
The `RestaurantAppointmentTour` performed two consecutive "Reload Data" actions. The first reload starts synchronizing data from the server to IndexedDB. If the second reload is triggered before the synchronization completes, it deletes the IndexedDB while it is still in use, causing the synchronization process to crash. This race condition can be reproduced locally by running the tour with `cpu_throttling` enabled. In practice, users never trigger two consecutive reloads, so the second reload step in the tour is unnecessary. Remove it to avoid the artificial race condition while preserving the intended test coverage. Task-[6364951](https://www.odoo.com/odoo/project/1737/tasks/6364951) Runbot Error-[941343](https://runbot.odoo.com/odoo/error/941343), [941344](https://runbot.odoo.com/odoo/error/941344), [941345](https://runbot.odoo.com/odoo/error/941345) Forward-Port-Of: odoo/enterprise#125028 Forward-Port-Of: odoo/enterprise#123429
Steps to reproduce: - Install the PayU payment provider. - Click the Connect button and complete the onboarding flow. - After being redirected back to the PayU provider form, click Disconnect. Issue: - After confirming the disconnection, a validation error is raised stating that the PayU fields must be filled in. Cause: - During disconnection, the PayU-specific fields are cleared. At that point, `_check_required_if_provider` is triggered, and since those fields have the `required_if_p
Original PR description
Steps to reproduce: - Install the PayU payment provider. - Click the Connect button and complete the onboarding flow. - After being redirected back to the PayU provider form, click Disconnect. Issue: - After confirming the disconnection, a validation error is raised stating that the PayU fields must be filled in. Cause: - During disconnection, the PayU-specific fields are cleared. At that point, `_check_required_if_provider` is triggered, and since those fields have the `required_if_provider` attribute, it raises a `ValidationError` because their values are now `None`. Fix: - Remove the `required_if_provider` attribute from the PayU-specific fields. opw-6391133 Forward-Port-Of: odoo/odoo#276567
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`. **Error:** `ValueError: invalid literal for int() with base 10: '1234567890a'` **Issue 2:** - Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`. - Set `Identification Number` to `1234567890a`. **Observation:** All non-digit chara
Original PR description
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and…
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`. **Error:** `ValueError: invalid literal for int() with base 10: '1234567890a'` **Issue 2:** - Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`. - Set `Identification Number` to `1234567890a`. **Observation:** All non-digit characters are stripped, and the identification number is silently changed to `1234567890`. **Expected behaviour:** Any Identification Type other than CUIT (80), CUIL (86), and DNI (96) should be kept unchanged without stripping alphabetic characters. **Root Cause:** At [1], `_get_id_number_sanitize` sanitizes identification numbers based on the selected Identification Type. - For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes separators (e.g., spaces and dashes). If the identification number contains alphabetic characters, they are preserved and called `int()` on the resulting value, raising a `ValueError`. - For all other identification types, valid alphanumeric values are unintentionally modified by stripping non-digit characters. **Fix:** This commit validates identification numbers before sanitization for `CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric identification numbers are converted. For all other identification types, it preserves alphanumeric characters by removing only non-alphanumeric separators. [1]: https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136 Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729 opw-6333998 Forward-Port-Of: odoo/odoo#277132 Forward-Port-Of: odoo/odoo#272651
Previously: 1.`purchase_cdnur_regular` section was assigned to credit/debit notes of: - import of goods - import of services without RCM However: - import of goods should be handled through bill of supply - import of services without RCM is not possible Therefore, with this commit, such journal items are moved to `purchase_out_of_scope`. 2.`purcha
Original PR description
Previously:
1.`purchase_cdnur_regular` section was assigned to credit/debit notes of:
- import of goods
- import of services without RCM However:
- import of goods should be handled through bill of supply
- import of services without RCM is not possible Therefore, with this commit, such journal items are moved to `purchase_out_of_scope`.
2.`purchase_imp_services` section included import of services both with and
without RCM. Since import of services without RCM is not possible, those
journal items are now moved to `purchase_out_of_scope`.
3.Credit/debit notes of import of services with RCM were previously moved to
`purchase_out_of_scope`, which was incorrect. With this commit, they are now
correctly moved to `purchase_imp_services`.
task-6330737
Forward-Port-Of: odoo/odoo#276301
Forward-Port-Of: odoo/odoo#272453**Issue:** The course-specific options should appear after the forum page options, but they are displayed before them. **Reason:** Due to refactoring [commit], the course-specific options were inserted after a generic page hook. Since `website_slides_forum` is loaded before the forum module, the options were added before the forum page options, resulting in an incorrect order. **Steps to Reproduce:** 1. Go to /forum. 2. Enter edit mode. 3. Notice that the course-specific options a
Original PR description
**Issue:** The course-specific options should appear after the forum page options, but they are displayed before them. **Reason:** Due to refactoring [commit], the course-specific options were…
**Issue:** The course-specific options should appear after the forum page options, but they are displayed before them. **Reason:** Due to refactoring [commit], the course-specific options were inserted after a generic page hook. Since `website_slides_forum` is loaded before the forum module, the options were added before the forum page options, resulting in an incorrect order. **Steps to Reproduce:** 1. Go to /forum. 2. Enter edit mode. 3. Notice that the course-specific options appear before the forum page options. **Fix:** Extend the forum page options instead of the generic page hook ensuring course-specific options to be inserted after the forum page options. | Before | After | | ----- | -----| | <img width="285" height="267" alt="image" src="https://github.com/user-attachments/assets/73fb1f27-4edc-47eb-8bed-a873aea8a427" /> | <img width="285" height="268" alt="image" src="https://github.com/user-attachments/assets/d56aac2a-c66f-4c81-b04e-f204613d2c9c" /> | [commit]: https://github.com/odoo/odoo/commit/3f63c76da0b867facd5ed021beea79efabea15f1 task-[6359989](https://www.odoo.com/odoo/project/974/tasks/6359989) Forward-Port-Of: odoo/odoo#275921
Steps to reproduce: 1. Edit/Create an activity type (e.g., "To Do") and enable "Keep Done". 2. Schedule an activity of this type on a journal (or a journal entry/move) with a deadline in the past. 3. Mark the activity as done. 4. Go to the Accounting Dashboard. Notice that the activity is still shown as "overdue" in red on the journal card. When an activity type has "Keep Done" enabled, completed activities are not deleted from the database. Instead, they are archived by setting `active =
Original PR description
Steps to reproduce: 1. Edit/Create an activity type (e.g., "To Do") and enable "Keep Done". 2. Schedule an activity of this type on a journal (or a journal entry/move) with a deadline in the past. 3. Mark the activity as done. 4. Go to the Accounting Dashboard. Notice that the activity is still shown as "overdue" in red on the journal card. When an activity type has "Keep Done" enabled, completed activities are not deleted from the database. Instead, they are archived by setting `active = False` and `date_done` is populated. Since the activity dashboard query retrieves records via direct SQL, it bypasses Odoo's automatic active filtering on `mail.activity`. As a result, archived (done) activities were incorrectly fetched and displayed on the journal dashboard cards, appearing as overdue. This commit resolves the issue by explicitly adding `AND activity.active = TRUE` to the SQL queries. Task-6142042 Forward-Port-Of: odoo/odoo#276998 Forward-Port-Of: odoo/odoo#274313
The reversal wizard always injected a shared 'R4' onto every credit note it created, so a credit note of a simplified invoice never got the required 'R5', and reversing several invoices of mixed simplified status at once forced the same reason onto all of them. The wizard now derives the reason per original move ('R5' if it is simplified, 'R4' otherwise) instead of using one shared value, while still respecting an explicit manual choice. `l10n_es_is_simplified` already freezes correctly
Original PR description
The reversal wizard always injected a shared 'R4' onto every credit
note it created, so a credit note of a simplified invoice never got
the required 'R5', and reversing several invoices of mixed simplified
status at once forced the same reason onto all of them.
The wizard now derives the reason per original move ('R5' if it is
simplified, 'R4' otherwise) instead of using one shared value, while
still respecting an explicit manual choice. `l10n_es_is_simplified`
already freezes correctly on the credit note via its existing compute,
so no new compute is needed on `l10n_es_edi_verifactu_refund_reason`.
task-6358684
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#277394
Forward-Port-Of: odoo/odoo#276187Currently, overlays remain open when the POS screensaver is loaded [^1]. #### Steps to reproduce: - Open the POS interface. - Open a dropdown/popover menu (e.g., the navbar hamburger menu). - Wait for the screensaver (SaverScreen) to trigger due to inactivity. - The open dropdown menu remains visible on top of the screensaver. #### Issue Dropdowns and popovers are rendered as active overlays outside the main screen container. While the screensaver setup closes active dialogs, it doe
Original PR description
Currently, overlays remain open when the POS screensaver is loaded [^1]. #### Steps to reproduce: - Open the POS interface. - Open a dropdown/popover menu (e.g., the navbar hamburger menu). - Wait for the screensaver (SaverScreen) to trigger due to inactivity. - The open dropdown menu remains visible on top of the screensaver. #### Issue Dropdowns and popovers are rendered as active overlays outside the main screen container. While the screensaver setup closes active dialogs, it does not handle active overlays. #### Fix Retrieve the overlay service in SaverScreen and close all active overlays during its setup phase using a dedicated `closeAllOverlays` method. [^1]:  Forward-Port-Of: odoo/odoo#277055 Forward-Port-Of: odoo/odoo#274716
PR #247474 fixed an error where the lock date restriction was applied overzealously, restricting `stock.picking` models with a `scheduled_date` field before the lock date. This field does not affect accounting entries. The previous fix was to only check the `scheduled_date` field if the picking was in the `done` state. A more complete fix is to simply not check the `scheduled_date` field. opw-6311703 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-
Original PR description
PR #247474 fixed an error where the lock date restriction was applied overzealously, restricting `stock.picking` models with a `scheduled_date` field before the lock date. This field does not affect accounting entries. The previous fix was to only check the `scheduled_date` field if the picking was in the `done` state. A more complete fix is to simply not check the `scheduled_date` field. opw-6311703 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270875
Issue: In a multi-company environment, when an attachment is uploaded in the chatter, the resulting `ir.attachment` record incorrectly sets the company_id to the current user's default company. This occurs regardless of the active company or the company associated with the record the attachment is linked to. Steps to reproduce: In a multi-company setup, activate only Company B. Open any chatter and attach a file. Navigate to Settings > Technical > Data Structure > Attachments. Current b
Original PR description
Issue: In a multi-company environment, when an attachment is uploaded in the chatter, the resulting `ir.attachment` record incorrectly sets the company_id to the current user's default company. This…
Issue: In a multi-company environment, when an attachment is uploaded in the chatter, the resulting `ir.attachment` record incorrectly sets the company_id to the current user's default company. This occurs regardless of the active company or the company associated with the record the attachment is linked to. Steps to reproduce: In a multi-company setup, activate only Company B. Open any chatter and attach a file. Navigate to Settings > Technical > Data Structure > Attachments. Current behaviour: The created attachment has its company_id set to the user's default company, rather than the currently active company, or the company of the record, even when the record has a company_id field. This behavior introduces inconsistencies in data visibility, particularly when attachments appear to belong to a company different from the one associated with the related business record. Behaviour After Fix: If the related record (i.e., the model the attachment is linked to) contains a company_id field, its value will be used as the attachment's company_id otherwise, the attachment's company_id will be set to the currently active company's id. This logic ensures proper alignment between attachments and their related business records and also maintaining consistency in multi-company scenarios. task-4563173 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277582 Forward-Port-Of: odoo/odoo#235665