Daily updates from Odoo
Navigate
Branch
Saturday, September 13, 2025
100 changes
6 changes
Resolved issues and error corrections
This fix adjusts Swiss ISO 20022 payment files so bank clearing numbers are placed in the expected XML field structure. It helps prevent payment batch files from being rejected or flagged as invalid by banks and validation tools.
Original PR description
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner - Pay with "Swiss ISO20022" - Create a batch payment with that payment and validate - In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId)) ### Cause: The code directly inputs the value of `clearing_number` in `ClrSysMmbId`. ### Solution: Add `MmbId` to contain the clearing number. ### Note: The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`. This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations. opw-4872507 Forward-Port-Of: odoo/enterprise#94460
Fixes an issue that prevented users from saving Mexican customer credit notes when a CFDI Origin was entered. This helps businesses complete credit note workflows without encountering an error.
Original PR description
Currently, an error occurs when creating a customer credit note with a CFDI Origin.
**Steps to reproduce:**
- Install the `l10n_mx_edi` module and switch to `ESCUELA KEMPER URGATE` company.
- Navigate to: Invoicing > Customers > Credit Notes > New.
- Set `CFDI Origin` to `01|E19C50D2-1292-5817-BDDE-2666967C7471` and click `Save`.
**Error:**
`TypeError: unhashable type: 'list'`
**Root Cause:**
At [1], the code incorrectly uses `relationado_data['03', []]` instead of `relationado_data.get('03', [])`. The tuple `('03', [])` is treated as a dictionary key, which leads to an `error`.
**Fix:**
This commit ensures users can correctly set the CFDI Origin.
[1]
https://github.com/odoo/enterprise/blob/14b31a3631a97dd61ebd662fb768485e5a509c2c/l10n_mx_edi/models/account_move.py#L500
sentry-6823395705The Spanish balance sheet now avoids counting certain related-party payable accounts twice. This prevents overstated totals in the Other Current Payables section, giving businesses more accurate financial reports.
Original PR description
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from…
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from *Accounting → Reporting → Balance Sheet*. **Observed behavior:** - In the Balance Sheet, under *3. Other Current Payables*, the amount shown is double the journal entry. - Drilling down shows the correct amount in the journal entry, but the Balance Sheet line is overstated. **Root cause:** * In the expression for *3. Other Current Payables*, accounts **551** and **5525** were included twice: * once in credits and again in the balance, leading to double counting. **Reference:** * BOE: https://www.boe.es/eli/es/rd/2007/11/16/1514/con#cuenta * PR with related changes: [odoo/enterprise#82447](https://github.com/odoo/enterprise/pull/82447) **Solution:** - Removed accounts 551 and 5525 from the balance calculation to prevent duplication. opw-5056965 Forward-Port-Of: odoo/enterprise#94310
The journal report test was updated so it no longer depends on a payment reference staying blank in certain country-specific accounting setups. This helps keep automated builds stable when Czech localization is installed, reducing false test failures without changing user-facing accounting behavior.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#94554
Users can no longer place signing fields on a PDF page before it has finished loading, preventing errors during document preparation. The update also improves page refresh handling so temporary elements are not removed at the wrong time.
Original PR description
Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading. Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically. task-5065598 Forward-Port-Of: odoo/enterprise#94666 Forward-Port-Of: odoo/enterprise#94001
This fixes a timing issue that could cause the two-step authentication flow to behave unreliably when the web client starts. It updates the related test synchronization so the problem is properly covered and less likely to reappear.
Original PR description
Should actually fix what #224161 tried to: I didn't notice that the events had been renamed (#220852) and since the test was still disabled (and the fixing PR was set to the master one) all the CIs ran without the test, thus not testing the fix in any way. It could have passed anyway as it's a non-deterministic issue, but it's at best a 50/50 that it succeeds so over 3 stagings I'd most likely have seen it... https://runbot.odoo.com/odoo/error/231316 https://runbot.odoo.com/odoo/error/181862 (the original of the same) Forward-Port-Of: odoo/odoo#226857
6 changes
Enhancements to existing features
Invoices created from sales orders now use the sales order name as the reference when no customer reference is already provided. This helps teams match prepayments more reliably and reduces payment reconciliation errors, with related updates to payment memo handling and localization tests.
Original PR description
Unless there's already a customer reference, we need the SO name to be able to match any prepayment --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Signing fields can no longer be added before the PDF page is ready, preventing errors during document preparation. Cleanup of temporary page elements was also adjusted to avoid disrupting page re-rendering, making the signing setup experience more stable.
Original PR description
Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading. Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically. task-5065598 Forward-Port-Of: odoo/enterprise#94001
This fix updates an accounting report test so it no longer depends on a payment reference staying blank in every localization setup. It helps keep automated builds stable when Czech accounting localization is installed, reducing false test failures without changing business behavior.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#94554
This fixes an issue where moving documents into a folder could accidentally remove access for members who had previously visited that folder. Users keep their intended document permissions, reducing unexpected access loss and support needs.
Original PR description
When moving documents with members to a folder which has been visited by those same members (or some of them) they are removed from those documents access. This is caused by the document.access which has an entry for the members but with a null role. Task-5075196 Forward-Port-Of: odoo/enterprise#94610 Forward-Port-Of: odoo/enterprise#94149
This fix improves the reliability of the two-factor authentication flow when the web client starts. It corrects a test synchronization issue so the related login behavior is properly checked and intermittent failures are less likely to reach users.
Original PR description
Should actually fix what #224161 tried to: I didn't notice that the events had been renamed (#220852) and since the test was still disabled (and the fixing PR was set to the master one) all the CIs ran without the test, thus not testing the fix in any way. It could have passed anyway as it's a non-deterministic issue, but it's at best a 50/50 that it succeeds so over 3 stagings I'd most likely have seen it... https://runbot.odoo.com/odoo/error/231316 https://runbot.odoo.com/odoo/error/181862 (the original of the same) Forward-Port-Of: odoo/odoo#226857
Bank reconciliation matching now recognizes shorter sales order references like SO0001. This helps payments match the right customer documents more reliably, reducing 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 -_-
1 change
Resolved issues and error corrections
This change updates a journal report test so it no longer depends on a payment reference staying empty in all localizations. It helps prevent false build failures when Czech localization is installed, improving release stability without changing user-facing behavior.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#94554
10 changes
Resolved issues and error corrections
The Spanish balance sheet report no longer double-counts entries posted to accounts 551 and 5525. This prevents overstated amounts under Other Current Payables, giving businesses more accurate financial reporting.
Original PR description
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from…
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from *Accounting → Reporting → Balance Sheet*. **Observed behavior:** - In the Balance Sheet, under *3. Other Current Payables*, the amount shown is double the journal entry. - Drilling down shows the correct amount in the journal entry, but the Balance Sheet line is overstated. **Root cause:** * In the expression for *3. Other Current Payables*, accounts **551** and **5525** were included twice: * once in credits and again in the balance, leading to double counting. **Reference:** * BOE: https://www.boe.es/eli/es/rd/2007/11/16/1514/con#cuenta * PR with related changes: [odoo/enterprise#82447](https://github.com/odoo/enterprise/pull/82447) **Solution:** - Removed accounts 551 and 5525 from the balance calculation to prevent duplication. opw-5056965 Forward-Port-Of: odoo/enterprise#94310
Users can no longer add, edit, or remove approvers on their own approval requests, preventing permission errors and unintended changes. This keeps approval workflows more reliable by ensuring approver management follows the correct access rules.
Original PR description
Fixed an issue happening when trying to add approvers to one's own request, and remove their ability to delete approvers from the request Task-4897775 Forward-Port-Of: odoo/enterprise#94577 Forward-Port-Of: odoo/enterprise#92309
UPS shipping rate checks now handle combo products correctly. This prevents valid orders with combo items from being blocked when customers or staff request a shipping rate.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit 59a79a5bc51 fixed a bug in 8 shipping connectors, preventing the retrieval of the shipping rate if combo products were present, but failed to fix it in `delivery_ups_rest`. Solution -------- Use `_get_invalid_delivery_weight_lines` helper method to check if there are any lines where a weight is expected, but is lacking. opw-4940973 Forward-Port-Of: odoo/enterprise#93737
AI voice recording now shows a clearer notification when it cannot start because of a backend setup issue, such as a missing API key. This helps users and administrators understand what went wrong and resolve the problem faster.
Original PR description
This PR adds a more explicit toast message for the recording when an error occurs on the backend (i.e. UserError). This applies to cases such as not having the API key set and trying to start the recording Forward-Port-Of: odoo/enterprise#94571
This fix prevents an error when users save Mexican customer credit notes with a CFDI Origin. It helps accounting teams complete credit note workflows reliably without being blocked by a system crash.
Original PR description
Currently, an error occurs when creating a customer credit note with a CFDI Origin.
**Steps to reproduce:**
- Install the `l10n_mx_edi` module and switch to `ESCUELA KEMPER URGATE` company.
- Navigate to: Invoicing > Customers > Credit Notes > New.
- Set `CFDI Origin` to `01|E19C50D2-1292-5817-BDDE-2666967C7471` and click `Save`.
**Error:**
`TypeError: unhashable type: 'list'`
**Root Cause:**
At [1], the code incorrectly uses `relationado_data['03', []]` instead of `relationado_data.get('03', [])`. The tuple `('03', [])` is treated as a dictionary key, which leads to an `error`.
**Fix:**
This commit ensures users can correctly set the CFDI Origin.
[1]
https://github.com/odoo/enterprise/blob/14b31a3631a97dd61ebd662fb768485e5a509c2c/l10n_mx_edi/models/account_move.py#L500
sentry-6823395705
Forward-Port-Of: odoo/enterprise#92876The journal report test now validates the payment reference using the value generated by the system instead of assuming it is empty. This prevents false build failures when Czech localization is installed, improving test reliability without changing user-facing behavior.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#94554
[This commit][1] introduced errors in the Dutch and German translation files. As a result this module can not be installed anymore when any of these languages is used. This commit fixes the errors. [1]: https://github.com/odoo/enterprise/commit/d3d5e667a2d543b55a40148cb536e54d2ac64300 Forward-Port-Of: odoo/enterprise#94345
Original PR description
[This commit][1] introduced errors in the Dutch and German translation files. As a result this module can not be installed anymore when any of these languages is used. This commit fixes the errors. [1]: https://github.com/odoo/enterprise/commit/d3d5e667a2d543b55a40148cb536e54d2ac64300 Forward-Port-Of: odoo/enterprise#94345
Users can no longer place signing fields on a PDF page before it has finished loading, preventing errors during document preparation. The cleanup of temporary page elements is also handled more safely, improving stability when PDF pages refresh.
Original PR description
Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading. Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically. task-5065598 Forward-Port-Of: odoo/enterprise#94666 Forward-Port-Of: odoo/enterprise#94001
The quote calculator now applies spreadsheet filter values in the correct format after older data is updated. This prevents filters from being set incorrectly when opening or using quote calculator spreadsheets created before the data format change.
Original PR description
Commit odoo/odoo@dddcd8919f02e458219443afbc560ca2fbad6d1e changed the way global filter values are represented in the json data. Any data in a prior version undergo a "client-side upgrade". However the quote calculator action was changing the data before it was upgrade with the new representation. Forward-Port-Of: odoo/enterprise#94711
Miscellaneous changes
Related: https://github.com/odoo/odoo/pull/226599 Related: https://github.com/odoo/design-themes/pull/1145 Forward-Port-Of: odoo/enterprise#94469
Original PR description
Related: https://github.com/odoo/odoo/pull/226599 Related: https://github.com/odoo/design-themes/pull/1145 Forward-Port-Of: odoo/enterprise#94469
76 changes
Enhancements to existing features
Record creation is now faster when large HTML content is involved, such as marketing emails. The change avoids repeating an expensive processing step, reducing campaign processing time and memory use while keeping stored content properly cleaned.
Original PR description
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database*…
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database* insertion 2) Once post-insert in `convert_to_cache`, when converting the `vals` for insertion in the *cache* for the newly created records. This redundancy has a negative performance impact when creating many records where new HTML fields are set, e.g., mass-mailing, as potentially large HTML documents are parsed and validated, often with external libraries. To address this issue, this commit removes the insertion into *cache* of the HTML values for the newly created records. This removes the overhead of the second sanitization, speeding up the creation, and also helps with overall memory pressure, as we're not inserting large HTML fields into cache. The latter is particularly noticeable for long-running batch creation processes that do *not* commit intermediate results. The downside of this patch is the potential *cache-miss* (and therefore the subsequent *query*) if the HTML field of the newly created records is read. This is unlikely in business code because intrinsically, an HTML field is often just a data 'blob' that has no logical usage. In the rare case where it needs to be read after creation, since the value in the database is already sanitized, re-sanitization is not necessary for insertion in the cache. Given these considerations, the trade-off seems reasonable to make. Benchmark --------- In a scenario for a marketing campaign with 1000 recipients, using a *mid-sized* email template and emulating a typical campaign, the results were: | Method | Before | After | Speed up | |-------------------------------|----------|-----------|----------| | `_process_mass_mailing_queue` | 2.84 min | 1.55 min | 1.8x | | `create` | 2.11 min | 50.23 sec | 2.5x | This represents roughly a *2x* performance improvement in processing an email campaign. * more detailed benchmarks are available in the task's description Reference --------- task-4962646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225207 Forward-Port-Of: odoo/odoo#223875
This update adjusts internal performance expectations for the Knowledge app after a change in how HTML content is handled during creation. It helps keep automated performance tests accurate and prevents false alarms without changing user-facing behavior.
Original PR description
Adapting query count, due to not putting html fields in cache upon creation. task-4962646 Forward-Port-Of: odoo/enterprise#93741 Forward-Port-Of: odoo/enterprise#93171
Payroll contract templates now copy the right country-specific fields when creating employee contracts. This helps reduce missing local payroll details and improves consistency across supported country payroll setups, with tests added to confirm the behavior.
Original PR description
This commit implements _get_whitelist_fields_from_template() method across all HR payroll localizations to ensure that localization-specific fields are properly copied when creating contracts from templates. Additionally, comprehensive test coverage has been added for all localizations to validate the whitelist functionality and ensure proper template loading behavior. task-4954283 X-original-commit: b6c5609de48e631f1a7158f6c91fea35e97d4b78
Odoo notifications have been redesigned to be smaller, clearer, and more consistent across apps. They now include a progress bar so users can see when temporary messages will disappear, improving usability without changing core business workflows.
Original PR description
A big part of the notification behaviour that was in the notification service has been move to the component "Notification". With this comes also a visual cleaning of the notification. Smaller, more compact and with a progress bar that show when the notification will disappear. TASK-ID: 4334047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Notifications have been redesigned to be smaller, clearer, and less distracting across the application. Users can now better understand when temporary messages will disappear thanks to a visible progress indicator, improving day-to-day usability.
Original PR description
A big part of the notification behaviour that was in the notification service has been move to the component "Notification". With this comes also a visual cleaning of the notification. Smaller, more compact and with a progress bar that show when the notification will disappear. TASK-ID: 4334047
The Barcode app now better supports putting packages inside other packages, including scanning multiple packages into a larger package and unpacking them when needed. Package lines are grouped and labeled by their full outer package structure, making warehouse operations clearer and reducing handling mistakes.
Original PR description
Add some improvement for the pack in pack feature in the Barcode app, like an "Unpack" button or the package lines groupement by their outermost package dest. See commits' message for more details. [task-5065193](https://www.odoo.com/odoo/966/tasks/5065193)
Clicking an @mention in Mail now opens the person's avatar card instead of taking the user directly to a chat. This helps users view relevant contact details while staying in their current conversation or workflow.
Original PR description
Purpose of this commit: Previously, clicking on an @mention would navigate the user directly to a chat session with the corresponding partner. This commit changes that behavior to open the partner's avatar card popover instead, giving the user immediate access to more detailed information without leaving the current context. task-3816952 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The manufacturing demo data for tables now reflects the updated shop floor workflow, where each production step has its own worksheet. This gives users clearer, step-specific guidance in demos and removes an unused worksheet file.
Original PR description
Purpose: -------- With the new shopfloor design, worksheets are no longer defined at the operation level. Each step now has its own worksheet at the Quality Point level. The demo data of [FURN_9666] Table and [FURN_8522] Table Top has been updated accordingly to align with this design and provide users with a consistent experience. Before this commit: ------------------- The worksheet was attached at the operation level as a single PDF, with pages reused across different steps. After this commit: ------------------ - Worksheets are now defined at the Quality Point level. Each step has its own dedicated worksheet, split from the original PDF and applied to the corresponding Quality Check. - The unused file `drill-worksheet.pdf` has also been removed. Relevant PR: https://github.com/odoo/odoo/pull/200345 Task: 5068250
Demo data for the Table and Table Top products now matches the new shopfloor workflow. Instead of one worksheet reused across an operation, each quality step has its own dedicated worksheet, making demonstrations clearer and more consistent for users.
Original PR description
_* = quality_mrp_workorder, quality_mrp_workorder_worksheet Purpose: -------- With the new shopfloor design, worksheets are no longer defined at the operation level. Each step now has its own worksheet at the Quality Point level. The demo data of [FURN_9666] Table and [FURN_8522] Table Top has been updated accordingly to align with this design and provide users with a consistent experience. Before this commit: ------------------- The worksheet was attached at the operation level as a single PDF, with pages reused across different steps. After this commit: ------------------ Worksheets are now defined at the Quality Point level. Each step has its own dedicated worksheet, split from the original PDF and applied to the corresponding Quality Check. Relevant PR: https://github.com/odoo/odoo/pull/200345 Task: 5068250
The Discuss message composer now has subtler button colors, cleaner focus outlines, and better spacing in mobile action menus. These visual refinements make chat and discussion interactions feel clearer and less distracting across light and dark themes.
Original PR description
1. Send button in discuss app and chat window has lighter primary color so this looks best in white and dark theme in addition to green outline on input focus 2. Send button has darker outline, so…
1. Send button in discuss app and chat window has lighter primary color so this looks best in white and dark theme in addition to green outline on input focus 2. Send button has darker outline, so the button feels slightly smaller so it has more visual spacing with input 3. input focus outline has its effect reduced (100% to 65%), so this is less distracting especially in dark theme 4. Composer buttons in mobile are rounded and no oval-shaped. 5. Discuss actions in bottom sheet have better (more) spacing in-between icon and label Before / After <img width="456" height="799" alt="Screenshot 2025-09-12 at 14 44 19" src="https://github.com/user-attachments/assets/5db8971a-bf1b-4269-b4dd-19a0632d3a7b" /> <img width="454" height="798" alt="Screenshot 2025-09-12 at 18 05 19" src="https://github.com/user-attachments/assets/2965e6ab-57dd-4861-86e1-3a6ccb6cccc7" /> Before / After <img width="445" height="800" alt="Screenshot 2025-09-12 at 14 44 30" src="https://github.com/user-attachments/assets/9e8d9b7e-2fa7-4d4f-b5b2-9a57bedbbe56" /> <img width="444" height="797" alt="Screenshot 2025-09-12 at 14 45 20" src="https://github.com/user-attachments/assets/1ee8a33e-8fe4-4184-add6-9788582d925f" />
The messaging menu now shows the same live chat status indicator that users already see in other chat areas. This makes agent or chat availability easier to spot at a glance and keeps the experience consistent across Odoo messaging.
Original PR description
Live chat status icon is visible in discuss sidebar, in chat window header, in chat bubble... It's missing in messaging menu, which this commit fixes. Before <img width="479" height="612" alt="Screenshot 2025-09-11 at 17 33 23" src="https://github.com/user-attachments/assets/100c19e9-fb37-4def-822e-ed8886e87a83" /> After <img width="481" height="612" alt="Screenshot 2025-09-11 at 17 32 45" src="https://github.com/user-attachments/assets/57947070-e31d-4629-8114-7ae6e3d6ce97" />
Resolved issues and error corrections
This update makes the AI assistant more reliable when gathering information from discussion messages. It prevents errors in cases where related conversation details are unavailable, helping users avoid interruptions.
Original PR description
This commit adds optional chaining to access thread properties in the getRecordInfo function.
Errors found during the web test runner's preliminary checks are now reported clearly as real errors. This helps Odoo's automated testing infrastructure catch critical setup issues sooner, reducing the risk of broken test runs going unnoticed.
Original PR description
The test runner replaces most occurences of `console.log` with a formatted `console.trace`, as to avoid duplicate runbot error messages in general. The issue is that during the dry run, errors that are caught should be logged on the runbot since these errors are more critical (i.e. duplicate test name, which will prevent the runner to run at all). This commit ensures that errors caught during dry run are logged as actual errors to prevent this issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225688
Survey datetime answers are now shown using the current user's time zone, so the answer list and detailed form display the same time. This prevents confusion when reviewing submitted survey responses across different locations.
Original PR description
Steps to reproduce ==================== 1. Create survey with some datetime questions. 2. Receive some response on it. 3. Check answer of datetime questions in answer tab. 4. Click on that answer to open form. ->The time shown in answer tab differs from actual value in form. The display_name of survey.user_input.line is computed based on the answers submitted by users. For questions of type datetime, the display_name was generated by converting the datetime value to a string without accounting for the user's timezone, leading to a mismatch between the actual value and the displayed time. After this commit ================== This commit updates the computation of display_name for datetime answers to consider the current user's timezone. Task-4890423 Forward-Port-Of: odoo/odoo#226354 Forward-Port-Of: odoo/odoo#216281
Website generation now handles temporary concurrency conflicts so the operation can be retried instead of failing outright. This improves reliability when multiple actions happen at the same time, reducing unexpected interruptions for users creating or updating websites.
Original PR description
When a concurrency error occurs, we need to let it retry. To do this, we must catch the Serialization Failure and raise it. Forward-Port-Of: odoo/enterprise#93851
The web test runner now keeps excluded tests when simplifying test URLs. This prevents test selections from accidentally changing, helping developers run the exact intended checks more reliably.
Original PR description
Before this commit, when the test runner simplified the URL (e.g. if the runner is given the ID of every test in a suite, it will remove them and only include the suite ID), it always considered IDs as being "included", and ignored the "-" specifying that some IDs should be "excluded". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225950
This fixes an issue where reloading a grouped Kanban view after folding a group could show an error. The view now refreshes its saved grouping state from the latest server response, helping users return to their work without interruption.
Original PR description
- Open a grouped kanban; - Fold a group; - Reload the page; Before this commit, an error occurred because the configuration says that the group is unfolded, but the returning RPC didn't have any records. This commit clears the current configuration, which will then be reloaded based on the returning RPC. Forward-Port-Of: odoo/odoo#226312
The stock picking screen now shows the correct "Add a Product" button text on phone-sized views. This avoids confusion for warehouse users who previously saw the less clear "Add Stock Moves" label.
Original PR description
Have the "Add a Product" button correctly display that instead of "Add Stock Moves" while in phone view on a picking. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editor snippet previews now show the Parallax label only when the snippet actually uses a parallax background. This prevents misleading labels in theme snippets and restores the label for custom snippets where parallax is enabled.
Original PR description
Steps to reproduce the issues: **Issue 1** - Enter "Website" edit mode. - Drag and drop a "Cover" snippet into the page. - Save the snippet as a custom snippet. - Click the "Custom" category. - Bug:…
Steps to reproduce the issues: **Issue 1** - Enter "Website" edit mode. - Drag and drop a "Cover" snippet into the page. - Save the snippet as a custom snippet. - Click the "Custom" category. - Bug: the "Parallax" label is not displayed on the snippet preview. **Issue 2** - Install the "Artists" theme. - Enter "Website" edit mode. - Click the "Intro" category. - Bug: The "Parallax" label is displayed on the "Cover" snippet preview even though it doesn't have a parallax effect. Commit [1] added a label on snippet previews to indicate if they are Carousel, Popup, Gallery, Tab, or Parallax. This label is linked directly to the snippet's original template. However, this does not work well for "Parallax" because it's an option that can be enabled or disabled. So it doesn't make sense to keep the label when the option is not active. This commit fixes that by checking the snippet structure to see if it contains a parallax on its background. [1]: https://github.com/odoo/odoo/commit/63cd0c6497c3c2e8482dc62b4359eb2431a75926 task-4926420 Forward-Port-Of: odoo/odoo#225783 Forward-Port-Of: odoo/odoo#218863
The Employee Type field has been added back to the employee form after it recently disappeared. This helps HR users continue classifying employees correctly without losing access to an important personnel detail.
Original PR description
The Employee Type field disappeared lately, so had to put it back. task-5079734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Send & Print wizard no longer shows an unnecessary tax warning when GST has already been applied through grouped taxes on invoice lines. This reduces confusion for users preparing Indian electronic invoices and helps keep the sending process smoother.
Original PR description
Before this PR: Even if a GST tax was applied on invoice lines, the tax warning was still displayed in the Send & Print wizard. Technical Reason: We were checking `l10n_in_tax_type` to decide whether to show the warning. But since group taxes don’t have a direct value assigned to `l10n_in_tax_type`. To fix this, we now also look at the child taxes’ tax_type when a group tax is used. After this PR: The system now also checks `l10n_in_tax_type` in child taxes. As a result, if GST tax is applied in invoice lines, the warning will no longer appear in the wizard.
Grouped list views with monetary totals no longer crash when all records in a mixed-currency group are deleted. The interface now resets empty group totals correctly, improving reliability for users working with financial lists.
Original PR description
Be in a grouped list view with a monetary field aggregate and a group with different currencies. Open that group, select all its records and delete them. Before this commit, it crashed. Since [1], we…
Be in a grouped list view with a monetary field aggregate and a group with different currencies. Open that group, select all its records and delete them. Before this commit, it crashed. Since [1], we use the new aggregator `array_agg_distinct` which returns the list of currencies of aggregated records. When a group disappears after a reload (which is the case in our flow as we deleted all its records), we keep it in the UI for UX reasons. However, as that group is no longer returned by web_read_group, we manually reset its aggregate values to 0. Before [1], that was correct as all aggregate values were numbers. Now, it can also be arrays (for currencies, with the `array_agg_distinct` operator). This commit properly handles that case. [1] https://github.com/odoo/odoo/pull/224667 closes #226566 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 fix updates a Mexican electronic stock delivery test so it no longer depends on optional demo data. It helps ensure automated checks run consistently across databases, reducing false build failures.
Original PR description
In the [PR 91185](https://github.com/odoo/enterprise/pull/91185), the test was changed to comply with the new changes. In that test, a new vehicle was created using a model from the demo data. Since the demo data is not present in all databases, this caused a problem when the ID could not be found. To fix this, we now create a new model using a brand that exists in the data file and will therefore be present in all databases. See: https://runbot.odoo.com/odoo/runbot.build.error/231693?menu_id=405 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a display issue on product pages where carousel thumbnails could disappear when the image area was set to full width and thumbnails were placed on the left. This improves the shopping experience by keeping product image navigation visible in that layout.
Original PR description
Before this commit, in a product page, when a user selected 100% as the image area size, sets the carousel display option for thumbnails, and positioned them on the left, they were not visible. This commit updates the CSS rules to ensure thumbnails on the left are properly displayed when the image area is set to 100%. task-5077519 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Peppol connections in neutralized databases are now kept fully offline for existing records, preventing failed or unintended network calls. New Peppol connections from those databases are directed to the test network, and support teams get clearer debug information about connection mode and type.
Original PR description
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network,…
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network, therefore the database is in an inconsistent state, and calls to the test network are very likely to fail - if you create a new connection to Peppol on a neutralized database, since the system parameter was not changed, the new connection was on production After this commit: - existing connections are switched in `demo` where everything is mocked locally, no call to the network (whether it's `test` or `prod` can happen) - the system parameter is switched to `test`, therefore new connections will register to the Peppol test network - Also added some fields on the Edi Proxy User to display the mode of the user, as well as the proxy_type in list view. (Those records are only accessible in debug already.) <img width="579" height="333" alt="image" src="https://github.com/user-attachments/assets/87847726-d954-4f68-8336-07771747365f" /> task-none (report from PMAX + WTA) Forward-Port-Of: odoo/odoo#226435
The partner list now consistently uses the standard card-style view when opened in kanban mode. This prevents mobile workflows, such as Field Service, from accidentally showing a specialized equity-related view instead, reducing confusion for users.
Original PR description
This commit sets the priority of the res.partner kanban view to 1, ensuring it is used as the default when opening a kanban on partners. Without this fix, certain contexts (e.g., opening a res.partner many2one field from mobile apps like Field Service) could incorrectly default to the equity-specific kanban view instead of the standard one. task-5077712
This fix makes the rental duration test wait for the shopping cart to finish updating before checking totals. It helps prevent false build failures and improves confidence that rental pricing changes are validated correctly.
Original PR description
steps to reprduce: 1. duplicate multi enterprise 18.0 database 2. run the tour `website_sale_change_rental_duration` in the duplicated database inspired from: https://github.com/odoo/enterprise/commit/c7542e897c537650966497065db9c7d033dcb8ee added a delay to wait when choosing the rental duration, after page is loaded when go to cart , check if the next page is loaded before checking untaxed amount build_error-227718 Forward-Port-Of: odoo/enterprise#93659 Forward-Port-Of: odoo/enterprise#89274
Users returning from an external chart link now land back on the dashboard they were viewing, instead of being reset to the first dashboard. This preserves context when navigating between dashboards and linked pages, reducing confusion and extra clicks.
Original PR description
Steps to reproduce: - go to dashboards - select a dashboard with external links on scorecard charts for instance (do not select the first dashboard) - click on the chart w/ the external link to be redirected - Go back to the previous page through the browser The selected dashboard is now the first dashboard instead of the one you came from. the behaviour was broken since the introduction of the path-based routing in #157867 as we did not specify a path for the dashboard action but still worked because the action params were sent in the context but this was corrected in #216067 task-5067826 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#225870
Users can now work with approvers on their own approval requests without triggering access errors. The change also prevents request owners from adding, editing, or deleting approvers directly, keeping approval controls consistent and reliable.
Original PR description
Fixed an issue happening when trying to add approvers to one's own request, and remove their ability to delete approvers from the request Task-4897775 Forward-Port-Of: odoo/enterprise#94515 Forward-Port-Of: odoo/enterprise#92309
This update prevents accounting test failures when the journal selection field is hidden because only one journal is available. It keeps automated invoice setup reliable after a recent interface change, with no expected impact on day-to-day users.
Original PR description
- Before [#222209](https://github.com/odoo/odoo/pull/222209), the `journal_id` field was always visible, so `init_invoice` could reliably set the `journal_id` value in tests. Now that the field is only shown when two or more journals exist, this PR updates `init_invoice` to handle cases where `journal_id` may be invisible, preventing test failures. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Stripe payment fields at checkout now use the language selected on the website instead of defaulting to the shopper's browser language. This keeps the payment experience consistent for multilingual stores and avoids confusing mixed-language checkout screens.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable Stripe; 2. enable a second language on the website; 3. use second language on website; 3. go to checkout; 4. open card payment method. Issue ----- The card field values are displayed using the current browser's locale instead of the website's language. Cause ----- The `locale` parameter isn't included when connecting to the Stripe API. Solution -------- Include the lang from the `html` element via `_prepareStripeOptions`. If not present, let it fall back on the browser's locale. opw-5024805 Forward-Port-Of: odoo/odoo#226045
When users open a project task created from a sales order, the expected task-related actions now appear in the top bar. This helps sales and project teams access the right task options without extra navigation or confusion.
Original PR description
**Steps to reproduce:** - Install `sale_project` - Create a service-type product - Create and confirm a Sales Order - Open the generated task - Check the top bar actions **Issue:** The related task embedded actions do not appear when opening a task from a Sales Order. **Cause:** The active_id context was not passed when calling `_for_xml_id()`, and a different action (`action_view_task`) was used instead. **Fix:** Pass the project in the context as active_id and use the correct action `act_project_project_2_project_task_all` instead of `action_view_task`. task-4946932
Coupons meant for a customer's next order can no longer be claimed on the order that generated them. This prevents unintended discounts and keeps loyalty program rules applied as configured.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a next-order coupon program; 2. create an order that would generate a coupon; 3. confirm order; 4. click on the "Reward" button. Issue ----- It's possible to claim the reward on the current order. Cause ----- When retrieving claimable rewards, it checks the coupons generated by the current order using `coupon_point_ids`, but does not verify whether the program should be applicable to the current order. Solution -------- If the program only applies on future orders, and the coupon's `order_id` is the current order, skip the coupon when retrieving claimable rewards. opw-4910922 opw-4948757 Forward-Port-Of: odoo/odoo#221536
This fix stops pricelists from referencing each other in a loop, which could previously cause the online shop to crash with a server error. Businesses can now configure dependent pricelist rules more safely, with invalid circular setups blocked before they affect customers.
Original PR description
Steps ----- 1. Create a selectable pricelist A; 2. create a selectable pricelist B; 3. add a rule to pricelist B which uses pricelist A; 4. add a rule to pricelist A which uses pricelist B; 5. go to /shop & select one of the pricelists. Issue ----- > 500: Internal Server Error > Error while render the template > RecursionError: maximum recursion depth exceeded in comparison Cause ----- The `_check_pricelist_recursion` constraint only checks if a pricelist item's `base_pricelist_id` is the same as the item's `pricelist_id`. It can therefore not detect if two or more pricelists have a mutually recursive dependence relationship. Solution -------- Use a depth-first search to ensure any dependent pricelist doesn't depend on a parent pricelist. opw-5070604 Forward-Port-Of: odoo/odoo#226251
This fix ensures payment form tooltips reuse an existing tooltip when one was already created. It helps prevent inconsistent tooltip behavior during checkout or payment interactions, improving clarity for users without changing the payment flow.
This update fixes several issues with packages placed inside other packages during stock transfers. It makes package moves, deletions, and on-screen package information more consistent, helping warehouse teams avoid confusing or incorrect package records.
Original PR description
Various fixes following the pack in pack introduced in #203987 Summary of the changes: - Allow the deletion of a container package even if it was used in a picking, as long as it was only ever used as a container (so it has no `stock.move.line` related to it). - A bunch of visual changes. - Display the full current package name for ongoing pickings in the `Pick From` column. - When relocating packages, if their container are completely moved as well, move the container as well instead of removing them from it. - Adjust the `package_m2o` widget so it is less costly - Use `SelectCreateDialog` for the 'Move a Pack' button. - Fixes an issue where adding a new package on top of packages and their destination container at the same time would leave some unnecessary data behind. For more information, check the commit descriptions. Task-5065793 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures online orders paid entirely with a gift card still go through the same stock availability checks as other payment methods. It prevents customers from completing checkout when items became unavailable after being added to the cart, reducing overselling and fulfillment issues.
Original PR description
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The…
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated. To reproduce: 1- Create a product and add quantity on stock. 2- Uncheck `Conitnue Selling` in `Out-of-Stock` 3- Publish the product on the website 4- Create a gift card 5- Add the product to the cart using portal user 7- Using admin user, set the quantity to less than ordered quantity 8- Using portal user, proceed to payment, and use the gift card. Then checkout. 9- As you see, the order is validated The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`. However, when checking out with gift card, this method is not called. To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0) opw-4941658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226394 Forward-Port-Of: odoo/odoo#222306
This fixes several live chat meeting issues that could cause crashes, incorrect display, cropped permission warnings, and missing picture-in-picture support. Users should have a smoother and more consistent calling experience when using live chat on websites.
Original PR description
This PR fixes several issues with the call meeting view: - crash when opening call settings - wrong style in website, because the full screen component is not mounted in the shadow DOM. - permission icons are cropped - crash when typing component is shown - pip assets are not loaded in the live chat
The barcode inventory tests were updated to match a related platform change in how full packages are added from the user interface. This helps keep automated checks reliable and reduces the risk of regressions in barcode-driven warehouse operations.
Original PR description
Following the change in the community counterpart in [#226043](https://github.com/odoo/odoo/pull/226043), `action_add_entire_packs` now uses ids instead of recordsets (as it's meant to be called directly through JS code). Adapt tests to reflect this change. Task-5065793
Users now see a more explicit notification when starting an AI voice recording fails because of a backend setup problem, such as a missing API key. This helps users understand what went wrong and reduces confusion during recording setup.
Original PR description
This PR adds a more explicit toast message for the recording when an error occurs on the backend (i.e. UserError). This applies to cases such as not having the API key set and trying to start the recording
Payslip simulations no longer force the start date from the employee contract. This avoids errors when salary rules do not have parameters for older contract dates and lets the system use the normal current-month defaults.
Original PR description
Issue: by specifying the payslip date_from to the contract date start when simulating a payslip, there was a risk that some salary rule had no parameter for that date. Solution: not specify the date and let the payslip compute the default dates, which will default to this month.
Employee profile avatars now keep a consistent fixed size in HR views. This restores a previous correction that was accidentally undone, improving the visual consistency of employee records.
Original PR description
The changes made in this PR: https://github.com/odoo/odoo/pull/215597 were wrongly reverted in this PR: https://github.com/odoo/odoo/pull/218194 This PR re-introduces the changes (the employee avatar image has a fixed size). 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 failing automated tests in the online store area. It helps keep quality checks reliable so future changes to eCommerce functionality can be validated with confidence.
Original PR description
runbot-error-227575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226624
Checkout payments using a saved payment method are now held until the order is validated. This prevents customers from being charged or payment requests being sent when a last-minute checkout issue, such as an expired coupon, makes the order invalid.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a saved Stripe payment token; 2. create a discount coupon program & a coupon; 3. go to /shop & add a product to your cart; 4. go to checkout; 5. apply coupon; 6. before finalizing payment, set coupon program expiration to yesterday; 7. finalize payment. Issue ----- An error appears, because of the reward change, but a payment request has already been sent. Cause ----- For token transactions, `_send_payment_request` is called immediately upon creation, i.e. before the `WebsiteSale` controller is able to validate the transaction using `_validate_transaction_for_order`. Solution -------- If the payment flow happens via token, add a `delay_payment_request` context value. When creating a token transaction in `PaymentPortal`, only call `_send_payment_request` if this value is not set in the current context. opw-5013284 Forward-Port-Of: odoo/odoo#226067 Forward-Port-Of: odoo/odoo#225008
Point of sale payments through Adyen now handle cancellation and service availability errors more reliably. This helps prevent payments from getting stuck while waiting for a card response and makes checkout issues clearer when Adyen is unavailable.
Original PR description
When we try to cancel a processing payment, we can get stuck with a in the state waiting card, if there is no anwser from adyen. Also when we call Adyen to process payment, the value returned by data.silentCall is false, so we don't get error when the service is not available --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226587
This fix ensures payment button actions are ready as soon as the checkout payment flow is prepared. It prevents cases where PayPal-related payment events could fire before the button was listening, helping customers complete payments without missed clicks or stalled actions.
Original PR description
In commit 3e5f87b5de143eadf80e9c96e61fe24e621a939e event listeners were initialized on start. However when the event was triggered in payment_paypal it started to add the listeners. So at the moment were the event was triggered there was no listeners on the button to execute. Therefore The event listeners needed to be initialized on setup not on start. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures automated check templates correctly set the intended action when checks are generated. It prevents missing actions caused by an unnecessary condition, helping accounting workflows behave as expected.
Original PR description
Currently the check template will not set the action for an automated checks. This is due to a condition that test if there is already the key in the dict which is useless here.
This fixes an issue where logged-in users starting a livechat could be added twice under different identities, which stopped the feedback panel from appearing after the chat ended. Livechat sessions now keep the correct participant record so customers can consistently leave feedback.
Original PR description
Before this PR, when a logged-in user had a guest in context and started a livechat, 2 discuss.channel.member records were created: one for the guest and one for the logged-in user. This prevented the feedback panel from being shown after the livechat ended. This PR fixes the issue by only adding the guest as a channel member when the user is not logged in. Steps to reproduce: - Start a livechat as a visitor and end it -> feedback panel is shown. - Log in as any user. - Start a livechat and end it -> feedback panel is not shown when clicking Continue or Close.
This fixes an issue where state or government checks within an audit could not be disabled as intended. Businesses can now better control which audit checks apply, reducing unnecessary steps when those checks are not required.
Original PR description
State/Governement checks inside an Audit couldn't be disabled.
Fixes an issue where confirming a generated purchase order could fail when two make-to-order manufactured products shared the same component. The change keeps the related manufacturing references separate, allowing the purchase order confirmation to proceed normally.
Original PR description
Steps to reproduce the bug: With MTO enabled Create 2 finished products sharing 1 common component Create a sale order for those 2 products Try to confirm the generated purchase order for the component: ValueError: Expected singleton: mrp.production.group(x, y) Origin: Each generated mrp.production creates its own mrp.production.group and a purchase.order is generated with only 1 line for the whole quantity. Fix: Since it is for the reception picking, skip updating the production group --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors can now open and adjust settings for older snippets even when their stored version differs from the current template version. This removes a frustrating warning/blocker and helps users continue editing existing pages without extra technical intervention.
Original PR description
* : html_builder. For UX reasons, the block preventing users from accessing the options of a snippet when its version (XML, CSS, JS) differed from the one declared in the snippet's template has been removed. Users can now freely access options for outdated snippets. task-4297808
Express checkout now hides Click & Collect delivery options when multiple pickup stores are configured, because shoppers cannot choose a store in that flow. This prevents customers from accidentally selecting an in-store pickup option without knowing where the order will be collected, while still allowing it when there is only one pickup location.
Original PR description
Before this commit, when entering the express checkout flow, Click & Collect (C&C) delivery methods (DM) were included in the list of possible delivery methods available for express checkout. However, the express checkout flow does not allow customers to select which store they want to pick up their order from. After this commit, C&C DMs are excluded from the list if they have more than one store configured. If only one store is configured, the customer implicitly knows where they will need to pick up their order. Forward-Port-Of: odoo/odoo#226770 Forward-Port-Of: odoo/odoo#226329
UPS shipping rates can now be retrieved for orders that include combo products. This prevents valid deliveries from being blocked when combo items are present, while still checking for products that are missing required weight information.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit 59a79a5bc51 fixed a bug in 8 shipping connectors, preventing the retrieval of the shipping rate if combo products were present, but failed to fix it in `delivery_ups_rest`. Solution -------- Use `_get_invalid_delivery_weight_lines` helper method to check if there are any lines where a weight is expected, but is lacking. opw-4940973 Forward-Port-Of: odoo/enterprise#93737
This fixes an error that could stop the AI live chat snippet from working when no regular live chat channel exists, such as on a fresh database or after channels are deleted. The change makes the website chat experience more reliable in setup and edge cases without changing user-facing features.
Original PR description
Steps to reproduce: - Go to the livechat app. - Delete all the livechat channels. - Open the website app. - Click on edit -> Contacts & Forms and add the ai_livechat snippet. - Set the 'AI Agent' on the snippet and save. - Start chatting with the ai agent using the snippet. - An error occurs. This error will happen in any case such that the livechat isn't available. For example: - Deleting all the livechat channels. - Installing a fresh db without demo data. This will result in the element '.o-livechat-root' not appearing on the website. This causes the ai_livechat component to have an error when trying to hide that element. This commit fixes the issue by adding optional chaining before accessing the class list of the element '.o-livechat-root'.
Mollie payments that remain open, such as SEPA bank transfers, are now treated as pending instead of triggering an invalid status error. This prevents checkout confusion and allows customers to complete bank-transfer payment flows normally.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Mollie as a payment provider; 2. set up an eCommerce order in EUR; 3. go to checkout; 4. pay via Mollie; 5. pick SEPA bank transfer as payment method; 6. leave the transaction open. Issue ----- When returning from the redirect, we get the following error message: > Mollie: Received data with invalid payment status: open Cause ----- An 'open' payment indicates the payment has been created, but nothing else has happened yet[^1]. This is the expected status for bank transfers, but is currently not getting handled in `_process_notification_data`, leading to the error. [^1]: https://docs.mollie.com/docs/status-change Solution -------- Handle 'open' payments the same as 'pending' ones. opw-4894556 Forward-Port-Of: odoo/odoo#226755 Forward-Port-Of: odoo/odoo#225875
This update refreshes Odoo Spreadsheet with fixes for pivot table calculated measures, improving accuracy when totals are used. It also makes spreadsheet navigation easier when many tabs are open and reduces accidental figure dragging, creating a smoother user experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f443c9aed [REL] 19.0.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f443c9aed [REL] 19.0.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0e24e1730 [FIX] pivot: calculated measure from totals [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) https://github.com/odoo/o-spreadsheet/commit/c541ecf11 [FIX] pivot: add aggregator to calculated measure id [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) https://github.com/odoo/o-spreadsheet/commit/6bf3609fd [IMP] carousels: add dropdown when too many tabs [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) https://github.com/odoo/o-spreadsheet/commit/2e401cce2 [IMP] figures: add drag threshold [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) https://github.com/odoo/o-spreadsheet/commit/a96ba1bb8 [IMP] test: add `expect.toHaveStyle` jest matcher [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix makes the website editor’s background positioning tool behave correctly across desktop, mobile preview, scrolling, and visual effects. Users can now adjust background images more accurately without overlay glitches, missing masks, or confusing loading visuals.
Original PR description
__Current behavior before commit:__ The background position overlay action allows the user to move the background image of the editing element. To do that it copies it inside an overlay which is…
__Current behavior before commit:__ The background position overlay action allows the user to move the background image of the editing element. To do that it copies it inside an overlay which is outside the iframe since the [Website refactoring]. This creates multiple challenges because the overlay needs to perfectly align with the editing element behind it which is not a trivial task for several reasons: - The iframe can have different sizes and positions when toggling the mobile preview. - The editing element can be anywhere on the page, and it can move if the user scrolls. - Some scroll effects depend on the dimensions of the viewport which is different in and out of the iframe. Furthermore the `overlay` plugin currently used is designed for contextual menus and pop-ups. It forces the overlay content to always be fully visible in the window and it hides the content if it is bigger. This makes it unsuitable for the purpose of positioning a background image. Here are several bugs that arise from the above: - The overlay doesn't appear if the editing element is taller than the window. - When the overlay is open, it's only possible to scroll while the mouse is hovering the scrollbar. - The overlay image doesn't follow the editing element after scrolling. - The overlay dark mask doesn't cover the whole iframe window. - The loading spinner and its dark overlay is displayed while the background position overlay is on. - If the Scroll Effect is set to "Zoom Out" with maximum intensity, the overlay is not correctly positioned. - If the Scroll Effect is set to "Fixed", the overlay **is** correctly positioned but the background position doesn't align with the one behind it. - In the mobile preview the overlay doesn't cover the iframe. - etc. __Description of the fix:__ Several things are now done differently to fix these issues: - The `overlay` service is used instead of the plugin. This way we have a better control over the positioning of the overlay. - The overlay positioning is more robust to take into account the mobile preview iframe position, the page scrolling and a possible browser zoom. - We stop using an image copy, instead the editing element `background-position` is directly modified making it a perfect wysiwyg. To do this, the overlay dark mask is kept but the portion in front of the editing element is cut-out to highlight it. An invisble dragger element is there to be able to listen to mouse event for the dragging. Also, the content of the section is made invisible so that only the background is shown. [Website refactoring]: https://github.com/odoo/odoo/pull/187419 Related to task-4367641 Forward-Port-Of: odoo/odoo#219179
This update improves how inventory value is calculated for lot-tracked products, backdated stock movements, subcontracting quantities, and manufacturing labor costs. It helps businesses get more reliable stock valuation reports and clearer accounting labels, reducing the risk of misleading inventory or cost figures.
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 fix stops changing one product line’s scheduled date from automatically changing the scheduled dates of other lines on the same stock receipt when delivery features are installed. It helps keep warehouse planning accurate and prevents unexpected timing changes during receipt updates.
Original PR description
### Steps to reproduce: - Install stock_delivery - Create and confirm a receipt for 2 products: - 1 x P1 - 1 x P2 - Modify the scheduled date of P1 to the day before - Save the picking #### Expected…
### Steps to reproduce:
- Install stock_delivery
- Create and confirm a receipt for 2 products:
- 1 x P1
- 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking
#### Expected behavior:
The scheduled date of the picking is updated but not the one of the other move.
#### Current behavior:
The the move scheduled date is also updated.
### Cause of the issue:
Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901
### Note:
This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38
opw-5017423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225690
Forward-Port-Of: odoo/odoo#224986This fix prevents notification items in the messaging menu from jumping or changing height when users hover over them. The unread or important badge and mark-as-read action remain available, while the item text stays visually stable for a smoother experience.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/225145 PR above made a few visual changes, one of which was to show mark as read button in messaging menu item in addition to keeping the badge unread /…
Follow-up of https://github.com/odoo/odoo/pull/225145 PR above made a few visual changes, one of which was to show mark as read button in messaging menu item in addition to keeping the badge unread / important on hover. This is motivated by the fact that item is considered important thanks to this badge, and when hovering it it gives a wrong impression the item is no longer important when this is just on hover. Solution of PR above was to keep display of badge even when mouse-hovering, so mouse hover shows both the badge and the mark as read button. However, if the notification item text takes almost a full single line, mouse-hovering made the item grow bigger due to being on 2 lines forced by mark as read button on hover. This flicker is not great UX. This commit fixes the issue by keeping badge and mark as read button visible on hover, but the mark as read button now overlaps the notification item text rather than collide. As a result, the text part of notification item doesn't change its visual of lines and word break per line just on mouse hovering. Before / After  
Fixes how Odoo calculates the standard cost for FIFO-tracked products when stock is shipped out. This helps keep inventory valuation and product costs accurate after outgoing stock movements.
Original PR description
Ensure that the standard price is correctly computed when a FIFO product has outgoing stock moves. Due to the need of the old FIFO value before marking the moves as 'done', `_update_standard_price` has to be called in `_action_done` instead of `_set_value`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The product comparison feature now stores selected products in cookies again instead of browser session storage. This prevents inconsistencies when shoppers use multiple tabs, making comparison behavior more reliable.
Original PR description
This PR rollback to the use of `cookies` instead of `sessionStorage` for the products comparison features. With Commit[^1], we introduced a fresh new look for the comparison feature, and this redesign included switching from `cookies` to `sessionStorage`. Unfortunately, this approach presents downside (e.g when using multiple tabs). To avoid any issue, we switch back to the use of `cookies`. task-5086187 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr [^1]: https://github.com/odoo/odoo/commit/524c968eb647a65119a935ed820602b57820a418
Fixed an issue where booking a resource-based appointment could incorrectly reduce availability for a staff member assigned as responsible. This prevents customers from being sent back to the calendar with an error when a user-based appointment slot should still be available.
Original PR description
In [1], we introduced capacity for users. Therefore, capacity is handled by using booking lines, with capacity reserved / used set on them. However, unlike the resources, the user is not stored and…
In [1], we introduced capacity for users. Therefore, capacity is handled by using booking lines, with capacity reserved / used set on them. However, unlike the resources, the user is not stored and is related as the responsible (user_id) of the meeting instead. This has a side effect: if there are resource booking lines on a meeting, and a responsible is set (manually or the appointment type creator as a default responsible, as done in appointment module), then those booking lines may end up counting as booked capacity for the responsible as well! Therefore, we now make sure that the appointment type linked to the meeting is scheduled based on users when searching for booking lines in the remaining capacity computation. STEPS TO REPRODUCE ================== 0. Create a new db and install website_appointment 1. Log in as mitchell Admin 2. Create an appointment_type R based on resources, with a resource R1 and an appointment_type U based on users, with only Mitchell Admin set as staff user 3. Log out and book R on a given slot S 4. Once done, go to appointment U and try to book the same slot S 5. Once you submit the form, you are brought back to the calendar selection screen with an error message (code 'failed-staff-user') TEST ==== A test is added covering most cases, both when getting slots and when directly measuring the user's remaining capacity. 1: https://github.com/odoo/enterprise/commit/bce7e94650c337a9046958a7689c81db5b2a4c73 Task-5080374 Forward-Port-Of: odoo/enterprise#94339
Fixes an issue where customers could see an Internal Server Error when adding a Stripe payment method. Validation-only payment setup is now handled correctly, improving the reliability of saving payment methods without affecting normal payments.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Configure Stripe; 2. go to `/my/payment_method`; 3. create a payment token. Issue ----- > Internal Server Error Cause ----- Commit 5db75d32d718a added a…
Versions
--------
- saas-18.4+
Steps
-----
1. Configure Stripe;
2. go to `/my/payment_method`;
3. create a payment token.
Issue
-----
> Internal Server Error
Cause
-----
Commit 5db75d32d718a added a method that compares notification data values to the transaction values. For most operations, the structure of Stripe notification data is similar, but for `SetupIntent` responses, these don't include an amount or currency value (unless the currency is supported by Indian eMandates, in which case it's part of a `mandate_options` dict)[^1].
The error is the result of `payment_data.get('currency').upper()`. Because there is no currency value, `upper` gets called on `None`.
Additionally, when the transaction amount is zero (as is expected for validation operations), the base `_compare_notification_data` method assumes the amount is missing, throwing a validation error.
[^1]: https://docs.stripe.com/api/setup_intents/confirm
Solution
--------
- Skip comparing notification data for validation transactions.
- If the `currency` value is in fact missing unexpectedly, fall back on the empty string, so that we get to the intended validation error.
opw-5008858
Forward-Port-Of: odoo/odoo#222591The Spanish balance sheet now avoids counting accounts 551 and 5525 twice under Other Current Payables. This prevents overstated payable amounts and gives finance teams a more accurate report when reviewing company liabilities.
Original PR description
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from…
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from *Accounting → Reporting → Balance Sheet*. **Observed behavior:** - In the Balance Sheet, under *3. Other Current Payables*, the amount shown is double the journal entry. - Drilling down shows the correct amount in the journal entry, but the Balance Sheet line is overstated. **Root cause:** * In the expression for *3. Other Current Payables*, accounts **551** and **5525** were included twice: * once in credits and again in the balance, leading to double counting. **Reference:** * BOE: https://www.boe.es/eli/es/rd/2007/11/16/1514/con#cuenta * PR with related changes: [odoo/enterprise#82447](https://github.com/odoo/enterprise/pull/82447) **Solution:** - Removed accounts 551 and 5525 from the balance calculation to prevent duplication. opw-5056965 Forward-Port-Of: odoo/enterprise#94310
A failing automated test for journal reports has been corrected so it no longer depends on payment reference behavior that can vary by country localization. This helps keep builds reliable when Czech accounting localization is installed, reducing false test failures without changing user-facing features.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#94554
Product page links now remove product option values that do not apply to the selected product. This keeps customer-facing URLs clearer and avoids confusing shoppers or search engines with irrelevant parameters.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Service products in Indian POS GST reports are now reported with a quantity of zero, as required by the GST portal. This prevents validation errors during filing while keeping goods quantities unchanged.
Original PR description
Before this PR: - Service products in POS GSTR lines were reported with their actual quantity. - This caused GST portal validation error: `RET191355: The Quantity entered is not valid`. After this PR: - For service-type products, `qty` is always set to `0`. - For goods, `qty` continues to reflect the actual ordered quantity. OPW: 5070636 Forward-Port-Of: odoo/enterprise#94522 Forward-Port-Of: odoo/enterprise#94272
The rental search form no longer starts a search automatically when shoppers adjust rental dates. This prevents unexpected page updates and gives customers clearer control, while also making the search button more visually prominent.
Original PR description
Steps to reproduce: 1. Navigate to the rental search snippet on the website. 2. Modify the date range using the date picker. 3. Observe that the search is triggered automatically, which is not the desired behavior. After this commit: - Updated the search button style to use the primary color. - Made the search trigger only when the button is clicked, preventing automatic activation when the date range is modified.
The website editor now uses the proper internal source for a timing helper used by Google Maps options. This prevents an inappropriate testing dependency from being pulled into the website feature, reducing the risk of editor issues without changing user-facing behavior.
Original PR description
The commit 47e971086ea57219a628a99d35e36354c71a4192 uses `Deferred` in the implementation of the google maps options plugin. But imported it from hoot. This commit fixes the import to use `concurrency.js` instead. task-4367641 Forward-Port-Of: odoo/odoo#226811
This fix prevents an error when users create Mexican customer credit notes and enter a CFDI Origin. It helps accounting teams save these documents reliably without being blocked by a system error.
Original PR description
Currently, an error occurs when creating a customer credit note with a CFDI Origin.
**Steps to reproduce:**
- Install the `l10n_mx_edi` module and switch to `ESCUELA KEMPER URGATE` company.
- Navigate to: Invoicing > Customers > Credit Notes > New.
- Set `CFDI Origin` to `01|E19C50D2-1292-5817-BDDE-2666967C7471` and click `Save`.
**Error:**
`TypeError: unhashable type: 'list'`
**Root Cause:**
At [1], the code incorrectly uses `relationado_data['03', []]` instead of `relationado_data.get('03', [])`. The tuple `('03', [])` is treated as a dictionary key, which leads to an `error`.
**Fix:**
This commit ensures users can correctly set the CFDI Origin.
[1]
https://github.com/odoo/enterprise/blob/14b31a3631a97dd61ebd662fb768485e5a509c2c/l10n_mx_edi/models/account_move.py#L500
sentry-6823395705
Forward-Port-Of: odoo/enterprise#92876This fixes a display issue in the website product comparison feature where the expanded comparison panel could appear hidden behind the floating bar on mobile devices. Shoppers can now view and use the comparison bar properly when it is opened.
Original PR description
This PR increase the `z-index` property of the `collapse` element within the comparison bottom bar when open. | 19.0 and above | This PR | |--------|--------| | <img width="466" height="852" alt="image" src="https://github.com/user-attachments/assets/04cad4c6-b40f-402f-b667-5f3393f5a082" /> | <img width="489" height="844" alt="image" src="https://github.com/user-attachments/assets/39a289ca-26c4-47c4-a15a-121d5387acb6" /> | Prior to this PR, we set the `z-index` to `3`, which is below the `4` of the floating bar. While this solved an issue on desktop, it introduced a new one on mobile, where the collapse would unfold UNDER the floating bar. With this PR, we change the `z-index` when the collapse is open so it is greater than the floating bar one. task-5086473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can no longer add signature fields before a PDF page is ready, preventing errors during document setup. Cleanup of temporary page elements is now handled more safely, improving stability when PDF pages reload.
Original PR description
Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading. Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically. task-5065598 Forward-Port-Of: odoo/enterprise#94666 Forward-Port-Of: odoo/enterprise#94001
This fixes an issue where quote calculator spreadsheet filters could be changed before older data was updated to the current format. Sales teams get more reliable quote calculations and filtering when opening or using existing spreadsheets.
Original PR description
Commit odoo/odoo@dddcd8919f02e458219443afbc560ca2fbad6d1e changed the way global filter values are represented in the json data. Any data in a prior version undergo a "client-side upgrade". However the quote calculator action was changing the data before it was upgrade with the new representation.
Miscellaneous changes
Related: https://github.com/odoo/enterprise/pull/94469 Related: https://github.com/odoo/design-themes/pull/1145
Original PR description
Related: https://github.com/odoo/enterprise/pull/94469 Related: https://github.com/odoo/design-themes/pull/1145
Related: https://github.com/odoo/odoo/pull/226599 Related: https://github.com/odoo/design-themes/pull/1145
Original PR description
Related: https://github.com/odoo/odoo/pull/226599 Related: https://github.com/odoo/design-themes/pull/1145
1 change
Resolved issues and error corrections
The favorite search option now lets users select both available checkboxes at the same time. This fixes confusing behavior where the options acted like radio buttons, so users no longer have to choose only one when both should apply.
Original PR description
With this change, both boxes can be checked at the same time. Previously, they behaved like radio buttons, but now they will work as proper checkboxes. Description of the issue/feature this PR addresses: https://github.com/odoo/odoo/issues/224909 With this change, both boxes can be checked at the same time. Previously, they behaved like radio buttons, but now they will work as proper checkboxes. 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