Daily updates from Odoo
Thursday, September 18, 2025
101 changes
9 changes
Resolved issues and error corrections
Pasted tables with a header row from tools like ChatGPT are now normalized so the editor can handle them correctly. This prevents crashes or selection problems when users edit or delete rows in those tables, improving reliability for content editing.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Copy a table from chatGPT's response containing first row wrapped in `<thead>`. - Paste it in editor. - Select last row. - Pressing backspace leads to traceback. This issue happens because the copied table is pasted with first row wrapped in a thead element. Due to this, rows are wrongly calculated leading to traceback in removeRow method. **Desired behavior after PR is merged:** - This commit ensures that if a table has first row wrapped inside a `thead`, the row is moved from `thead` to the start of `tbody` ensuring that rows are calculated correctly. - This commit also replaces all the `<th>` elements with `<td>`. task-5048339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226990 Forward-Port-Of: odoo/odoo#224784
When users create a mass mailing and change the target audience model, favorite templates now refresh to show the right options. This helps users find and reuse the correct saved templates more reliably.
Original PR description
In mass_mailing, when creating a new mailing, the theme selector allows users to select base templates for their mailings. Users can also add their own model-specific templates by marking mailings as "Favorite"s, which will cause them to show up in model selectors if the template's target model matches the new mailing's target model. However, in some circumstances, changing the target model does not cause the available template mailings to update. This is due to the callback responsible for updating the templates not reading the model variable correctly, causing useRecordObserver to not being called every time it is updated. This commit fixes this issue, therefore causing favorite templates to be updated more reliably. task-5054968 Forward-Port-Of: odoo/odoo#227424
The automatic cleanup process will now skip documents that are linked to signed document records, avoiding background deletion errors. This keeps the system stable while still preventing users from manually deleting protected signed documents.
Original PR description
Currently an error occurs when auto vacuum tries to clear documents linked to `sign_document`. **Steps to replicate:** * Install `documents_sign` with demo data. * Go to documents > Move Employment…
Currently an error occurs when auto vacuum tries to clear documents linked to `sign_document`. **Steps to replicate:** * Install `documents_sign` with demo data. * Go to documents > Move Employment contracts to trash * Trash > Try to to delete employment contract you will see error in terminal. Similarly error will be produced by the Auto-Vacuum process when it attempts to delete it after the configured deletion delay. **Error:** `ForeignKeyViolation: update or delete on table 'ir_attachment' violates foreign key constraint 'sign_document_attachment_id_fkey' on table 'sign_document' DETAIL: Key (id)=(1164) is still referenced from table 'sign_document'.` **Root cause:** * At [1], the `sign.document` model was introduced, which prevents the deletion of sign documents. As a result, attempting to delete them due to [2] will cause an error. **Solution:** * Update the `_get_gc_clear_bin_domain` to ensure that the Auto-Vacuum process skips sign documents. * This will still throw an Validation and ForeignKey error as expected when the user tries to delete it from the GUI letting them know it cannot be deleted. [1]: https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b#diff-deebbcccf829fd1804d145c5c7140b482801644bd948639f77caa310b18b8120 [2]: https://github.com/odoo/enterprise/blob/828d47f9ad1d5e396b074c404287799574a6d692/sign/models/sign_document.py#L44 sentry-6842360375 Forward-Port-Of: odoo/enterprise#93818
Changing a customer’s country could crash checkout when the same shopper had reward-enabled carts open on multiple websites. This fix lets Odoo update pricing and loyalty rewards across those carts correctly, avoiding an interruption to the shopping experience.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
Creating a new attendee record from eLearning reporting views no longer triggers an error. This prevents interruptions for users reviewing course attendees and keeps reporting workflows usable.
Original PR description
Currently an error occurs when creating the attendee records. Steps to Reproduce: - Install the `website_slide` module. - Go to `Reporting` > `Attendees`. - Go to either the `Graph or Pivot View` and…
Currently an error occurs when creating the attendee records. Steps to Reproduce: - Install the `website_slide` module. - Go to `Reporting` > `Attendees`. - Go to either the `Graph or Pivot View` and click on any `count` value. - Open any attendee record and click on `New`. `SyntaxError: syntax error at or near ")" LINE 18: WHERE SCP.id IN () ^` This error occurs when creating an Attendee record. The _compute_next_slide_id method runs every time the record is accessed, which causes the error [1]. As clearly mentioned in [this commit](https://github.com/odoo/odoo/commit/fd2fb88bb155b680147313433d22a2b7388c902c#diff-1ee3fce434db0c4e897973eebf5c1be501196cbd413e6c250ecc973238f939b9L292-R326), when a compute method is declared without the @api.depends(...) decorator or with no actual dependencies, the computed field will still be initialized when creating a new record from a form view. This commit ensures that when the compute method runs and the record has not been created yet, the next_slide_id is set to False. [1]:- https://github.com/odoo/odoo/blob/9f18013bc05e6657f5d41c05931fcdafad827d54/addons/website_slides/models/slide_channel.py#L91 sentry-6465821899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217104
Enabling the Can Create option in Studio for Website Live Chat channels no longer triggers an error. This improves reliability for teams customizing Live Chat views and prevents interruptions when configuring channel settings.
Original PR description
Currently, an error occurs when enabling `Can Create` in Studio for a Website Live Chat channels. **Steps to reproduce:** - Install the `im_livechat` and `web_studio` modules. - Go to `Live Chat`,…
Currently, an error occurs when enabling `Can Create` in Studio for a Website Live Chat channels. **Steps to reproduce:** - Install the `im_livechat` and `web_studio` modules. - Go to `Live Chat`, create a new channel, then return to the Live Chat channels view and open the newly created channel in kanban view. - Open `Studio` and enable `Can Create`. **Error:** ``` SyntaxError: syntax error at or near ')' LINE 12: WHERE discuss_channel.id IN () ``` **Root Cause:** At [1], an `SQL query` is executed with `self.ids`, when `self.ids` is `empty`, this leads to an `error`. **Fix:** This commit prevents the error by updating `_get_last_messages` to check for `empty self.ids` and return an empty recordset early and also updates `_compute_duration` to safely handle cases where `record.create_date` is `False`. [1]: https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/mail/models/discuss/discuss_channel.py#L1404-L1421 sentry-6861438710
Archived tasks opened through project sharing now show the same fields as they do in the standard project view. This prevents users from seeing the Recurrent option when it no longer applies, reducing confusion and keeping task details consistent.
Original PR description
**Steps to Reproduce:**
- Share a project.
- From the shared project, archive a task.
- Open the archived task in the standard project form view → the Recurrent field becomes invisible (as expected).
- Open the same archived task from the Project Sharing view by applying the Inactive/Archived filter → the Recurrent field is
still visible.
**Issue:**
The Recurrent field should not be visible for archived tasks. However, in the Project Sharing view, it still appears for inactive tasks.
**Current behaviour:**
The Recurrent field is hidden in the standard form view for archived tasks, but remains visible in the project sharing view.
**Expected behaviour:**
The Recurrent field should remain invisible in both the standard form view and the project sharing view when the task is archived.
**Fix:**
Adjusted the project sharing form view XML to apply the same invisible logic, ensuring the Recurrent field is hidden when the task is archived.
**Task-5040281**In Field Service task forms, the repeat interval is now shown directly under the planned date. This makes recurring task scheduling easier to find and keeps related planning details together.
Original PR description
**Steps to Reproduce:** 1. Open the Field Service app. 2. Create or open an existing task. 3. Check the form view of the task. **Issue:** - The 'Repeat Every' block was displayed at the bottom of the sheet, making it less intuitive. - It should logically appear under the 'Planned Date' block for better visibility. **Current behaviour:** - The 'Repeat Every' block appears in a different section, away from the 'Planned Date' block. **Expected behaviour:** - The 'Repeat Every' block should be displayed directly under the 'Planned Date' block for better usability and logical grouping. **Fix:** - Adjusted the form view XML to move the 'Repeat Every' field below the 'Planned Date' field. **Task-5040281**
This change prevents certain internal performance tests from failing when their timing results vary unpredictably. It helps keep automated checks reliable without affecting customer-facing features.
Original PR description
These tests are non-deterministic, we should not fail when running them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227515 Forward-Port-Of: odoo/odoo#226278
8 changes
Resolved issues and error corrections
Follow-up PDF reports now correctly include attachments stored as remote links or in cloud storage. This prevents report generation failures and helps users reliably produce customer follow-up documents regardless of where files are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The to_pdf_stream() method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports (enterprise): - account_followup.report_followup_print_all [Community PR](https://github.com/odoo/odoo/pull/226094) OPW-5036638 Forward-Port-Of: odoo/enterprise#94975 Forward-Port-Of: odoo/enterprise#94477
PDF report generation now downloads remote or cloud-stored attachments before including them. This prevents errors when printing vendor bills or expense sheets that reference files stored outside Odoo, improving reliability for businesses using cloud storage links.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments,…
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports - `account.report_original_vendor_bill` - Vendor bill reports - `hr_expense.report_expense_sheet` - Expense sheet reports ### Affected Versions - 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense) ### Reproduction Steps #### Option A: HR Expense Report 1. Create HR expense record 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to hr.expense record 4. Generate expense report → TypeError occurs #### Option B: Vendor Bill Report 1. Create vendor bill (account.move) 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to account.move record 4. Print Original Vendor Bill → TypeError occurs ### Error Details ```python TypeError: a bytes-like object is required, not 'bool' at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream from /odoo/addons/hr_expense/models/ir_actions_report.py:29 ``` #### Reference Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view OPW-5036638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227571 Forward-Port-Of: odoo/odoo#226094
Fixes an issue where tables pasted from sources like ChatGPT could cause the editor to crash or fail to select rows correctly. The editor now normalizes pasted table headers so users can edit and delete table rows reliably.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Copy a table from chatGPT's response containing first row wrapped in `<thead>`. - Paste it in editor. - Select last row. - Pressing backspace leads to traceback. This issue happens because the copied table is pasted with first row wrapped in a thead element. Due to this, rows are wrongly calculated leading to traceback in removeRow method. **Desired behavior after PR is merged:** - This commit ensures that if a table has first row wrapped inside a `thead`, the row is moved from `thead` to the start of `tbody` ensuring that rows are calculated correctly. - This commit also replaces all the `<th>` elements with `<td>`. task-5048339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226990 Forward-Port-Of: odoo/odoo#224784
This update prevents certain internal performance tests from failing when timing results vary unpredictably. It helps keep development and release checks stable without affecting customer-facing Odoo features.
Original PR description
These tests are non-deterministic, we should not fail when running them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227515 Forward-Port-Of: odoo/odoo#226278
This fix prevents an error when a customer has open carts on multiple eCommerce sites and their country change triggers different tax settings. Loyalty rewards are now recalculated separately for each cart, so customers can continue shopping without interruption.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
When creating a mass mailing, favorite templates now refresh correctly after users change the target audience or related model. This helps users see the right reusable templates at the right time, reducing confusion and manual work.
Original PR description
In mass_mailing, when creating a new mailing, the theme selector allows users to select base templates for their mailings. Users can also add their own model-specific templates by marking mailings as "Favorite"s, which will cause them to show up in model selectors if the template's target model matches the new mailing's target model. However, in some circumstances, changing the target model does not cause the available template mailings to update. This is due to the callback responsible for updating the templates not reading the model variable correctly, causing useRecordObserver to not being called every time it is updated. This commit fixes this issue, therefore causing favorite templates to be updated more reliably. task-5054968 Forward-Port-Of: odoo/odoo#227424
Creating a new attendee record from reporting views no longer triggers an error in the eLearning app. This prevents an unexpected crash and keeps attendee management workflows usable for staff.
Original PR description
Currently an error occurs when creating the attendee records. Steps to Reproduce: - Install the `website_slide` module. - Go to `Reporting` > `Attendees`. - Go to either the `Graph or Pivot View` and…
Currently an error occurs when creating the attendee records. Steps to Reproduce: - Install the `website_slide` module. - Go to `Reporting` > `Attendees`. - Go to either the `Graph or Pivot View` and click on any `count` value. - Open any attendee record and click on `New`. `SyntaxError: syntax error at or near ")" LINE 18: WHERE SCP.id IN () ^` This error occurs when creating an Attendee record. The _compute_next_slide_id method runs every time the record is accessed, which causes the error [1]. As clearly mentioned in [this commit](https://github.com/odoo/odoo/commit/fd2fb88bb155b680147313433d22a2b7388c902c#diff-1ee3fce434db0c4e897973eebf5c1be501196cbd413e6c250ecc973238f939b9L292-R326), when a compute method is declared without the @api.depends(...) decorator or with no actual dependencies, the computed field will still be initialized when creating a new record from a form view. This commit ensures that when the compute method runs and the record has not been created yet, the next_slide_id is set to False. [1]:- https://github.com/odoo/odoo/blob/9f18013bc05e6657f5d41c05931fcdafad827d54/addons/website_slides/models/slide_channel.py#L91 sentry-6465821899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217104
The calendar year view now updates properly when the browser window is resized. This prevents display issues for users viewing yearly calendars and keeps the layout responsive without extra processing.
Original PR description
FullCalendar already applies a debounce on the `windowResize` handler. Thus, doing it again in our renderer is a duplicated effort. Also, in the Year calendar renderer, the debounced version of the handler is initialized after the FullCalendar instances (one for each month) are created... which prevents it from being run at all. This commit fixes and cleans this up by directly passing our handler to FullCalendar, letting him do the rest. task-4809668 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227505 Forward-Port-Of: odoo/odoo#227458
2 changes
Resolved issues and error corrections
This update fixes a failing automated test related to Hong Kong payroll leave generation after a prior system change. It helps keep payroll quality checks reliable and reduces the risk of future payroll regressions reaching users.
Original PR description
Explanation: _generate_leave method is updated in saas-18.1. build_error-229902
Payroll users with Administrator access can now cancel completed payslips as intended. This prevents unnecessary errors and lets payroll teams manage corrections without needing full system administrator rights.
Original PR description
steps to reproduce: ------------------- 1. Install payroll 2. Create a user and grant "Administrator" access to Payroll. 3. Log in as the new user and try to cancel a 'Done' payslip. issue: ------ A UserError is raised: "Cannot cancel a payslip that is done." observation: ------------ A user with Payroll "Administrator" access is unable to cancel a payroll payslip cause of the issue: ------------------- During cancellation, the system checks whether the user is "Admin" instead of verifying if the user has Payroll "Administrator" access. https://github.com/odoo/enterprise/blob/13832d80570956e504e1c09f41acbeb0bc4baedc/hr_payroll/models/hr_payslip.py#L509-L513 solution: ---------- Check that the user has Payroll "Administrator" access. opw-5040029 Forward-Port-Of: odoo/enterprise#93831
12 changes
Resolved issues and error corrections
This update fixes an issue in Odoo Sign where users could not drag fields after uploading multiple documents. Teams can now prepare signing packets with several documents more smoothly, without field placement getting blocked.
Original PR description
Version: - saas-18.3 Steps to reproduce: - install sign - upload multiple documents - try to drag the field Issue: - Fields cannot be dragged when multiple documents are uploaded. Solution: - update the condition to check if !acive then return no need to preventdefault. Impact: - Users can now upload multiple documents and drag/drop fields without issues. Forward-Port-Of: odoo/enterprise#94959 Forward-Port-Of: odoo/enterprise#94882
Uploading documents to the Sign app now uses a PDF form-reading method compatible with newer PDF software. This prevents crashes during sign template creation and helps users continue preparing documents reliably.
Original PR description
### Issue: - The `getFields` method is not supported in the PyPDF version 3.x. - This caused an `AttributeError` when uploading a document for sign. ### Fix: - Replaced `getFields` method with `getFormTextFields`. This is more compatible than the earlier one ### Impact: - Prevents template creation crashes Forward-Port-Of: odoo/enterprise#95005
Spreadsheet pivots now hide fields that cannot be safely used for grouping when any part of the selected field path is not groupable. This helps users avoid setting up pivot dimensions that would later fail when the system tries to run the query.
Original PR description
A pivot cannot be grouped in a dimension if some link of the field chain is not groupable. This revision removes the special passthrough for o2m and m2o fields as the final query will still be rejected by the server. task-5095342 Forward-Port-Of: odoo/enterprise#95006
This update prevents salary configurator test flows from failing when only the base salary contract app is installed. Belgian-specific fields are now handled in the Belgian payroll module where they belong, keeping the base flow reliable across installations.
Original PR description
`l10n_be_hr_contract_salary` adds a bunch of fields to the salary configurator (by way of new hr.contract.salary.personal.info records). These fields can not be filled in `hr_contract_salary` as they are not present there, thus if the employee flow tour is run with just `hr_contract_salary` installed it fails as soon as it tries to fill one of these additional fields. Move the filling of the fields to `l10n_be_hr_contract_salary` extending the base tour (technically it might be possible to move just the lang and remove the rest since that's the only required field). https://runbot.odoo.com/odoo/error/232583 Forward-Port-Of: odoo/enterprise#94955 Forward-Port-Of: odoo/enterprise#94792
A Swiss payroll test was updated to stop using a field that is no longer supported. This helps keep automated checks reliable and reduces the risk of delays when maintaining payroll functionality.
Original PR description
The CH contract template whitelist test referenced `overtime_from_attendance` when creating a Version. task-5095572 Forward-Port-Of: odoo/enterprise#95034
This fixes the naming used for the bottom sheet’s dark mode styling in the web enterprise interface. It helps ensure the dark mode appearance is applied consistently, reducing small visual glitches for users.
Original PR description
task-5087158 Requires: - https://github.com/odoo/odoo/pull/227628 Forward-Port-Of: odoo/enterprise#95001
Fixed project template conversion so tasks correctly keep their template status. This prevents template tasks from being treated like regular field service work, ensuring project roles are only configured on normal tasks.
Original PR description
This feature was supposed to be introduced in 19 but got lost with the reversal of the templates refactor. When converting a project to a template, the tasks should retain their template status. Task templates in project templates are treated the same as task templates in normal projects. Project roles should be configured only on normal tasks and not on task templates. Task-5087632 Forward-Port-Of: odoo/enterprise#94849
This fixes an issue where settling a point-of-sale order for rental services could incorrectly reset delivered quantities and block valid returns. Rental service delivery quantities are now left for sales staff to manage manually, reducing errors during POS checkout and rental returns.
Original PR description
With [^1], a new constraint was introduced on sale order lines in rental to ensure the returned quantity does not exceed the delivered quantity. While this constraint is logical, it uncovered a bug…
With [^1], a new constraint was introduced on sale order lines in rental
to ensure the returned quantity does not exceed the delivered quantity.
While this constraint is logical, it uncovered a bug in the integration
between rental, POS, and stock. Specifically, when a POS order is
settled, the `pos.order.sync_from_ui` method reconciles the models.
If the rented product is a service, no picking is created, which means
no stock move, resetting the delivered quantity to zero. This triggers a
constraint violation if a returned quantity already exists (e.g., 0 >=
positive).
This commit applies the following fixes:
- If the SOL product is a service, we do not update its delivered
quantity as it is managed manually by the salesperson on the SOL
directly.
- Additionally, we remove the constraint to allow more flexibility.
opw-5076638
[^1]: https://github.com/odoo/enterprise/pull/88689
[^2]: https://github.com/odoo/enterprise/pull/90510
Forward-Port-Of: odoo/enterprise#94357This fix adds extra spacing around the mail search bar in dark mode so it no longer appears too close to the header. The change improves visual clarity and makes the interface feel more polished without affecting functionality.
Original PR description
Before this PR, the search bar was too close to the header bar, now padding has been added only in dark mode. Community: https://github.com/odoo/odoo/pull/227647 task-5092001 | Bafore | After | |--------|--------| | <img width="440" height="673" alt="Screenshot 2025-09-17 at 11 20 28" src="https://github.com/user-attachments/assets/000b2cb7-bace-4995-a58c-197f05185a99" /> | <img width="440" height="673" alt="Screenshot 2025-09-17 at 11 20 09" src="https://github.com/user-attachments/assets/bb5a0114-9e33-427d-a17d-66fb95f702ba" /> | Forward-Port-Of: odoo/enterprise#95004
This update fixes several small issues in accounting audits and reports, including opening aged receivable checks correctly, keeping audit scroll position, and using the right reporting period. It also improves audit usability by allowing audit names to be edited, showing the last message in balance views, and making duplicated labels more consistent.
Original PR description
- Removed " from the description of the age receivable followup check template - Age receivable checks can now be openned (before it said Invalid code) - Fix Account Status Badge colors not present on reports - Keep the scroll position on audit checks (Cycle) - Remove dead code _get_state_field in l10n_in_reports - Use the right period when opening a report from a check in an audit - Adding (copy) when duplicating a return type - Add the possibility to edit the name of the Audits - Add the last message column in the balance list view of the audit - Allow only the audit and use the right view when opening the returns from the accounting dashboard - Using copy instead of Copy when duplicating taxes Forward-Port-Of: odoo/enterprise#94806
Bank reconciliation can now match payments using shorter sales order references such as SO0001. This helps businesses reconcile bank transactions more reliably without waiting for longer reference numbers.
Original PR description
Matching on references was limited to matching words > 8, to increase reliability, but the default sequence for sale orders is 6 characters (SO0001), so they would never be found unless we reach SO1000000 -_- Forward-Port-Of: odoo/enterprise#94821 Forward-Port-Of: odoo/enterprise#93640
Canadian CPA005 payment files now use the batch payment name as the originator cross-reference, helping ensure each payment in a batch has a unique identifier. This prevents files from being rejected by banks such as CIBC and RBC when references are blank or duplicated.
Original PR description
… Reference No is blank on non-unique CPA0005 Alphanumeric Originator's Cross Reference No is blank on non-unique Impacted versions: 17.2 17.3 17.4 18.0 18.1 18.2 18.3 18.4 master Steps to reproduce: create a new batch payment create cpa005 payment file rejected by CIBC and RBC Current behavior: Uses payment_reference which is blank or non-unique Causes bank to reject on non-unique status Expected behavior: To have every batch payment reference (name of payment) be unique through the batch
61 changes
Resolved issues and error corrections
This fix removes an unnecessary test dependency from point of sale tour utilities. It helps keep automated checks more stable and easier to maintain without changing the customer-facing point of sale experience.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Malaysian EDI identity card placeholder was updated to remove hyphens, matching how these numbers are typically entered in ERP systems. This helps prevent user confusion and avoids validation failures with IAP and MyInvois services.
Original PR description
Hyphens are generally omitted in ERPs, and just shown on the Identity card. Putting hyphens in the placeholder is actually misleading for users, and prevents validation through the IAP server and MyInvois Ref: https://en.wikipedia.org/wiki/Malaysian_identity_card#Structure_of_the_National_Registration_Identity_Card_Number_(NRIC) Task [link](https://www.odoo.com/odoo/project/967/tasks/5054821) task-5054821 Forward-Port-Of: odoo/odoo#225094
Several help and documentation links across Odoo Enterprise have been updated so they direct users to the correct 19.0 documentation instead of older 18.0 pages. This reduces confusion and helps users find guidance that matches their current software version.
Original PR description
Community PR https://github.com/odoo/odoo/pull/227546.
This update corrects many documentation links so they lead to the appropriate Odoo 19.0 documentation instead of older 18.0 pages. This helps users and implementers find accurate guidance for the version they are using, reducing confusion and support friction.
Original PR description
Before this commit, many of the url is pointing to 18.0. After this commit, the url will point to 19.0 documentation link. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes payroll localisation test failures by ensuring an attendance-related overtime field is only added where the relevant attendance module is available. This helps keep payroll localisation validation reliable across countries without changing day-to-day payroll features.
Original PR description
**Issue:**
The test_{xx}_contract_template_loading test fails across all localisations due to incorrect fields being passed.
**Cause:**
The issue occurs because the _get_whitelist_fields_from_template() method includes the overtime_from_attendance field, introduced in this https://github.com/odoo/enterprise/pull/92093. This field comes from the hr_work_entry_attendance module, which is not listed as a dependency in all payroll localisations. As a result, the field cannot be found during test execution.
**Solution:**
Remove the overtime_from_attendance field from all _get_whitelist_fields_from_template overrides in the localisation modules, and instead include this field by overriding the function in the hr_work_entry_attendance module.
build_error-231680
Forward-Port-Of: odoo/enterprise#94004When a payment memo is edited, the related accounting entry reference is now updated to match. This keeps payment and accounting records consistent, reducing confusion during reconciliation and review.
Original PR description
Issue: In previous versions, the memo field of account payments and ref field of account move were related Now that payments do not required to have generated account move's when the memo is updated the ref remains unchanged. Purpose of this PR: To update the account move ref when the payment memo is updated. Steps to Reproduce on Runbot: install accounting go to bank account and assign outstanding accounts for manual payment methods create a payment -- a related account move should be created update the memo on the payment -- the ref on the related account move is unchanged. opw-4989260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226168 Forward-Port-Of: odoo/odoo#223459
Fixed project template conversion so task templates keep their intended template status. This helps field service teams use project templates consistently while ensuring project roles are only set on regular tasks, reducing setup errors.
Original PR description
This feature was supposed to be introduced in 19 but got lost with the reversal of the templates refactor. When converting a project to a template, the tasks should retain their template status. Task templates in project templates are treated the same as task templates in normal projects. Project roles should be configured only on normal tasks and not on task templates. Task-5087632
Fixes project templates so normal tasks and task templates are shown and handled correctly after a project is converted into a template. This prevents template-related filters from hiding regular tasks and ensures project roles are only configured on normal tasks, reducing confusion for users managing reusable project setups.
Original PR description
This feature was supposed to be introduced in 19 but got lost with [the reversal](https://github.com/odoo/odoo/pull/225953) of [the templates refactor](https://github.com/odoo/odoo/pull/220311). When converting a project to a template, the tasks should retain their template status. Task templates in project templates are treated the same as task templates in normal projects. Project roles should be configured only on normal tasks and not on task templates. Task-5087632
Uploading documents for Sign could fail when the system used a newer PDF library version. This change updates the PDF field-reading approach so users can create Sign templates without crashes.
Original PR description
### Issue: - The `getFields` method is not supported in the PyPDF version 3.x. - This caused an `AttributeError` when uploading a document for sign. ### Fix: - Replaced `getFields` method with `getFormTextFields`. This is more compatible than the earlier one ### Impact: - Prevents template creation crashes
The test suite now uses UTC for domain tests so results are not affected by the server or administrator timezone. This helps keep automated checks consistent across environments and reduces false test failures.
Original PR description
When testing with demo user, the timezone is in the installed localtime for the administrator user. For the tests, force it to UTC. runbot-error-230424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Dialogs such as camera or microphone permission prompts now remain visible when users join a meeting. This prevents confusion and helps users complete required confirmations without leaving the call view.
Original PR description
The meeting view allows focusing on an ongoing call, removing any distraction with a full screen call view. To do so, the overlay service is used, and the call view takes the whole screen. However, other components, such as confirmation dialogs also use the overlay service. As a result, dialogs are sometimes hidden behind the meeting view. This commit ensures the meeting view won't hide other overlays by reducing it's z-index. Steps to reproduce: - Reset your mic/camera permission. - Start a meeting. - The call permission dialog is hidden by the meeting view. task-5095114
Subscription invoices that include combo products can now be created and confirmed without triggering validation errors. This prevents failed manual invoices and automatic payment processing for affected subscription orders.
Original PR description
Currently, an error is produced while creating an invoice for a subscription order with combo products, and it can be triggered in two different ways. 1. Directly create an invoice. - Create and…
Currently, an error is produced while creating an invoice for a subscription order
with combo products, and it can be triggered in two different ways.
1. Directly create an invoice.
- Create and confirm a subscription with a combo product.
- Create an invoice for this subscription and try to confirm it.
- Validation error shown in display and error generated in log
2. When cron "Payment: Post-process transactions" trigger:
- Enable the Automatic Invoice option in the Subscription settings.
- Activate a demo payment provider (e.g. Demo: Payment Provider).
- Create and confirm a subscription that includes a combo product.
- Click on "Pay" to process the subscription payment.
- An error occurs when the above-mentioned cron is triggered, and it
tries to create an invoice for a subscription order.
Error: `new row for relation "account_move_line" violates check constraint
"account_move_line_check_accountable_....`
This issue arises during the creation of an account move line for deferred entries for
the 'Combo Product' column of the original invoice (subscription):
- At [1], `deferred_start_date` and `deferred_end_date` were added to all invoice line values within `_prepare_invoice_line` used to create the original invoice
- Then, at [2], during confirmation of the `original invoice`, the code attempts to generate `deferred entries` for for move where any move lines that has a `deferred_start_date`
- At code line [3], during the generation of deferred entries, an account move line is created without an associated `account_id`
- During `display_type` computation at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L480-L484), `line.move_id.is_invoice()` evaluates to `False`. As a result, the line is assigned a `display_type` as a 'product'.
- Since `display_type` is 'product' and `account_id` is missing, it violates the following check constraint at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L451): `CHECK(display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL)`
This commit fixes the issue by preventing the addition of the `deferred_start_date` and `deferred_end_date` keys for invoice lines whose corresponding sale order lines have products of type 'combo' at [1].
[1]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/sale_subscription/models/sale_order_line.py#L448-L449
[2]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L113-L114
[3]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L309
sentry-6763423503
Forward-Port-Of: odoo/enterprise#90989Fixes an error that occurred when users grouped stock locations while inventory valuation features were installed. This prevents an unexpected crash and lets users analyze locations normally.
Original PR description
Steps to reproduce: - Have `stock_account` module installed - Navigate to stock locations - Group by location Problem: Traceback "ValueError: Cannot convert stock.quant.value to SQL because it is not stored" --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Projects created from sales orders now automatically enable milestones when any ordered product is billed by milestone. This prevents sales and project teams from having to manually correct project settings and supports accurate milestone-based invoicing.
Original PR description
This commit fixes two issues related to the milestones settings of generated projects in SO: First issue: * Steps to reproduce: - Create a product whose invoicing is based on milestones - Add this…
This commit fixes two issues related to the milestones settings of generated projects in SO:
First issue:
* Steps to reproduce:
- Create a product whose invoicing is based on milestones
- Add this product to an SO
- Confirm the SO
- Create a project from the action button in the SO form view ('Create a Project'), with or without a project template
- The generated project does not have the milestone setting enabled
* Expected behavior:
=> When creating a project from the SO in which there is at least 1 product with invoicing based in milestone, the setting "Milestone" should be checked by default
Second issue:
* Steps to reproduce:
- Create a product with an invoice policy based on milestones
- Create another product with another policy
=> Both products must be configured to create a project on SO confirmation, without a project template
- Create a new SO with both products as SOLs
=> Set the second product (other policy) in first sequence, then the first product (milestones based) in second sequence, as the order of SOLs
- Confirm the SO
- The generated project does not have the milestone setting enabled
* Expected behavior:
=> The generated project should have the milestone setting enabled, as at least one product with an invoicing policy based on milestones has triggered the generation of that project
task-5090253
version: 19.0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe inventory action to set quantities to zero now works consistently from the forecasted report as well as the physical inventory menu. This helps users correct stock quantities faster and reduces inconsistent inventory handling depending on where the action is used.
Original PR description
The action "Set to 0" was working only via the "Physical inventory" menu and not via the list quants from the forecasted report. This commit makes sure the quant is set to 0 and autoapply the new quantity based on the context (either the "apply" button is present or not Task : 5064269 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When items from a receipt are moved into a new wave transfer, their related quality checks are now moved or recreated on the correct transfer. This prevents staff from missing required quality checks or completing them from the wrong receipt, improving accuracy in warehouse quality control.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Enterprise: https://github.com/odoo/enterprise/pull/92951
opw-5009635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224947
Forward-Port-Of: odoo/odoo#223852The website payment methods snippet now uses standard browser caching instead of storing data in the visitor session. This lets administrators see payment method changes after reloading while regular customers still benefit from faster page loading through a 7-day cache.
Original PR description
The "Supported Payment Methods" snippet introduced in [^1] was designed to cache payment methods to minimize server calls. However, this cache was stored in session storage, meaning it wasn't…
The "Supported Payment Methods" snippet introduced in [^1] was designed to cache payment methods to minimize server calls. However, this cache was stored in session storage, meaning it wasn't invalidated on page reloads. While this behavior worked well for regular customers, it was problematic for admins who needed to see backend changes reflected immediately upon reloading the page. This commit shifts the caching logic to rely on the HTTP caching mechanism. This change eliminates a significant amount of frontend code and centralizes the logic in the backend. The new approach disables caching for logged-in internal users while enforcing caching for regular customers visiting the website. Since payment methods are not expected to change frequently, a 7-day cache policy is enforced. After this period, the client must revalidate with the server, ensuring any inconsistencies are resolved in a timely manner. Additionally, a safeguard has been added to the snippet to prevent warnings in the console. task-2889752 [^1]: https://github.com/odoo/odoo/pull/213234
The spreadsheet pivot editor now filters out fields that cannot be used for grouping before users select them. This avoids configurations that would later fail on the server, making pivot setup more reliable.
Original PR description
A pivot cannot be grouped in a dimension if some link of the field chain is not groupable. This revision removes the special passthrough for o2m and m2o fields as the final query will still be rejected by the server. task-5095342
Users can now apply vertical alignment to table cells in the website editor without the formatting menu closing too soon. This makes table formatting more reliable when editing website content.
Original PR description
### Steps to reproduce: - Navigate to the Website module. - Drag and drop a Text Snippet. - Create a Table (e.g., /table) and select a table cell. - Click on Vertical Align button in toolbar and apply alignment option. ### Description of the issue/feature this PR addresses: - When clicking on a vertical align option inside the dropdown, overlay was immediately closed. Because of this, the click event handler was not triggered, and the selected vertical alignment was not applied to the table cell. ### Desired behavior after PR is merged: - Prevent overlay from closing by using `data-prevent-closing-overlay`. task-5062814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225470
The Discuss search bar now has extra spacing from the header, making the interface look cleaner and easier to use. This is a small visual fix that improves readability and polish without changing functionality.
Original PR description
Before this commit, the search bar was too close to the header bar, now padding has been added. Enterprise: https://github.com/odoo/enterprise/pull/95004 task-5092001 | Before | After | |--------|--------| | <img width="440" height="673" alt="Screenshot 2025-09-17 at 11 19 41" src="https://github.com/user-attachments/assets/226c48ff-a6cf-4e13-9f91-7b2fcfa8f92f" /> | <img width="440" height="673" alt="Screenshot 2025-09-17 at 11 19 31" src="https://github.com/user-attachments/assets/2b0b8034-6dff-4717-92fc-322b69a5c2ca" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When receipt items are moved into a new wave or picking, their related quality checks are now moved or recreated on the correct transfer. This prevents teams from missing quality checks on the new transfer or processing checks from the wrong receipt.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Community: https://github.com/odoo/odoo/pull/223852
opw-5009635
Forward-Port-Of: odoo/enterprise#93995
Forward-Port-Of: odoo/enterprise#92951Users can now mark unread notifications as read directly from the messaging menu, including when clicking the check icon. This prevents accidental opening of the related record and makes notification handling work as expected.
Original PR description
Steps to reproduce: * Open the messaging menu from the systray with an unread notification. * Hover on a notification item. * Click on the `mark as read` button (check icon). The notification is not marked as read. Instead, the related record is opened. In [1] UI changes introduced to avoid flickering in the messaging menu modified the structure of the `mark as read` button. Because the click handler only checked if the clicked element exactly matched the button reference, clicks on the inner icon were ignored and triggered the record opening instead. This commit adjusts the button so that clicks are correctly detected even when they occur on the icon. [1]: https://github.com/odoo/odoo/pull/226531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The stock app now hides the 'Move a Pack' button when package tracking is not enabled. This prevents users from seeing an action that should only be available when packages are configured, reducing confusion in warehouse operations.
Original PR description
As the button is added though an override of the ListRenderer, there was no check on the group made on the button, meaning that even if the 'Packages' setting wasn't activated, the button would still appear. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The replenishment action now works even when buying or manufacturing routes are set on the warehouse instead of directly on the product. This lets users replenish products from the forecast report again and choose valid buy or manufacture options when suppliers or bills of materials are available.
Original PR description
Steps to reproduce: - Create a product - Open the forecast report - Click "Replenish" Issue: Cannot replenish as now by default the buy/manufacture routes are set on the warehouse and no longer on the product itself We can simply remove the check on the route in the wizard, as now the procurement is smarter and can find the appropriate rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The messaging search bar now has extra spacing from the header when dark mode is enabled. This small visual fix makes the interface look cleaner and easier to use without affecting other display modes.
Original PR description
Before this PR, the search bar was too close to the header bar, now padding has been added only in dark mode. Community: https://github.com/odoo/odoo/pull/227647 task-5092001 | Bafore | After | |--------|--------| | <img width="440" height="673" alt="Screenshot 2025-09-17 at 11 20 28" src="https://github.com/user-attachments/assets/000b2cb7-bace-4995-a58c-197f05185a99" /> | <img width="440" height="673" alt="Screenshot 2025-09-17 at 11 20 09" src="https://github.com/user-attachments/assets/bb5a0114-9e33-427d-a17d-66fb95f702ba" /> |
Custom mailing templates are once again limited to new mailings for the same target type they were created from. This prevents users from accidentally selecting an unsuitable template and helps keep mailing setup consistent.
Original PR description
Previously, custom mailing templates (which could be created by marking an existing mailing as Favorite) would only be accessible for new mailings matching the template's target model. This restriction was lost by the update to the new mailing editor; this commit restores it. task-5054968
This update standardizes the wording shown when duplicating accounting records, changing the label to match the style used elsewhere in accounting. It helps provide a more consistent user experience with no expected change to business processes.
Original PR description
For coherence with other models in accounting. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error in the mail module when invalid empty values are included while looking up mail records. It improves reliability by ignoring those empty values before processing, reducing the chance of unexpected failures.
Original PR description
Browse breaks when given a bool, so the solution is to filter the list from false values before browsing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225916
Website editors no longer see duplicate background controls when adding scroll effects to category showcase blocks. This makes editing ecommerce category sections clearer and avoids confusion in the website builder.
Original PR description
Applying a scroll effect on a block from the categories showcase snippets triggers the parallax plugin, which converts the block into .parallax and adds a .s_parallax_bg child. But both global and snippet-local background option registrations then target the same block, resulting in duplicated controls in the builder. This commit fixes this by removing the snippet's custom WebsiteBackgroundOption registration entirely and adding .s_ecomm_categories_showcase_block to the global background selector. task-5076305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves several accounting audit and reporting workflows, including opening aged receivable checks correctly, preserving audit scroll position, and showing clearer audit balance information. It also tidies duplicate naming and dashboard filtering so users see the right records and more consistent labels.
Original PR description
- Removed " from the description of the age receivable followup check template - Age receivable checks can now be openned (before it said Invalid code) - Fix Account Status Badge colors not present on reports - Keep the scroll position on audit checks (Cycle) - Remove dead code _get_state_field in l10n_in_reports - Use the right period when opening a report from a check in an audit - Adding (copy) when duplicating a return type - Add the possibility to edit the name of the Audits - Add the last message column in the balance list view of the audit - Allow only the audit and use the right view when opening the returns from the accounting dashboard - Using copy instead of Copy when duplicating taxes
The product showcase design now uses a stronger overlay so product presentation remains clearly visible, even at the highest overlay setting. This improves the shopping page appearance and makes showcased products easier for visitors to view.
Original PR description
This commit adjusts the overlay of the Showcase product design, as it was too light and not visible enough, even when set to its maximum value. task-5090301 | Before | After | |--------|--------| | <img width="1387" height="793" alt="Capture d’écran 2025-09-17 à 15 27 49" src="https://github.com/user-attachments/assets/616e635b-d7ae-4d9a-b6a6-6807e7b68b4d" /> | <img width="1370" height="788" alt="Capture d’écran 2025-09-17 à 15 29 05" src="https://github.com/user-attachments/assets/094e00c2-6658-4d8b-a57d-a909ade08ca4" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes inventory valuation reporting so date-based values and average-cost products are handled correctly, even when some category settings are incomplete. It also makes it easier to backdate stock movements from the list view, helping businesses keep stock and accounting records aligned.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now recognizes Ecuadorian vendor invoice XML files downloaded from the SRI even when the invoice is wrapped inside a CDATA section. This allows vendor bill uploads to populate the bill details correctly, reducing manual entry and upload failures for Ecuadorian companies.
Original PR description
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill…
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill the vendor bill form view. #### Steps to reproduce: - Install "l10n_ec_edi" and switch to an Ecuadorian company - Have a file downloaded from the SRI. - Go to Accounting > Vendor > Bills - Click "Upload" and select the file - The generated move is not populated with the data ### Cause: We are expecting the XML to not be in the tag `CDATA` and it gets ignored. ### Solution: The change is in `_get_import_file_type` to detect the new type of file as `'l10n_ec.factura'`. The CDATA content can be fetched by getting the content of the tag `comprobante`. We then try to convert the content of `comprobante` to XML. If it's possible, we have an XML on which we can do the same check as before to know if it's an Ecuadorian invoice. We then replace the `file_data['xml_tree']` by the content of `CDATA` to have the correct XML for the data extraction. opw-5004636 Forward-Port-Of: odoo/enterprise#94184
This fix makes selecting and clicking icon-based website snippets behave more predictably. It prevents unwanted text highlighting, toolbar behavior, and editing errors around social media, sharing, and rating snippets, helping website editors avoid confusing interactions.
Original PR description
task-5066301
This update fixes urgent issues in subcontracting workflows, especially around purchase receipts, production orders, serial or lot generation, and subcontractor resupply. It helps prevent duplicate or incorrect resupply transfers, ghost manufacturing orders, and confusing subcontracting screens, making fulfillment more reliable for businesses using subcontracted manufacturing.
Original PR description
This PR fixes some urgent bugs in the new subcontracting introduced in [1]. Please refer to the individual commits for details. [1] https://github.com/odoo/odoo/pull/218377 task-5072277 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors can now replace background images in Banner Categories blocks directly from the editor. This fixes a missing media replacement option, making it easier to customize website catalog visuals without workarounds.
Original PR description
Steps to reproduce: 1. Go to Website > Edit Mode. 2. Add a _Banner Categories_ snippet from catalog. 3. Click on the image of a category (e.g., sofas, drawers, or desks) to replace it. 4. Notice that there is no Replace Media button. Issue: The _Banner Categories_ snippet does not contain a selector that triggers the Replace Media option. Reason: Since the snippet lacked a dedicated selector for its background images, the system could not detect or offer the replacement option. Fix: Added a generic selector named o_background_image to both the Banner Categories snippet and the Replace media options. Because it is a generic selector, it can also be reused in other snippets.
This fix adds the missing 'SZJ' product code required by Hungary's official NAV XML invoicing specification. It helps ensure Hungarian electronic invoices can use all officially supported product code types, reducing compliance issues for affected businesses.
Original PR description
Description of the issue/feature this PR addresses: In the official NAV XML 3.0 documentation (available at: https://onlineszamla.nav.gov.hu/dokumentaciok page 123), according to the list of possible product codes, there is an 'SZJ' code that is missing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226213
Vendor bill and expense sheet PDF reports can now include attachments stored as remote links or in cloud storage. This prevents report generation failures and helps users reliably print reports regardless of where supporting documents are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments,…
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports - `account.report_original_vendor_bill` - Vendor bill reports - `hr_expense.report_expense_sheet` - Expense sheet reports ### Affected Versions - 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense) ### Reproduction Steps #### Option A: HR Expense Report 1. Create HR expense record 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to hr.expense record 4. Generate expense report → TypeError occurs #### Option B: Vendor Bill Report 1. Create vendor bill (account.move) 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to account.move record 4. Print Original Vendor Bill → TypeError occurs ### Error Details ```python TypeError: a bytes-like object is required, not 'bool' at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream from /odoo/addons/hr_expense/models/ir_actions_report.py:29 ``` #### Reference Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view OPW-5036638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227571 Forward-Port-Of: odoo/odoo#226094
Follow-up PDF reports now work when attached files are stored as remote links or in cloud storage. This prevents report failures and helps users reliably generate customer follow-up documents regardless of where attachments are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The to_pdf_stream() method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports (enterprise): - account_followup.report_followup_print_all [Community PR](https://github.com/odoo/odoo/pull/226094) OPW-5036638 Forward-Port-Of: odoo/enterprise#94975 Forward-Port-Of: odoo/enterprise#94477
This fixes an issue where already-used serial numbers could reappear when adding delivery lines after deleting suggested lines. Warehouse users will now see the correct available serial numbers, reducing picking mistakes and inventory inconsistencies.
Original PR description
Steps to reproduce the bug: Create a storable product “P” tracked by serial number Create a receipt for 100 units with serial numbers sn.001 to sn.100 Create a delivery for 10 units, Odoo assigns serial numbers from sn.001 to sn.010, Validate Create a delivery for 3 units, Odoo assigns serial numbers from sn.011 to sn.013, Delete the 3 move lines, Add a line: you will see again the serial numbers sn.001 to sn.010 in the list Origin: This pr : https://github.com/odoo/odoo/pull/216035 removed the 'on_hand' & 'in_stock' without removing their uses (search_default_*) Fix: Ensure a correct domain when adding a line. opw-5075144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Long values in editable Many2one fields are now shortened with a visible ellipsis instead of causing layout misalignment. This keeps employee form fields, such as private state information, visually aligned and easier to read.
Original PR description
The text-truncate bootstrap class of the m2o field does not work properly as the ellipsis is not visible and create an alignment issue with the private_state_id field. This PR solves this issue which can be seen in the "Private information" tab of the employee form. Task-5078736 Forward-Port-Of: odoo/odoo#226214
Fixed an issue where previously used serial numbers could reappear when adding delivery lines after deleting automatically assigned lines. This helps warehouse users select only valid available stock, reducing picking mistakes and inventory inconsistencies.
Original PR description
Steps to reproduce the bug: Create a storable product “P” tracked by serial number Create a receipt for 100 units with serial numbers sn.001 to sn.100 Create a delivery for 10 units, Odoo assigns serial numbers from sn.001 to sn.010, Validate Create a delivery for 3 units, Odoo assigns serial numbers from sn.011 to sn.013, Delete the 3 move lines, Add a line: you will see again the serial numbers sn.001 to sn.010 in the list Origin: This pr : https://github.com/odoo/odoo/pull/216035 removed the 'on_hand' & 'in_stock' without removing their uses (search_default_*) Fix: Ensure a correct domain when adding a line. opw-5075144
This change prevents rental service products sold through POS from incorrectly resetting delivered quantities when no stock movement exists. It avoids blocking order settlement or returns in cases where salespeople manage service delivery manually, improving reliability for rental workflows.
Original PR description
With [^1], a new constraint was introduced on sale order lines in rental
to ensure the returned quantity does not exceed the delivered quantity.
While this constraint is logical, it uncovered a bug in the integration
between rental, POS, and stock. Specifically, when a POS order is
settled, the `pos.order.sync_from_ui` method reconciles the models.
If the rented product is a service, no picking is created, which means
no stock move, resetting the delivered quantity to zero. This triggers a
constraint violation if a returned quantity already exists (e.g., 0 >=
positive).
This commit applies the following fixes:
- If the SOL product is a service, we do not update its delivered
quantity as it is managed manually by the salesperson on the SOL
directly.
- Additionally, we remove the constraint to allow more flexibility.
opw-5076638
[^1]: https://github.com/odoo/enterprise/pull/88689
[^2]: https://github.com/odoo/enterprise/pull/90510A flaky automated test for purchase catalog suggestions was temporarily shortened to avoid inconsistent failures. This helps keep validation runs reliable while the related suggestion logic is being reworked separately.
Original PR description
Temporarily remove last part of suggest feature JS tour, which test record interactions as well as filter interactions. WHY: Non deterministic behavior, see: https://runbot.odoo.com/odoo/runbot.build.error/232708 https://runbot.odoo.com/odoo/runbot.build.error/231734 This was simply commented out because the logic, as well as the tour are being reworked in this PR https://github.com/odoo/odoo/pull/225721 task#4783508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverses a previous update that caused automated build failures. It restores the prior behavior for user settings field descriptions, helping keep the system stable for future releases.
Original PR description
This reverts commit adef0f7261de8f5936aff62077732a974c313f39. Responsible for this runbot error: https://runbot.odoo.com/odoo/runbot.build.error/230934
This update resolves several user-facing issues across accounting, inventory, manufacturing, point of sale, email, calendar, website editing, and Saudi e-invoicing. It improves reliability by preventing errors, correcting financial calculations, preserving saved data, and making reports and interface actions behave as expected.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Bank reconciliation can now match common sales order references such as SO0001, which were previously ignored because they were too short. This helps payments link to the right documents more reliably and reduces manual reconciliation work.
Original PR description
Matching on references was limited to matching words > 8, to increase reliability, but the default sequence for sale orders is 6 characters (SO0001), so they would never be found unless we reach SO1000000 -_- Forward-Port-Of: odoo/enterprise#94717 Forward-Port-Of: odoo/enterprise#93640
Project reports now leave out tasks that belong to template projects, so reporting reflects only real active project work. This prevents template setup data from distorting business metrics and management views.
Original PR description
Tasks in project templates should be excluded from the reporting. Task-5096193
This update fixes how purchase requests, sales-linked purchases, manufacturing, and stock reception reports handle planned dates, deadlines, and document links. It helps teams avoid duplicate purchase lines, keep supplier deadlines accurate, and access related business documents correctly from reception reports.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes internal test failures for Mexico electronic invoicing by giving the test user the required Sales permissions. It helps keep validation reliable without changing how customers create sales orders or invoices.
Original PR description
The tests `test_global_discount` and `test_down_payment` in `l10n_mx_edi_sale` were failing with:
AccessError: You are not allowed to create 'Sales Order' (sale.order) records.
This happened because `mx_external_setup` runs with a user that does not belong to any Sales group. Both tests explicitly create Sale Orders and advance payment wizards, which require Sales ACLs.
This change ensures the test user has the `sales_team.group_sale_salesman` group in `setUpClass`, so Sales Orders can be created normally. No business logic is modified, only test stabilization for the MX localization.
[RB-232559](https://runbot.odoo.com/odoo/error/232559)
Forward-Port-Of: odoo/enterprise#94911This update fixes an internal Swiss payroll test by removing a reference to a field that is no longer supported. It helps keep automated checks reliable without changing payroll features or user workflows.
Original PR description
The CH contract template whitelist test referenced `overtime_from_attendance` when creating a Version. task-5095572 Forward-Port-Of: odoo/enterprise#95034
Fixed an issue where adding products to an empty online cart could push the cart summary to the bottom of the page instead of keeping it beside the cart. This improves the shopping experience by ensuring the cart layout updates correctly when items are added, including through quick reorder.
Original PR description
When the cart was previously empty, adding products (e.g., via the quick reorder feature) caused the cart summary to display incorrectly at the bottom of the page. This happened because the left column's default width spans the entire screen when the cart is empty, and adding products did not update the column widths. As a result, the left column retained a full width which left no space for the cart summary on the right. This commit resolves the issue by ensuring the cart columns are updated dynamically when the cart content changes.
This fixes an Accounting issue where confirming a customer invoice could fail if the journal used European payment references and included non-alphanumeric characters in its code. The change validates the journal code before generating the payment reference, preventing invoice confirmation errors for affected configurations.
Original PR description
Currently, an error occurs when confirming a customer invoice that uses a journal with an invalid configuration. **Steps to Reproduce:** 1) Install Accounting app.(with Demo) 2) Navigate to…
Currently, an error occurs when confirming a customer invoice that uses a journal with an invalid configuration. **Steps to Reproduce:** 1) Install Accounting app.(with Demo) 2) Navigate to Accounting>Configuration>Journals 3) Open existing 'Sales' journal and make following changes: - set Sequence Prefix: INV- - In the Advanced Settings Page, set 'Communication Standard' as 'European' and save the journal. 4) Create a Customer Invoice with this Sales Journal and click on `Confirm`. **Error :** `ValueError: invalid literal for int() with base 36: '-'` **Root Cause:** Since [this commit](https://github.com/odoo/odoo/pull/212169/commits/e4a09467a20f282d28baa09091c10a6aea6d0094#diff-cc13d9842e166c12738b659e0478ceb8b1b15734442c1e090252919e7efb6ed7), On following above steps, The value of 'number' received at [1] looks like 'INV-000003' due to which on further computation of this value at [1] causing an error. **Fix:** prevent crash by adding a additional check on methods `_get_invoice_reference_euro_invoice` and `_get_invoice_reference_euro_partner` to validate the journal's short code. [1]- https://github.com/odoo/odoo/blob/2646790e7e31b4c600e39f2d5c87f0744b1578b0/addons/account/tools/structured_reference.py#L20-L26 **sentry-6860586611** Forward-Port-Of: odoo/odoo#227557 Forward-Port-Of: odoo/odoo#225987
Creating a project from a template with subtasks now assigns people to the correct tasks based on the configured roles. This prevents users from being placed on the wrong child tasks and keeps new project data consistent.
Original PR description
Before this commit, when we created a project from a template with task with subtask, the mapping of the role/user was not correctly applied. This lead to inconsistent data at the project creation such as setting users on the child tasks randomly instead of correctly setting it on the parent task Source of the issue: We wrongly assumed that the task order of the project copied was the same as the original project and thus used the original project task's list in order to set the user on the copied tasks. Solution: Keep the role_ids on the copied tasks and use that data to set the correct user using the wizard mapping. The role_ids are set to False once the data are correctly set. task-5094321 Forward-Port-Of: odoo/odoo#227654
The automatic cleanup process now skips documents that are linked to signed document records. This prevents background deletion jobs from failing while still keeping signed documents protected from manual deletion.
Original PR description
Currently an error occurs when auto vacuum tries to clear documents linked to `sign_document`. **Steps to replicate:** * Install `documents_sign` with demo data. * Go to documents > Move Employment…
Currently an error occurs when auto vacuum tries to clear documents linked to `sign_document`. **Steps to replicate:** * Install `documents_sign` with demo data. * Go to documents > Move Employment contracts to trash * Trash > Try to to delete employment contract you will see error in terminal. Similarly error will be produced by the Auto-Vacuum process when it attempts to delete it after the configured deletion delay. **Error:** `ForeignKeyViolation: update or delete on table 'ir_attachment' violates foreign key constraint 'sign_document_attachment_id_fkey' on table 'sign_document' DETAIL: Key (id)=(1164) is still referenced from table 'sign_document'.` **Root cause:** * At [1], the `sign.document` model was introduced, which prevents the deletion of sign documents. As a result, attempting to delete them due to [2] will cause an error. **Solution:** * Update the `_get_gc_clear_bin_domain` to ensure that the Auto-Vacuum process skips sign documents. * This will still throw an Validation and ForeignKey error as expected when the user tries to delete it from the GUI letting them know it cannot be deleted. [1]: https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b#diff-deebbcccf829fd1804d145c5c7140b482801644bd948639f77caa310b18b8120 [2]: https://github.com/odoo/enterprise/blob/828d47f9ad1d5e396b074c404287799574a6d692/sign/models/sign_document.py#L44 sentry-6842360375 Forward-Port-Of: odoo/enterprise#95018 Forward-Port-Of: odoo/enterprise#93818
Customers who paid an invoice or order can now update their billing address when no country was previously set. This prevents checkout or portal account issues where the country field was incorrectly locked, reducing support friction and failed address updates.
Original PR description
After paying an invoice or sale order, a customer without a billing country cannot update the country in their billing address because the form is disabled by the portal's country edition rule. **Steps to reproduce:** 1. Create a customer without a billing country. 2. Generate an invoice or sale order for that customer. 3. Pay the invoice/order (possible with some payment providers). 4. Go to the customer portal and try to update the billing address. The country field is disabled, preventing the customer from setting their country. This fix ensures that if the partner has no country set, the field remains editable even when normal country edition restrictions apply. This issue also affects the `website_sale` module, specifically the checkout process, where the country field may be blocked if not handled properly. Forward-Port-Of: odoo/odoo#227353
This update standardizes button text, tooltips, and accessibility labels across the online shop. It makes customer-facing actions clearer and more consistent while also correcting minor wording and formatting issues.
Original PR description
Harmonize & fix buttons labels/titles/aria-labels Correctly format/order button nodes attributes Fix some typos --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when a customer has open carts on multiple eCommerce websites and their address change triggers tax or fiscal position updates. Loyalty rewards are now recalculated separately for each cart, keeping checkout available and stable.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
Enabling the Can Create option in Studio for Website Live Chat channels no longer triggers an error. This prevents an interruption when administrators customize Live Chat views and makes the setup experience more reliable.
Original PR description
Currently, an error occurs when enabling `Can Create` in Studio for a Website Live Chat channels. **Steps to reproduce:** - Install the `im_livechat` and `web_studio` modules. - Go to `Live Chat`,…
Currently, an error occurs when enabling `Can Create` in Studio for a Website Live Chat channels. **Steps to reproduce:** - Install the `im_livechat` and `web_studio` modules. - Go to `Live Chat`, create a new channel, then return to the Live Chat channels view and open the newly created channel in kanban view. - Open `Studio` and enable `Can Create`. **Error:** ``` SyntaxError: syntax error at or near ')' LINE 12: WHERE discuss_channel.id IN () ``` **Root Cause:** At [1], an `SQL query` is executed with `self.ids`, when `self.ids` is `empty`, this leads to an `error`. **Fix:** This commit prevents the error by updating `_get_last_messages` to check for `empty self.ids` and return an empty recordset early and also updates `_compute_duration` to safely handle cases where `record.create_date` is `False`. [1]: https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/mail/models/discuss/discuss_channel.py#L1404-L1421 sentry-6861438710 Forward-Port-Of: odoo/odoo#225899
This fix prevents certain API request parameters from being confused with reserved fields used to route calls. It helps ensure integrations and automated requests work reliably when they use parameter names that overlap with internal request handling.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Purchase order lines no longer allow users to create new units of measure directly from the line entry field. This prevents deleted or incomplete units from causing purchase order confirmation failures, making the purchasing workflow more reliable.
Original PR description
When users create a new UoM from order lines, and after deleting the newly created UoM, they try to confirm the order. Steps to reproduce: --- - Install `purchase_stock` module - Create a New PO - Add an order line -> Remove its `Unit` and create a New one - Delete newly created UoM from `Units & Packagings` - Now Confirm Order Traceback: --- - `ValueError: Expected singleton: uom.uom()` - `ZeroDivisionError: float division by zero` This error occurs because, after deleting the newly created UoM, the `product_uom_id` becomes empty, which leads to errors in multiple lines. Solution: --- We are restricting users from creating a UoM from purchase order lines, as already done in other modules (e.g., stock, account, …). sentry-6746792383, 6853969554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225475
6 changes
Resolved issues and error corrections
Payroll users with Administrator access can now cancel completed payslips as intended. This removes an incorrect permission check that blocked authorized payroll staff and interrupted normal payroll corrections.
Original PR description
steps to reproduce: ------------------- 1. Install payroll 2. Create a user and grant "Administrator" access to Payroll. 3. Log in as the new user and try to cancel a 'Done' payslip. issue: ------ A UserError is raised: "Cannot cancel a payslip that is done." observation: ------------ A user with Payroll "Administrator" access is unable to cancel a payroll payslip cause of the issue: ------------------- During cancellation, the system checks whether the user is "Admin" instead of verifying if the user has Payroll "Administrator" access. https://github.com/odoo/enterprise/blob/13832d80570956e504e1c09f41acbeb0bc4baedc/hr_payroll/models/hr_payslip.py#L509-L513 solution: ---------- Check that the user has Payroll "Administrator" access. opw-5040029 Forward-Port-Of: odoo/enterprise#93831
This fix makes automated invoice date checks for Mexican electronic invoicing less sensitive to tiny timing differences. It helps avoid false test failures without changing customer-facing invoicing behavior.
Original PR description
ignored micro-seconds in CFDI date assertion to avoid test failure build_error-223223
This update prevents an error that could occur when a customer has open carts on multiple eCommerce sites and changes their address. Loyalty rewards and cart pricing are now recalculated safely across multiple carts, helping customers continue checkout without interruption.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
Purchase entries in India's GSTR-3B report now include credit notes, receipts, and other relevant purchase records so totals are accurate. Purchase-related lines were also removed from the POS-specific report area because point-of-sale activity is not related to purchase records, reducing incorrect reporting.
Original PR description
Currently, purchase entries are not displaying the correct data because the credit notes and receipts were not included. This PR removes purchase-related data from `l10n_in_reports_gstr_pos` (as POS has no relation to purchase records) and ensures that credit note data and other purchase records are properly displayed in the GSTR-3B report. **opw**-5079401 Forward-Port-Of: odoo/enterprise#95027 Forward-Port-Of: odoo/enterprise#94582
This fix prevents Odoo's core data loading process from crashing in rare cases involving invalid or mixed record references. It improves system stability and consistency without changing normal user workflows.
Original PR description
This commit addresses two corner cases that cause `fetch()` to crash: Mixing new and real records: - Issue: If a recordset contains both new and real records, `fetch()` raises an `AccessError`. - Rationale: While we typically assume that new and real records are never mixed, certain recordset operations can inadvertently lead to this state. Handling this case improves the overall robustness of the ORM. Using `False` as a record id: - Issue: Using a record with a `False` id, such as `browse([False])`, causes a SQL error when `fetch()` is called. - Rationale: Other operations, like `browse([False]).name`, work without crashing. To ensure consistency across the ORM, `fetch()` should also handle `False` ids without error.
This fix ensures Odoo VoIP sends the correct connection information when using secure web calling. As a result, users can reliably receive incoming calls in setups that use secure WSS connections.
Original PR description
### Before this PR Using voip with WSS, it can't receive calls because the current transport is not sent to the PBX. ### After this PR: The right transport is sent
2 changes
Resolved issues and error corrections
The GSTR-3B report now includes purchase credit notes, receipts, and other purchase records so reported values are accurate. Purchase-related report data was also removed from the POS reporting area because POS does not handle purchase records, reducing the risk of misleading tax figures.
Original PR description
Currently, purchase entries are not displaying the correct data because the credit notes and receipts were not included. This PR removes purchase-related data from `l10n_in_reports_gstr_pos` (as POS has no relation to purchase records) and ensures that credit note data and other purchase records are properly displayed in the GSTR-3B report. **opw**-5079401 Forward-Port-Of: odoo/enterprise#94582
This fixes a crash that could occur when a customer had open carts on multiple eCommerce sites and changed their address. Loyalty rewards are now recalculated separately for each cart, keeping checkout flows stable when tax or fiscal rules change.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225