Tuesday, September 30, 2025
51 changes · 19.0
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
This fix makes several automated website sales tests run consistently after recent internal changes. It helps reduce false test failures, giving teams more confidence that online store and loyalty features are working as expected.
Original PR description
This commit fixes some indeterministic tours which was introduced after the refactor of some public widgets to interaction in eCommerce and portal-related modules. error-232883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Google Merchant Center feature setting is now shared across all websites in Odoo 19. This prevents different websites from using conflicting settings and keeps behavior consistent across the version.
Original PR description
In a more recent version (see [^1]), it was decided to entirely remove the website-specific feature flag and instead rely on a group-based feature flag. Unfortunately, this change only affected newer versions of Odoo, specifically 19.1. To ensure consistent behavior across v19, this commit introduces a workaround to ensure all websites always share the same configuration regarding GMC. See also https://github.com/odoo/upgrade/pull/8468#discussion_r2374582760 for the initial discussion. [^1]: https://github.com/odoo/odoo/pull/227629
Opening All Orders from the customer list no longer clears the customer already selected on the point of sale order. This prevents extra re-selection steps and keeps cashier workflows smoother.
Original PR description
Before this commit, opening the All Orders from the partner list would reset the selected partner. As a result, the user had to reselect the partner after returning, which disrupted the workflow. opw-4972314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224904 Forward-Port-Of: odoo/odoo#222507
This update fixes a remaining source of unpredictability in an automated Web Studio test. It helps keep quality checks stable so future changes can be validated more reliably without false failures.
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
Fixed an error that could occur when users opened the General Ledger from the Trial Balance while working with multiple companies and Developer Mode enabled. This improves reporting reliability by ensuring the page opens instead of showing a traceback.
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
The website editor now opens the correct submenu settings when users choose "Edit Menu" from a submenu link. This prevents accidental edits to the main menu and makes event or nested website navigation easier to manage.
Original PR description
With the initial [website builder refactor], when user wanted to edit sub-menu with "Edit Menu", it opened the dialog to edit the top-level menu. This commit fixes that behavior by looking up the id of the containing menu (if any) Steps to reproduce: - On `/event/<some-event>`, open website builder - Click on a link in the menu of the event (not the top menu) - Click on "Edit Menu" button in the link popover - Bug: the edit menu dialog opens for the top level menu [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641 Forward-Port-Of: odoo/odoo#225343
Peruvian electronic invoices now show the invoice currency for deducted down payments instead of defaulting to the company currency. This prevents foreign-currency invoices, such as USD invoices, from being reported with the wrong currency in the official XML.
Original PR description
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to…
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to reproduce: 1. Install l10n_pe_edi 2. Sell a product to "Comercial Constructora los Patitos" through the sales app and make sure you use USD (or a different currency than PEN). 3. Create a downpayment invoice, could be any percentage. 4. To make sure it works correctly, add a random document number on the invoice with the format ABC-01234567. 5. Confirm this invoice. 6. Now go back to the sale order and deliver your product. 7. Create the final invoice, where the downpayment will be deducted. Make sure it is also in USD (or whatever currency you chose). 8. Confirm the invoice. #### Current behavior: - Display "PEN" in the attribute currencyID of tag PaidAmount in a PrepaidPayment: <cbc:PaidAmount currencyID=PEN> #### Expected behavior: - The currency displayed should match the invoice currency #### Cause of the issue: - the currency of the company emitting the invoice was used instead of the currency of the invoice. opw-5061019 Forward-Port-Of: odoo/enterprise#93885
The language settings now show example dates that correctly match each available date format. This reduces confusion for administrators configuring localization options and helps them choose the right date display format.
Original PR description
**Steps to reproduce:** 1. Set up a fresh v19 database. 2. Go to Settings > Translation > Languages (e.g., English) > Date Format. 3. Turn on debug mode and check field definitions. **Issue:** - Date format examples were not aligned correctly with their technical formats, causing confusion. **Cause:** - The mapping of example dates to format strings was incorrect. **Solution:** - Update the example dates to correctly match their corresponding technical date formats. **opw-5116664** Incorrect Format (image of field defination): <img width="237" height="250" alt="image" src="https://github.com/user-attachments/assets/ac0f9dac-2f18-4ef2-8a61-474951efda92" />
When a message linked to an accounting report note is deleted, the related note is now removed as well. This keeps reports clean and prevents outdated annotations from staying visible after their source message is gone.
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.
The payroll accounting test setup now gives the test user the required payroll manager permissions. This prevents an access rights error during automated testing, helping keep payroll functionality reliable for Slovak localization.
Original PR description
steps to reproduce: install l10n_sk_hr_payroll_account run test_payslip_1 test added payroll manager groups to the test user to avoid missing access rights error build_error-230673
The website now keeps the video size area hidden when visitors have not accepted optional cookies, matching the privacy-related video loading behavior. This prevents confusing or premature video controls from appearing before the visitor gives consent.
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#229064 Forward-Port-Of: odoo/odoo#226817
A Planning test was updated so it no longer fails when demo data is present. This helps keep automated validation stable and reduces false alarms during release checks.
Original PR description
Reason: - In the test case we check for record count, so we get the count of all the demo data installed too. Fix: - Remove all the records before hand to check for the count. https://runbot.odoo.com/odoo/runbot.build.error/231599 runbot-231599
The task list now shows the allocated hours field even when its value is zero, so users can edit it directly for one or multiple tasks. This removes a workflow blocker for planning and timesheet management where zero-hour allocations were hidden instead of editable.
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#229145 Forward-Port-Of: odoo/odoo#228188
This update fixes an automated website menu test that could fail in smaller single-app test environments. It ensures the test has the right setup, improving build reliability without changing the user-facing website experience.
Original PR description
Following this [commit], this tour would fail whenever it is run in single-app test builds. This happened because there were not enough items in the nav for the tour to function properly. Also, removed the "@odoo/hoot-dom" dependency. Build error-231699 [commit]: https://github.com/odoo/odoo/commit/7279c92fcb999f621fd9725c2339247c620ed378 Forward-Port-Of: odoo/odoo#226009
This update adjusts internal editor tests so each check has its own timeout instead of sharing one. It helps reduce occasional automated test failures, making release validation more stable without changing user-facing behavior.
Original PR description
Grouping multiple `testEditor` in a single `it` is bad practice because the timeout of `it` is then shared between the different `testEditor` calls rather than each having their own separate timers. Technically, only the web_edior tests ever timed out, but I split the html_editor ones as well for good measure. runbot-231687 Forward-Port-Of: odoo/odoo#227985
This update corrects an automated test so it reflects that sales kits can be invoiced based on ordered quantities before delivery. It helps keep validation reliable for businesses using kit products and reduces the risk of false build failures.
Original PR description
This change updates the test_sell_kit_invoice_before_delivery test to ensure that kit components and the kit product itself use an invoicing policy of Ordered Quantities rather than the default Delivered Quantities. build_error-232796 Forward-Port-Of: odoo/odoo#227870
This fix prevents Discuss from crashing when it receives an update for a call session that has already been removed. It improves reliability for users by safely ignoring outdated session events 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. Forward-Port-Of: odoo/odoo#229166 Forward-Port-Of: odoo/odoo#229073
Internal users previewing project task portal pages will now see the same “Back to edit mode” banner that already appears on project portal pages. This keeps the portal preview experience consistent and helps users quickly return to editing from task detail pages.
Original PR description
Steps to Reproduce: - Log in as an internal user with project access. - Open a project’s portal page: /my/projects/. - Open a task’s portal page: /my/tasks/ (or via /my/projects/<id>/task/). - Compare the banner visibility between the project page and the task page. Current Behavior: The “Back to edit mode” banner appears on the project page but is missing on the task detail page. This leads to an inconsistent experience when previewing portal content and causes failure of the industry_fsm tour. Expected Behavior: The “Back to edit mode” banner should consistently appear on the task detail page as well, allowing users to return to edit mode from any portal view. Task-5083445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents duplicate payment provider setup when the payment customization module is initialized more than once, such as during a reinstall. It also ensures the correct wire transfer provider is used, reducing setup errors for businesses using payment and delivery features.
Original PR description
**Description of the issue/feature this PR addresses:** If the `post_init_hook` is executed a second time for some reason (ie., reinstalling the module), then errors happen: - It will create again copies of providers. - If you have installed `delivery`, then the `main_provider` to copy may not be the one with `custom_mode='wire_transfer'.` This PR avoids these errors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the online shop’s GeoIP cart test uses pricelists even when a database has no demo data. It improves test reliability and helps prevent false failures in automated validation without changing customer-facing behavior.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a database without demo data; 2. run `test_cart_new_pricelist_from_geoip`. Issue ----- Test fails, due to the order not having a pricelist. Cause ----- Pricelists aren't enabled by default without demo data. Solution -------- Call `self._enable_pricelists()` at the start of the test. runbot-232989 Forward-Port-Of: odoo/odoo#229224
Free products added through loyalty rewards on sales orders now use the reward description as the line name instead of the underlying product name. This makes customized reward descriptions appear consistently and reduces confusion for sales teams and customers.
Original PR description
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program…
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program that grants a free product. 3) Manually update the reward's description. 4) Create a SO with a SOL containing that product 5) Apply the reward and observe the behavior. **Issue / Cause:** - The free product's description is taken from the reward product's name instead of the manually updated description. - This is incorrect because, in the point of sale, the name is taken from the reward's `discount_line_product_id` rather than the `reward_product_ids`. https://github.com/odoo/odoo/blob/0abdcd9ef6ad3fc932dc0eb46d8aa973b00c34c2/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1162 **Solution:** To resolve this inconsistent behavior, the free product name in the sale order line will now be taken from discount_line_product_id. opw-4982774 Forward-Port-Of: odoo/odoo#229152 Forward-Port-Of: odoo/odoo#223755
The SEPA payment flow now checks the bank account actually selected by the user, not just the account originally linked to the bill. This prevents incorrect warning banners when a trusted bank 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
Vendor payments no longer show a warning when a user manually selects a bank account that is already trusted. This helps accounting users avoid confusion and proceed with SEPA payments based on the account they actually selected.
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