Daily updates from Odoo
Tuesday, September 30, 2025
155 changes
21 changes
Resolved issues and error corrections
This fix ensures temporary database counters created for self-order point-of-sale sessions are removed once a session is closed. It helps prevent unnecessary database clutter over time, supporting smoother system maintenance without changing the user experience.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229069 Forward-Port-Of: odoo/odoo#223758
The payment wizard now checks the bank account the user actually selects, rather than only the account originally tied to the bill. This prevents unnecessary warning banners when a trusted bank account is chosen for SEPA vendor payments.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two…
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. * added testcase for the same in account_iso20022 [#95124](https://github.com/odoo/enterprise/pull/95124) opw-5059740 Forward-Port-Of: odoo/odoo#227404
The CRM periodic digest now shows the correct number of free credits for targeted lead generation. This prevents customers from seeing an overstated offer and helps keep product communication accurate.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
This fixes an issue in Odoo's web testing tools where creating records linked through many-to-many relationships could fail. The change improves reliability for automated tests and helps prevent false errors during development and quality checks.
Original PR description
Before this commit, using CREATE Command on a many2many field would result in an error. This is because upon record creation the inverse field would be set to the single id, which is incorrect for a many2many field. This commit fixes the issue by setting the inverse field of a many2many to a list containing the new id. Forward-Port-Of: odoo/odoo#208524
Fixed an issue where opening the barcode scanner in Attendance kiosk mode could trigger an error when debug mode was enabled. This keeps the kiosk scanning flow stable for administrators and users testing or troubleshooting the Attendances app.
Original PR description
**Step to reproduce:** - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode - open the scanner **Observation:** - We get a traceback **Cause:** - we pass a extra prop `token` to BarcodeDialog component, which is not accepted by it https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L12 - this raises issue from OWL when we have debug-mode on **Fix:** - reuse the actual `scanBarcode` method and remove the faulty one. https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L47-L60 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227551 Forward-Port-Of: odoo/odoo#225738
The SEPA payment flow now checks the bank account actually selected by the user before showing a trust warning. This prevents incorrect warning banners when a trusted account is chosen, reducing confusion during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Arabic invoice reports for Saudi Arabia now display the description column with consistent alignment alongside the other invoice columns. This improves readability for users printing or sharing localized invoices without changing invoice data or workflow.
Original PR description
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The…
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The description column is misaligned in the Arabic invoice report. According to Saudi localization, it should be aligned to the left for better readability. The current alignment makes Arabic text inconvenient to read. **Cause:** - Other columns (e.g., quantity, taxes) already use the `text-end` class, but the description column has no alignment class, causing inconsistent layout and misalignment. **Solution:** - Added the `text-end` class to the description column to ensure proper alignment and consistent readability in Arabic invoice reports. **Before FIX:** <img width="831" height="329" alt="image" src="https://github.com/user-attachments/assets/857f9f7f-d930-4c73-b2fa-eacd7a153ea3" /> **After FIX** <img width="788" height="354" alt="image" src="https://github.com/user-attachments/assets/929acdb1-bb13-4e1e-829c-8fdbe18334a4" /> **opw-5087770** Forward-Port-Of: odoo/odoo#228118
This fix prevents an error from appearing when users change a website theme color and then save their changes. It improves the reliability of the website editing experience by handling the save process correctly.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146 Forward-Port-Of: odoo/odoo#227946
The forum page cover block can now be selected and edited in the website builder. This restores expected editing behavior for website managers, making it easier to customize forum pages without workarounds.
Original PR description
Steps to reproduce: - Go to the "/forum" page and click "Edit". - Click the "s_cover" block. - Bug: the snippet is not editable. The cover snippet contains a link rendered with "t-attf-href", which makes the website builder refuse to mark the block as editable. This commit adds "t-ignore="True"" on the "oe_structure" so the branding stops before reaching the link and the snippet becomes editable again. task-5095234 Forward-Port-Of: odoo/odoo#227724
This update makes sure errors raised during automated tests are properly detected and reported. It helps improve product quality by preventing problems from being silently ignored before release.
Original PR description
This commit follows a community fix that restores proper error handling within and outside of unit tests. As such, it fixes tests reporting errors that were previously not picked up. Community PR: https://github.com/odoo/odoo/pull/228836
The internal web test runner now treats errors and warnings with clearer severity levels, so problems are reported appropriately depending on when they occur. This helps prevent test issues from being missed or from unnecessarily stopping test runs, improving confidence in automated quality checks.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228674
Users who open a product’s View Diagram without a warehouse configured for their company will now see a helpful warning instead of an error. This prevents a confusing crash and guides users toward completing warehouse setup.
Original PR description
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2)…
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2) Navigate to Inventory>Configuration>Warehouses and create a new Warehouse. 3) Create a new company and switch to that company. 4) Navigate to Inventory>Products>Products 5) Open any product and click on 'View Diagram' in the 'inventory tab'. **Error:** `AttributeError: 'bool' object has no attribute 'origin'` **Root Cause:** On following above steps, `default_get` method is called. At [1], it attempts to fetch the ID of the warehouse. Because Odoo does not create a default warehouse for a newly created company, the value received by `res` at [2] looks like `[(6, 0, ['False'])]` which causes an error during further computation. **Fix:** Raise a `Redirect Warehouse Warning` when clicking 'View Diagram' if no warehouse is found. [1]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L35 [2]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L36 **Note**: not adding a test case, as the issue is not reproducible in test mode as default warehouse is created for a company in the test mode https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 sentry-6575082178 Forward-Port-Of: odoo/odoo#227810
Helpdesk team tag assignment now only shows internal users when selecting team members. This prevents portal users from being assigned to ticket dispatch rules by mistake, keeping automatic assignment setup accurate.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188** Forward-Port-Of: odoo/enterprise#95264
The website now keeps video size placeholders hidden until visitors accept optional cookies. This prevents blocked video areas from appearing incorrectly and keeps the page behavior aligned with privacy choices.
Original PR description
Commit [958b41c] introduced a way not to load videos if the user did not accept optional cookies. In doing so, the "video size" container was hidden. However, since [b9b3a60], the code was wrong: - Instead of a proper handler, the `optionalCookiesAccepted` listener wasn't a listener at all and immediately removed `d-none` on `media_iframe_video_size`. - It was all done in the `setup` instead of the `start` or `dynamicContent`. [958b41c]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1 [b9b3a60]: https://github.com/odoo/odoo/commit/b9b3a605e0f4c5da3a258c980107d6162da7f44f Forward-Port-Of: odoo/odoo#226817
This update ensures the main DATEV account is only assigned to companies based in Germany, preventing incorrect reporting setup for companies in other countries. It also improves how debit and credit lines are gathered, making the process more efficient for larger accounting entries.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
The task list now shows the allocated hours field even when the value is zero, so users can edit it directly during bulk task updates. This removes a small usability blocker for planning and timesheet management.
Original PR description
Before this commit, when the user would like to edit the allocated hours field of multiple tasks inside the list view, he cannot when the allocated hours is equal to 0. The reason is because the cell is hidden once the value is equal to 0. This commit makes that field is always editable in the list view of tasks even if the value is 0. task-5093288 Forward-Port-Of: odoo/odoo#228862 Forward-Port-Of: odoo/odoo#228188
This fixes an e-invoicing issue where OIN identifiers of a specific length could be marked with the wrong scheme code. It helps ensure BIS3 and NLCIUS electronic invoices are generated with the correct recipient identification, reducing rejection or compliance issues.
Original PR description
We previously [1] fixed the EAS that was incorrectly set to 0106 instead of 0190 in case of OIN (lenght = 20). This fix was overriden in the backport of the 19.0 dict helpers [2]. [1]: https://github.com/odoo/odoo/pull/219424 [2]: https://github.com/odoo/odoo/pull/215610 opw-5107445 Forward-Port-Of: odoo/odoo#228624
This fix removes a remaining source of unpredictable behavior in an automated Web Studio rename test. It helps keep quality checks stable, reducing false failures during development and release validation.
Original PR description
Similar to https://github.com/odoo/enterprise/commit/5574c52df8794b3f23d385a670cac8fb5355e229 There was still one indeterminism remaining runbot-232572 Forward-Port-Of: odoo/enterprise#95447
This fix keeps the website preview consistent after changing page styling, such as boxed layout or background color. It prevents a brief flicker of the previous design when the preview reloads, giving website editors a smoother and more reliable editing experience.
Original PR description
In this [commit], fallback iframe was added to avoid flickering between iframe reloads. But the flicker still happens if we change page's style, since we do not apply the new styles to the fallback iframe. To reproduce the issue: - Open Website and start editing - Move to the 'Theme' tab - Change page layout to 'Boxed' - Set background color to a non-transparent color, e.g. red - Save, and do any action to reload the iframe, e.g. go to /contactus => The iframe flickers from the previous color to red, which shouldn't be the case. Task-4985472 [commit]: https://github.com/odoo/odoo/commit/7b19831e1c624b483008feb526ba773ec8b23009 Forward-Port-Of: odoo/odoo#221391
This fix prevents an error when users open the General Ledger from the Trial Balance while working with multiple companies in Developer Mode. It ensures the report search opens correctly instead of showing a traceback, improving reliability for accounting users.
Original PR description
**Issue** When multiple companies are selected and Developer Mode is enabled, clicking "View General Ledger" for an account in the Trial Balance leads to a traceback. This affects accounts whose code is hidden. **Steps to Reproduce** 1. Go to Accounting > Reporting > Trial Balance. 2. Select multiple companies. 3. Click on an account where the account code is not visible. 4. From the three-dot menu, select "View General Ledger". 5. Observe the traceback error. **Root Cause** The error occurs because the `AccountReportSearchBar` component expects a string `initialQuery` prop, but in the multi-company scenario with developer mode enabled, the value passed can be `undefined` or non-string. Owl's strict prop validation then throws an `OwlError`, leading to the traceback. **Fix** Ensure that `initialQuery` is always a string when passed to `AccountReportSearchBar`. Opw-5050843 Forward-Port-Of: odoo/enterprise#94104
This fix ensures packaging details entered on a product are correctly carried over to its product variant, including products without attribute options. This prevents missing or inconsistent packaging information for users managing products and sales operations.
Original PR description
e158730ba16e898a13dd9a98ed96fa30fa95ab6f recently fixed a situation where one-variant products had duplicated packagings. In the aforementioned commit, we concluded that the logic to write (again) the templates values for variant-stored fields was useless because already applied to the generated variants. Nevertheless, while trying to remove in master this logic, we noticed that those varlues are only applied to variants of templates having at least one attribute line, whose creation will trigger the variants creation. This commit therefore partially reverts the previous commit, bringing back the first solution that is still the best approach in the end. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229080
15 changes
Resolved issues and error corrections
The CRM Periodic Digest tip now states the correct number of free credits for targeted lead generation. This avoids misleading users by changing the communicated amount from 200 credits to the actual 20 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
This update corrects how the web mock server handles creating linked many-to-many records. It prevents test errors by storing the new relationship in the expected list format, improving reliability of web feature validation.
Original PR description
Before this commit, using CREATE Command on a many2many field would result in an error. This is because upon record creation the inverse field would be set to the single id, which is incorrect for a many2many field. This commit fixes the issue by setting the inverse field of a many2many to a list containing the new id. Forward-Port-Of: odoo/odoo#208524
The payment registration flow now checks the bank account the user actually selects, not only the account originally linked to the invoice. This prevents an incorrect warning from appearing when a trusted bank account is chosen for SEPA vendor payments.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two…
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. * added testcase for the same in account_iso20022 [#95124](https://github.com/odoo/enterprise/pull/95124) opw-5059740 Forward-Port-Of: odoo/odoo#227404
SEPA payment registration now checks the bank account the user actually selects, rather than only the account originally linked to the bill. This prevents unnecessary warning banners when a trusted account is chosen, reducing confusion during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Fixes an error that could occur when users changed a website theme color from the color palette and then saved. This improves reliability of website editing and helps prevent interruptions during design updates.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146 Forward-Port-Of: odoo/odoo#227946
This fixes an issue that prevented website editors from modifying the cover block on the forum page. Forum page content can now be edited normally in the website builder, reducing friction for teams maintaining their community pages.
Original PR description
Steps to reproduce: - Go to the "/forum" page and click "Edit". - Click the "s_cover" block. - Bug: the snippet is not editable. The cover snippet contains a link rendered with "t-attf-href", which makes the website builder refuse to mark the block as editable. This commit adds "t-ignore="True"" on the "oe_structure" so the branding stops before reaching the link and the snippet becomes editable again. task-5095234 Forward-Port-Of: odoo/odoo#227724
This fixes a website display issue where the video size placeholder could appear even when visitors had not accepted optional cookies. The change keeps video-related elements hidden until consent is given, improving privacy compliance and avoiding confusing page content.
Original PR description
Commit [958b41c] introduced a way not to load videos if the user did not accept optional cookies. In doing so, the "video size" container was hidden. However, since [b9b3a60], the code was wrong: - Instead of a proper handler, the `optionalCookiesAccepted` listener wasn't a listener at all and immediately removed `d-none` on `media_iframe_video_size`. - It was all done in the `setup` instead of the `start` or `dynamicContent`. [958b41c]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1 [b9b3a60]: https://github.com/odoo/odoo/commit/b9b3a605e0f4c5da3a258c980107d6162da7f44f Forward-Port-Of: odoo/odoo#226817
Arabic invoice reports for Saudi Arabia now display the description column with consistent alignment. This makes printed invoices easier to read and better aligned with local presentation expectations.
Original PR description
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The…
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The description column is misaligned in the Arabic invoice report. According to Saudi localization, it should be aligned to the left for better readability. The current alignment makes Arabic text inconvenient to read. **Cause:** - Other columns (e.g., quantity, taxes) already use the `text-end` class, but the description column has no alignment class, causing inconsistent layout and misalignment. **Solution:** - Added the `text-end` class to the description column to ensure proper alignment and consistent readability in Arabic invoice reports. **Before FIX:** <img width="831" height="329" alt="image" src="https://github.com/user-attachments/assets/857f9f7f-d930-4c73-b2fa-eacd7a153ea3" /> **After FIX** <img width="788" height="354" alt="image" src="https://github.com/user-attachments/assets/929acdb1-bb13-4e1e-829c-8fdbe18334a4" /> **opw-5087770** Forward-Port-Of: odoo/odoo#228118
This fixes a point-of-sale display issue where the Order button appeared highlighted after a self-order had already been sent for preparation. Staff now see a more accurate order status when opening self-orders from the ticket screen, reducing confusion during service.
Original PR description
In the POS UI, the "Order" button was wrongly highlighted when loading a self-order, even though it had already been sent Steps to reproduce: - Create an order using self-order mobile (or kiosk). - Open the related POS terminal. - Load the self-order from the ticket screen. - Notice the "Order" button remains highlighted. Fix: - Ensure the last order changes updated when loading self-order in pos Task: 5005161 Forward-Port-Of: odoo/odoo#223560
Tasks now show the allocated hours field in list view even when the value is 0. This lets users update planned time across multiple tasks without being blocked by hidden empty-hour cells.
Original PR description
Before this commit, when the user would like to edit the allocated hours field of multiple tasks inside the list view, he cannot when the allocated hours is equal to 0. The reason is because the cell is hidden once the value is equal to 0. This commit makes that field is always editable in the list view of tasks even if the value is 0. task-5093288 Forward-Port-Of: odoo/odoo#228862 Forward-Port-Of: odoo/odoo#228188
This fix restores the correct electronic invoicing code for Dutch OIN identifiers with 20 digits. It helps ensure BIS3 and NLCIUS invoices use the expected identifier format, reducing the risk of rejected or incorrectly processed e-invoices.
Original PR description
We previously [1] fixed the EAS that was incorrectly set to 0106 instead of 0190 in case of OIN (lenght = 20). This fix was overriden in the backport of the 19.0 dict helpers [2]. [1]: https://github.com/odoo/odoo/pull/219424 [2]: https://github.com/odoo/odoo/pull/215610 opw-5107445 Forward-Port-Of: odoo/odoo#228624
Users viewing a product's inventory diagram in a newly created company without a configured warehouse will no longer hit an unexpected error. Instead, Odoo now shows a helpful warehouse setup warning, guiding users to fix the missing configuration.
Original PR description
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2)…
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2) Navigate to Inventory>Configuration>Warehouses and create a new Warehouse. 3) Create a new company and switch to that company. 4) Navigate to Inventory>Products>Products 5) Open any product and click on 'View Diagram' in the 'inventory tab'. **Error:** `AttributeError: 'bool' object has no attribute 'origin'` **Root Cause:** On following above steps, `default_get` method is called. At [1], it attempts to fetch the ID of the warehouse. Because Odoo does not create a default warehouse for a newly created company, the value received by `res` at [2] looks like `[(6, 0, ['False'])]` which causes an error during further computation. **Fix:** Raise a `Redirect Warehouse Warning` when clicking 'View Diagram' if no warehouse is found. [1]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L35 [2]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L36 **Note**: not adding a test case, as the issue is not reproducible in test mode as default warehouse is created for a company in the test mode https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 sentry-6575082178 Forward-Port-Of: odoo/odoo#227810
Helpdesk team member selection now only shows internal users when configuring automatic ticket assignment by tags. This prevents portal users from being assigned to internal helpdesk workflows by mistake, keeping team setup clearer and more reliable.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188** Forward-Port-Of: odoo/enterprise#95264
This fix ensures the main DATEV account is only applied to companies based in Germany, preventing incorrect accounting setup for companies in other countries. It also improves how debit and credit lines are gathered, making the related reporting process more efficient.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
This fixes an error that could prevent users from saving certain views or Web Studio reports when an attribute entry had no name. The system now safely skips those incomplete attributes, improving reliability when editing custom views.
Original PR description
Currently, an error occurs when user tries to save a view with an attribute node without name. **Steps to replicate:** - Initialize a DB and open Views. - Create a new view and fill in random values…
Currently, an error occurs when user tries to save a view with an attribute node without name.
**Steps to replicate:**
- Initialize a DB and open Views.
- Create a new view and fill in random values for name and give a View Type.
- In the Architecture give value as `<attribute></attribute>`.
- Save and you will get the error.
(Same error can also be produced with Web Studio report editor.)
**Error:**
`AttributeError: 'NoneType' object has no attribute 'endswith'`
**Cause:**
- The error occurred because we received **key** as `None` at [1], as it was called from an attribute node with no name [2].
- In `saas-18.2`, we only checked if `node.get('name') not in TRANSLATED_ATTRS`. Since `node.get('name')` was `None` and `None` was not included in the `TRANSLATED_ATTRS` list, no error occurred.
**Solution:**
- Added a conditional check, so that attributes with no name skip the function call.
[1]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L83
[2]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L190
[3]: https://github.com/odoo/odoo/blob/0b700ec3c08ecd9c6f1597f9d10f6c1eee06bcee/odoo/tools/translate.py#L255
sentry-6877030439
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr4 changes
Resolved issues and error corrections
Sales orders no longer keep an outdated quote calculator after the quotation template is changed. This prevents users from relying on calculator data from the previous template and keeps the sales order aligned with the selected template.
Original PR description
Step to reproduce: - Create a new SO - Add a customer and quotation template to the order - Click on quote calculator smart button - Return to sale order (click on SO number in top left) - Change the quotation template - Result: it does not change the quote calculator that is linked to the new quotation template Cause: - Clicking on Quote Calculator creates a copy of the quotation template spreadsheet and links it to the SO. https://github.com/odoo/enterprise/blob/8bc6098335d283e6d210dc788463a8ef8c559b14/spreadsheet_sale_management/models/sale_order.py#L30-L35 - When the quotation template is later changed, the spreadsheet linked to the old template remains attached to the SO. Fix: - On changing the sale_order_template, the old spreadsheet should be unlinked from the SO. - Keeping it linked is inconsistent, as it does not matches the current template opw-4998587 Forward-Port-Of: odoo/enterprise#93970
The SEPA payment flow now checks the bank account actually selected by the user, rather than only the account originally linked to the invoice. This prevents unnecessary warning banners when a trusted bank account is chosen, improving confidence during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
This fix ensures the main DATEV account is only set for companies based in Germany, preventing incorrect accounting setup for companies in other countries. It also improves how debit and credit lines are processed, making the German reports feature more efficient.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
This fix removes a remaining source of inconsistent behavior in an automated Studio rename test. It helps keep validation stable so future changes can be checked more reliably without affecting daily users.
Original PR description
Similar to https://github.com/odoo/enterprise/commit/5574c52df8794b3f23d385a670cac8fb5355e229 There was still one indeterminism remaining runbot-232572 Forward-Port-Of: odoo/enterprise#95447
24 changes
Resolved issues and error corrections
This fixes visibility issues in dark mode for appointment and point-of-sale screens. Icons and text now use colors that remain readable across light and dark themes, making the interface easier to use.
Original PR description
In this commit: ------------------- - Added a dark mode color for the star icon. - Changed the text color to white in light mode, which is reflected as black in dark mode. This fixes the issue of the text not being properly visible in dark mode. task:4943078 Forward-Port-Of: odoo/enterprise#95673 Forward-Port-Of: odoo/enterprise#93993
When the AI feature cannot scrape a webpage, the system now records it as a warning instead of an error. This better reflects that the issue is already shown to the user and does not block the overall process, helping reduce unnecessary error alerts.
Original PR description
Currently, an error can occur on unsuccessful scrapping of URL.
**Error:**
`Error scraping URL https://agenciavirtualpy.com: HTTPError('403 Client Error: Forbidden for url: https://agenciavirtualpy.com/')`
- Instead of logging an error, we log only warning during unsuccessful URL
scraping because it is not a blocking point in the code.
- On unsuccessful scraping, we log warnings [1] and raise a UserError [2] to
inform the user about the failed URL scraping. Therefore, we should log a
warning as the UserError is already present.
[1]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L258
[2]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L283-L285
sentry-6634525990
Forward-Port-Of: odoo/enterprise#94960
Forward-Port-Of: odoo/enterprise#94002The Spanish Mod 349 tax report now correctly shows the underlying invoice details when users audit the summary line for intra-community operations. This helps accounting teams verify reported amounts more reliably and reduces manual investigation when reviewing tax filings.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
The partner ledger now keeps names and expand arrows properly aligned on phones and tablets. This makes the report easier to read and use on smaller devices without changing its underlying data or behavior.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317
This fixes naming inconsistencies introduced during a previous refactor of Indian GST reporting. The change helps keep India-specific reporting logic isolated so it does not interfere with other localizations, improving reliability for tax reporting workflows.
Original PR description
Following the refactor-https://github.com/odoo/enterprise/commit/3722e9255647254a078166c5ea9696cbf7818147 and removal of `l10n_in.gst.return.period` and adapting the `account.report` since it's no longer an Indian Localisation model the method names not renamed to the localisation specific in this commit we fix that so other localisation are aren't affected Forward-Port-Of: odoo/enterprise#94441
Planning now shows a valid allocated percentage for employees using flexible or fully flexible work schedules when grouped by resource and role. This prevents confusing 'NaN' values from appearing in the schedule view and gives managers clearer staffing information.
Original PR description
Steps to reproduce: ==== - Install the Planning module. - Go to Planning and apply two level group by: Resources ⇒ Role. - Ensure some employees (e.g., AKA Foster) are assigned a 'Flexible Hours'…
Steps to reproduce: ==== - Install the Planning module. - Go to Planning and apply two level group by: Resources ⇒ Role. - Ensure some employees (e.g., AKA Foster) are assigned a 'Flexible Hours' work schedule. Issue: === When grouping by Resource ⇒ Role, employees with flexible hours display 'NaN' instead of a valid allocated percentage. Cause: ==== Flexible and fully flexible resources do not have predefined work intervals in their schedules. The calculation previously relied on work_intervals to compute 'workHours', which is undefined for flexible users, resulting in 'NaN' in the UI. Fix: === The issue is resolved by using avg_hours instead of work_intervals for flexible and fully flexible resources. Additionally, the necessary change has been added to handle fully flexible schedules as well. Since both flexible and fully flexible resources lack scheduled intervals, their avg_hours serve as a reliable value for computing 'workHours', preventing the display of NaN. task-4968436 Forward-Port-Of: odoo/enterprise#91436
When a signer is no longer assigned in a Sign template, the sidebar now removes the old profile picture instead of showing a stale avatar. This keeps the signer information accurate and avoids confusion for users preparing documents for signature.
Original PR description
Issue: - In the template iframe view, when editing a signer’s settings, removing the "Assign To" field did not clear the profile picture. - As a result, the previous avatar remained visible in the sidebar even though no user was assigned. Fix: - Updated `updateRoleNameAndAvatar` to reset the `profilePic` state to an empty string when `assignTo` is removed. Impact: - The profile picture is now correctly hidden when no signer is assigned, ensuring the sidebar always reflects the current state of the signer. Steps to reproduce: 1. Open the signer settings dialog in the template view. 2. Clear the `Assign To` field. 3. Save the dialog. Forward-Port-Of: odoo/enterprise#95743
This fix exposes the company country code in payroll configuration settings. It helps the system access the correct country context from settings, reducing configuration-related errors during setup or processing.
Original PR description
Add a related field in res.config.settings to expose country_code build_error-231405
Payroll settings now include the company country code needed by the configuration view. This prevents upgrade validation errors and access-rights inconsistencies, helping payroll setup remain stable during module updates.
Original PR description
The payroll settings view referenced `country_code` in its invisibility condition, but the field was missing from `res.config.settings`. This caused a validation error and access rights inconsistency during module upgrade. A related field `country_code` has been added, pointing to `company_id.country_id.code`. build_error-231409
This fix prevents errors when upgrading the Lithuanian payroll module by ensuring the payroll settings screen has the country information it expects. It improves reliability for companies using Lithuanian payroll without changing day-to-day payroll features.
Original PR description
The payroll settings view referenced `country_code` in its invisibility condition, but the field was missing from `res.config.settings`. This caused a validation error and access rights inconsistency during module upgrade. A related field `country_code` has been added, pointing to `company_id.country_id.code`. build_erro-231395
Documents can now create server actions that generate journal entries for journals marked as Credit Card. This fixes a gap that prevented users from setting up credit card statement workflows through Documents.
Original PR description
We are unable to create an action to create a credit card statement on a journal with type credit card Allow to create a Server Action to create Journal Entries in journals of type "Credit Card" in Documents. task-5123868
The SEPA payment flow now checks the bank account actually selected by the user, not only the account originally linked to the bill. This prevents unnecessary warning banners when a trusted account is chosen, improving confidence during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Helpdesk team tag assignment now only lets internal users be selected as team members. This prevents portal users from being accidentally assigned to handle tickets, keeping automatic ticket dispatch aligned with staff responsibilities.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188** Forward-Port-Of: odoo/enterprise#95264
This fix ensures the main DATEV account is only assigned for companies based in Germany, preventing incorrect accounting setup for non-German companies. It also improves how debit and credit lines are gathered, making the report logic more efficient for larger records.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
This fixes an issue where General Ledger lines using custom grouping could not be expanded to show details. Businesses using tailored report groupings can now drill into their accounting data as expected.
Original PR description
Before when we added different groupby on the gl line than the default ones, that would not be unfoldable by default. This is due to a default dict that set has_sublines to False by default and it would never be set to true for groupby other than the default ones. Forward-Port-Of: odoo/enterprise#95545
The ESG Database menu no longer offers a direct create option, reducing confusion about unsupported automatic database imports. Users can still create database records from emission factors when they need to manually classify custom emission factors.
Original PR description
Before this commit, when the user goes to Database menu inside ESG app, the user can create a database if he wants. However, when he creates a database, he might think it can add the link of the database to automatically fetch the data, but this system is not implemented because each database has its own formatting. This commit disables the create action inside that menu to avoid confusing the user. However, he can still create a database inside a emission factor if he wants to classify his emission factors manually created. task-5117594 Forward-Port-Of: odoo/enterprise#95613
Customers renting products on the website will now see the correct stock warning when availability is limited. This helps prevent confusion during checkout and reduces the risk of orders being placed without clear availability information.
Original PR description
Introduced by 151349aeaf899a3b70534a0120a5f49882981d53, the `_set_shop_warning_stock` method was modified and is now supposed to return the applied warning. Forward-Port-Of: odoo/enterprise#95731
This fixes a remaining source of inconsistent automated test behavior in Web Studio's rename flow. It helps keep the development and release process stable by reducing false test failures, with no expected change for end users.
Original PR description
Similar to https://github.com/odoo/enterprise/commit/5574c52df8794b3f23d385a670cac8fb5355e229 There was still one indeterminism remaining runbot-232572 Forward-Port-Of: odoo/enterprise#95447
This update corrects an internal mismatch that caused a payroll test to fail for Indian localization fields. It ensures selected employee payroll fields remain consistently editable across employee records and their version history, reducing the risk of configuration issues.
Original PR description
The test `TestHrVersion.test_related_fields_on_version` was failing with:
(Readonly) Inconsistency between some employee fields and version ones.
for the following fields:
- l10n_in_medical_insurance_total
- l10n_in_provident_fund
- l10n_in_pf_employee_percentage
- l10n_in_pf_employer_percentage
- l10n_in_fixed_allowance
Cause:
- On `hr.employee`, these fields were defined as `related='version_id.<field>'` with `readonly=False`. On `hr.version`, the same fields were still implicitly readonly (due to being computed/related), creating a mismatch.
Solution:
- Explicitly set `readonly=False` on these fields on `hr.version` as well.
[RB-232577](https://runbot.odoo.com/odoo/error/232577)
Forward-Port-Of: odoo/enterprise#94914The account reports area now uses the label “Type” instead of “Category” for account return types. This fixes naming so the field better matches its purpose and reduces confusion for users working with returns.
Original PR description
Forward-Port-Of: odoo/enterprise#95183
Mexican payroll employee fields are now only visible to authorized HR payroll users. This prevents non-HR internal users from encountering access errors when viewing employee profile data and keeps payroll-related information appropriately limited.
Original PR description
The test `test_employee_fields_groups` crashed with: `AccessError: The fields "l10n_mx_regime_type,l10n_mx_shift_type, l10n_mx_payment_periodicity", which you are trying to read, are not available for employee public profiles.` These fields exist without HR group restriction as a result, a non-HR internal user calling `.read([])` triggered the `AccessError`. This commit adds `groups="hr_payroll.group_hr_payroll_user"` to these fields so they are only accessible to HR users, resolving the error. [RB-231737](https://runbot.odoo.com/odoo/error/231737)
This update adjusts a payroll-related test so it uses the right user permissions during setup. It helps keep automated checks reliable and prevents false build failures without changing business functionality.
Original PR description
to bypass the access right restriction in test build_error-230682
A naming error prevented a Mexican localization validation from running correctly after a related core function was renamed. This fix aligns the localization with the corrected function name so the intended invoice checks are active again in Odoo 19.
Original PR description
In odoo, The standard function _check_move_constraints had a typo, as it was missing the last t (_check_move_constrains). When it was inherited in this module, the function was left with the typo. In version 19, this typo was fixed in the standard function, but the Mexican localization function was left as it was, so the function was useless as it attempts to inherit a method that does not exist. In this PR, this typo is corrected so that the functionality also exists in 19. Task-id: 5119381 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95825
When a user deletes a message linked to an accounting report annotation, the related annotation is now removed as well. This keeps financial report notes accurate and avoids outdated comments remaining visible after the original message is deleted.
Original PR description
And improve a bit the tour to check the result to prevent cases where the tour would pass but something wouldn't be done right. Forward-Port-Of: odoo/enterprise#95750
28 changes
Resolved issues and error corrections
This fixes access handling for AI tools so they run under the appropriate system-level permissions. It prevents regular users from being blocked by missing access rights when AI features rely on internal server actions.
Original PR description
Tools are server actions to which normal users don't have access. (runbot.build.error/231672)
This fix updates India-specific GST reporting methods after a prior refactor so they no longer interfere with other localizations. It helps keep Indian GST returns, e-invoicing, and related point-of-sale reporting working correctly while reducing the risk of cross-country reporting side effects.
Original PR description
Following the refactor-https://github.com/odoo/enterprise/commit/3722e9255647254a078166c5ea9696cbf7818147 and removal of `l10n_in.gst.return.period` and adapting the `account.report` since it's no longer an Indian Localisation model the method names not renamed to the localisation specific in this commit we fix that so other localisation are aren't affected
The web interface no longer sends an extra date value when retrieving currency rates because the system already determines the correct date on the server. This avoids creating new cached records every day, helping control disk usage without changing user workflows.
Original PR description
The date parameter used for currency_rates fetches is removed since it is always computed server-side by default. This prevents unnecessary growth of the disk cache, which previously added at least one new entry every day.
The Spanish Mod 349 tax report now correctly shows the detailed entries behind the intra-community operations summary line during audit. This helps accounting users verify reported amounts and reduces confusion when checking EU transaction declarations.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
This fixes a case where resetting a Google Calendar account could fail because calendar event permission checks were still triggered. Account resets should now complete more reliably without unexpected validation errors.
Original PR description
This commit adds the last context key "skip_event_permission" to the remaining writes done to `calendar.event` records at the reset of google_calendar account, created at odoo/odoo#227991. By adding it, we'll no longer face any possibility of triggering a ValidationError during account resets of google_calendar. task-5103918 Forward-Port-Of: odoo/odoo#228520
The account reports area now labels account return types as “Type” instead of “Category.” This fixes wording so users see clearer, more accurate terminology when working with returns.
Fixes an issue where changing a website theme color from the palette could trigger an error when saving. This helps users customize website colors more reliably without interruptions.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146 Forward-Port-Of: odoo/odoo#227946
This change fixes the classification of Spanish chart of accounts entry 411 so it is treated as a current liability. This helps Spanish accounting reports and bookkeeping use the correct financial category.
Original PR description
Account 411 should be of 'liability_current' type --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Closed self-ordering point-of-sale sessions now remove an unused database sequence once it is no longer needed. This helps prevent unnecessary buildup in the database and keeps maintenance lighter without changing the customer-facing checkout experience.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229069 Forward-Port-Of: odoo/odoo#223758
The Danish Nemhandel module now prepares key partner information during installation instead of calculating it later during updates. This helps avoid long update times and makes module setup smoother for companies using Danish e-invoicing.
Original PR description
To avoid lengthy update due to the compute of the records by the ORM, let's pre-compute the nemhandel fields on the install of the module. 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#228102
The partner ledger now keeps names and navigation arrows properly aligned on smaller screens such as phones and tablets. This makes the report easier to read and use when working from mobile devices.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317
The web testing mock server now handles many-to-many record creation correctly. This prevents errors in automated tests and helps ensure relationship-based features behave reliably during development.
Original PR description
Before this commit, using CREATE Command on a many2many field would result in an error. This is because upon record creation the inverse field would be set to the single id, which is incorrect for a many2many field. This commit fixes the issue by setting the inverse field of a many2many to a list containing the new id. Forward-Port-Of: odoo/odoo#208524
This fixes an issue in the Mail app where replacing an item in a related record list could accidentally remove an extra item. The change helps keep message-related data lists accurate when records are updated in place.
Original PR description
Before this commit, when doing an indexed assignment (`array[index] = record`) on a Many field, it produces an incorrect result where an extra element of the record list would be deleted. This happens because we call a high-level delete on the inverse record before replacing the record, causing the list to shrink in size and causing the indexed assignment to replace the wrong record. This commit fixes the issue by changing the order of the assignment and deletion. fixes task-5090802 Forward-Port-Of: odoo/odoo#229005
A naming mistake prevented a Mexican localization validation from running in Odoo 19. This fix restores that check so Mexican electronic invoicing workflows use the intended safeguards.
Original PR description
In odoo, The standard function _check_move_constraints had a typo, as it was missing the last t (_check_move_constrains). When it was inherited in this module, the function was left with the typo. In version 19, this typo was fixed in the standard function, but the Mexican localization function was left as it was, so the function was useless as it attempts to inherit a method that does not exist. In this PR, this typo is corrected so that the functionality also exists in 19. Task-id: 5119381 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors can now select and modify the cover block on the forum page as expected. This removes a blocker in the page builder, making it easier to customize forum pages without technical help.
Original PR description
Steps to reproduce: - Go to the "/forum" page and click "Edit". - Click the "s_cover" block. - Bug: the snippet is not editable. The cover snippet contains a link rendered with "t-attf-href", which makes the website builder refuse to mark the block as editable. This commit adds "t-ignore="True"" on the "oe_structure" so the branding stops before reaching the link and the snippet becomes editable again. task-5095234 Forward-Port-Of: odoo/odoo#227724
This fixes a configuration mismatch that could block automated checks for Indian payroll employee information. The affected payroll fields now behave consistently across employee records and their version history, reducing the risk of errors during payroll data maintenance.
Original PR description
The test `TestHrVersion.test_related_fields_on_version` was failing with:
(Readonly) Inconsistency between some employee fields and version ones.
for the following fields:
- l10n_in_medical_insurance_total
- l10n_in_provident_fund
- l10n_in_pf_employee_percentage
- l10n_in_pf_employer_percentage
- l10n_in_fixed_allowance
Cause:
- On `hr.employee`, these fields were defined as `related='version_id.<field>'` with `readonly=False`. On `hr.version`, the same fields were still implicitly readonly (due to being computed/related), creating a mismatch.
Solution:
- Explicitly set `readonly=False` on these fields on `hr.version` as well.
[RB-232577](https://runbot.odoo.com/odoo/error/232577)Users in a newly created company without a configured warehouse will no longer see an error when opening a product's View Diagram. Instead, Odoo shows a clear warehouse setup warning, helping users understand what needs to be configured.
Original PR description
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2)…
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2) Navigate to Inventory>Configuration>Warehouses and create a new Warehouse. 3) Create a new company and switch to that company. 4) Navigate to Inventory>Products>Products 5) Open any product and click on 'View Diagram' in the 'inventory tab'. **Error:** `AttributeError: 'bool' object has no attribute 'origin'` **Root Cause:** On following above steps, `default_get` method is called. At [1], it attempts to fetch the ID of the warehouse. Because Odoo does not create a default warehouse for a newly created company, the value received by `res` at [2] looks like `[(6, 0, ['False'])]` which causes an error during further computation. **Fix:** Raise a `Redirect Warehouse Warning` when clicking 'View Diagram' if no warehouse is found. [1]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L35 [2]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L36 **Note**: not adding a test case, as the issue is not reproducible in test mode as default warehouse is created for a company in the test mode https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 sentry-6575082178 Forward-Port-Of: odoo/odoo#227810
In editable lists, drag handles now remain visible instead of disappearing while still being clickable. This prevents confusing interactions when users edit rows and reduces visual flicker when saving after reordering.
Original PR description
When editing a list row, handle fields were invisible but still interactable, leading to confusing behavior. They are now kept fully visible during edition. Additionally, the explicit leaveEditMode call on drop has been put further in the method, since it could cause a flicker to occur with the save otherwise. task-5079713
Arabic invoice reports for Saudi Arabia now display the description column with the intended alignment. This makes printed invoices easier to read and keeps the layout consistent with the other invoice columns.
Original PR description
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The…
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The description column is misaligned in the Arabic invoice report. According to Saudi localization, it should be aligned to the left for better readability. The current alignment makes Arabic text inconvenient to read. **Cause:** - Other columns (e.g., quantity, taxes) already use the `text-end` class, but the description column has no alignment class, causing inconsistent layout and misalignment. **Solution:** - Added the `text-end` class to the description column to ensure proper alignment and consistent readability in Arabic invoice reports. **Before FIX:** <img width="831" height="329" alt="image" src="https://github.com/user-attachments/assets/857f9f7f-d930-4c73-b2fa-eacd7a153ea3" /> **After FIX** <img width="788" height="354" alt="image" src="https://github.com/user-attachments/assets/929acdb1-bb13-4e1e-829c-8fdbe18334a4" /> **opw-5087770** Forward-Port-Of: odoo/odoo#228118
Printed invoices now show the correct early-payment amount when cash rounding is applied. This prevents customers from seeing a slightly incorrect amount due on invoices with early payment discounts and cash rounding rules.
Original PR description
**Steps to reproduce** - Create a tax of 8.1% - Activate and create a cash rounding with rounding precision 0.05 - Use the existing '2/7 Net 30' payment term (or create a new 2% early discount one) - Create a new invoice: - Add payment terms - Add cash rounding method - Add line with price 50, 8.1% tax - Invoice total will be 54.05 **Issue** Print the invoice: The invoice will show "$ 52.97 due if paid before 09/12/2025" However 52.97 is the amount with just the 2% early payment discount applied With cash rounding applied, it should display 52.95 This occurs because when retrieving the amount from the invoice template the system applies only the early payment discount opw-4914545 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4914545) Forward-Port-Of: odoo/odoo#228677 Forward-Port-Of: odoo/odoo#225759
This fix makes an automated website test wait more reliably when the testing servers are busy. It reduces false test failures, helping keep the release process smoother without changing customer-facing website behavior.
Original PR description
__Current behavior before commit:__ The timeout in `waitForReposition` is sometimes reached if runbot is on heavy load making the test fail. __Description of the fix:__ Remove `waitForReposition` and use `waitUntil` instead. This should wait more time if runbot is on heavy load. The timeout has been increased for security. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/232802 Forward-Port-Of: odoo/odoo#228607
Users opening a signature request from a record's chatter will now see the expected documents in the download menu. This avoids confusion and ensures signed documents remain easy to access regardless of how the request was opened.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign request from 'request signature' activity. - From the chatter of the related record, open the sign request. - It will redirect to form view of that sign request. - click on download dropdown button. Before: - The download dropdown was empty. - This happened because the 'sign_request_documents_dropdown' widget tried to use 'active_id' from the context, but 'active_id' was missing when the sign request was opened from chatter. After: - The download dropdown correctly shows the related documents. - When active_id is not in the context, the widget now uses the sign request id from evalcontext, so it can fetch the right documents. Impact: - Users will always see the correct documents in the download dropdown, even when opening a sign request from chatter. task-5089829 Forward-Port-Of: odoo/enterprise#94885
Odoo now shows a user-friendly message when someone searches on a non-stored many-to-many field, instead of failing with a confusing technical error. This helps users and support teams understand that the search is unsupported without exposing internal system details.
Original PR description
When searching non-stored many2many fields, fail with a user-friendly message.
`self.env['account.payment'].search([('reconciled_invoice_ids', '=', 1)])` today results in an AttributeError when trying to get the SQL for the bridge table name.
task-5061329
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228819The website SEO dialog no longer shows broken image entries for dynamic template images that users cannot edit. This keeps the image optimization section focused on images users can actually improve, reducing confusion on appointment and course pages.
Original PR description
**Issue:** In the SEO dialog, under the `Images Optimization` section, broken images are displayed due to the inclusion of non-editable dynamic template images. This issue has been observed on the appointment and course pages. **Steps to reproduce:** 1. Go to the `Appointment` page on the website. 2. Go to `Site` settings present in the header > `Optimize SEO`. 3. Notice under the `Images Optimization` section, the broken image icon. See [screencast](https://drive.google.com/file/d/1EZTF2FY1ljj6S2PLwwt42Vht1IdVC3aK/view) Exclude non-editable dynamic template images from the SEO dialog's `Images Optimization` section. Users cannot modify their `alt` attributes, so including them serves no purpose. Forward-Port-Of: odoo/odoo#228850 Forward-Port-Of: odoo/odoo#227702
This fix ensures General Ledger report lines using additional grouping options can be expanded as expected. It helps users review detailed accounting information consistently, even when reports are customized beyond the default grouping.
Original PR description
Before when we added different groupby on the gl line than the default ones, that would not be unfoldable by default. This is due to a default dict that set has_sublines to False by default and it would never be set to true for groupby other than the default ones. Forward-Port-Of: odoo/enterprise#95545
Helpdesk team settings now show only internal users when assigning team members for tag-based ticket dispatching. This prevents portal users from being selected by mistake and keeps ticket assignment limited to appropriate staff.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188** Forward-Port-Of: odoo/enterprise#95264
This fix ensures the DATEV main account is only assigned for companies based in Germany, preventing incorrect accounting setup for businesses in other countries. It also improves how debit and credit lines are processed, making the report logic more efficient for larger accounting records.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
The CRM Periodic Digest tip now states the correct number of free credits for targeted lead generation. This avoids misleading users by clarifying that 20 credits are provided, not 200.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
7 changes
Resolved issues and error corrections
Draft restaurant bills no longer show a misleading change amount before any payment has been made. This keeps early printed bills accurate for staff and customers and avoids confusion during service.
Original PR description
steps to reproduce: ------------------ 1. Install pos_restaurant 2. Go to Settings of the Restaurant and activate Early Receipt Printing 3. Go to dashboard > open restaurant > create an order 4.…
steps to reproduce:
------------------
1. Install pos_restaurant
2. Go to Settings of the Restaurant and activate Early Receipt Printing
3. Go to dashboard > open restaurant > create an order
4. Click on Actions > Bill > Print
issue:
------
The "CHANGE" line appears on the bill print even without a payment transaction.
cause of the issue:
--------------------
The condition:
https://github.com/odoo/odoo/blob/76757158c0ce4a29883c3c52c3378218ea755a8f/addons/point_of_sale/static/src/app/models/pos_order.js#L264 is responsible to display of "CHANGE" regardless of the order state, leading to incorrect printing while the order is still in DRAFT state.
solution:
---------
Add a check to ensure the order is not in DRAFT state before printing the bill.
**NOTE:** The issue no longer exists in later versions, as it was [resolved](https://github.com/odoo/odoo/commit/e11a3489a78334ad5d3395fd405b870fa1aa218b#diff-5f6173b111795dcdfe25b1fb26d55d27e1ce9c334eabe838d413fc35c5084d1aR1034-R1036) in commit e11a348.
<details>
<summary>Click here to see:</summary>
Before fix:
<img src="https://github.com/user-attachments/assets/4acd2322-ecae-4ff8-8421-234a9d00af86"/>
After fix:
<img src="https://github.com/user-attachments/assets/02edc28b-b1c1-40aa-b478-7a3419f2e736"/>
</details>
opw-5078803
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers in a newly created company without a configured warehouse will no longer hit an error when opening a product's inventory diagram. Instead, Odoo shows a clear warehouse setup warning so the user can correct the configuration and continue.
Original PR description
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2)…
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2) Navigate to Inventory>Configuration>Warehouses and create a new Warehouse. 3) Create a new company and switch to that company. 4) Navigate to Inventory>Products>Products 5) Open any product and click on 'View Diagram' in the 'inventory tab'. **Error:** `AttributeError: 'bool' object has no attribute 'origin'` **Root Cause:** On following above steps, `default_get` method is called. At [1], it attempts to fetch the ID of the warehouse. Because Odoo does not create a default warehouse for a newly created company, the value received by `res` at [2] looks like `[(6, 0, ['False'])]` which causes an error during further computation. **Fix:** Raise a `Redirect Warehouse Warning` when clicking 'View Diagram' if no warehouse is found. [1]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L35 [2]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L36 **Note**: not adding a test case, as the issue is not reproducible in test mode as default warehouse is created for a company in the test mode https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 sentry-6575082178
The Partner Ledger now keeps partner names and expand arrows neatly aligned on phones and tablets. This makes the report easier to read and use on smaller devices without changing its functionality.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317
This fixes a problem where Discuss could crash if an update arrived for a call session that had already been removed. It improves reliability for users by safely ignoring outdated session updates instead of showing an error.
Original PR description
Before this commit, since a regression introduced in https://github.com/odoo/odoo/pull/228601 A traceback could occur when updating a session that does not exist. For example if the event is received after the session is removed.
The CRM periodic digest now states the correct number of free lead generation credits. This avoids misleading users by showing 20 credits instead of the incorrect 200 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
This fix updates the Indonesian e-Faktur buyer document values so invoices use the correct labels for Other ID and National ID. It helps ensure generated tax documents contain accurate buyer identification information, reducing confusion and compliance issues.
Original PR description
the byer document has a wrong value in others and NIT. so this commit change the values to `Other ID` and `National ID` To check values: go to fields and search for `l10n_id_buyer_document_type` opw-4974469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The cohort view export button is now disabled when there is no data to export. This prevents users from encountering an error when downloading reports from empty views, such as Helpdesk ticket analysis without records.
Original PR description
Currently, an error occurs when user tries to export data on cohort view with no data. Steps to replicate: - Install `helpdesk` (without demo data). - Go to `Helpdesk > reporting > Ticket Analysis` and go to cohort view. - Click download and error will occur. - If error doesnt occur, click on `Measure > Count`, and click Download again. Error: `IndexError: list index out of range` Cause: - The export button remained enabled even when no data available, this caused the export to be called without any data that caused the `Indexerror` at [1]. Solution: - Disabled the export button when no data in cohort view. [1]: https://github.com/odoo/enterprise/blob/475a802aa3e748a905be83c0f6408f8c20f03905/web_cohort/controllers/main.py#L30 sentry-6831823426
1 change
Resolved issues and error corrections
The sale order payment confirmation test now uses the email template selected in system settings instead of assuming a fixed default. This makes the test better reflect real configurations and helps avoid false failures when businesses customize their sales confirmation emails.
Original PR description
The email template for the sale confirmation can be changed through the config parameters so it's better to read it directly from there instead of having it hard-coded. This now correctly tests the function it's testing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr