Friday, November 14, 2025
59 changes · 19.0
Enhancements to existing features
This change clears the blackbox processing queue whenever point-of-sale data is reloaded. It helps prevent rare situations where queued requests could keep repeating and cause the POS to become unresponsive.
Original PR description
This commit adds a clear of the blackbox queue when reloading data. This could avoid potential unexpected deadloop of calls in the queue. Forward-Port-Of: odoo/enterprise#99252
This change removes the need for the Sign app to be installed for the accountant knowledge features to work. It simplifies setup and reduces unnecessary dependency between products, while keeping the related templates and embedded signature elements available where needed.
Original PR description
task-5154292
Resolved issues and error corrections
This change moves a fleet-related tax report test and its query logic out of the community edition and into the enterprise module where the required vehicle data is available. It resolves a build failure in the community version while preserving the intended fleet reporting behavior for enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/odoo#235339 Forward-Port-Of: odoo/odoo#234095
This change prevents tracking from crashing when related records do not have a display name. Instead of showing an error, the system now falls back to a safe default, matching the behavior used in similar cases. This improves reliability for users working with tracked one-to-many and many-to-many fields.
Original PR description
Description of the issue/feature this PR addresses: Addresses: https://github.com/odoo/odoo/issues/178883 Same issue is also in 18.0. Is there a separate PR necessary or will this be ported forward? Current behavior before PR: An error is displayed when tracking is activated on one2many and many2many with records without display_name. Desired behavior after PR is merged: Should not crash and use fallback like in other cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214121
Fixed an issue where opening certain dropdowns on the website could accidentally trigger a page reload in some browsers. This improves the experience for visitors and editors by preventing the page from refreshing before a selection is made.
Original PR description
In some browsers, opening a `<select>` triggers a click event. Because of this when the blog's sidebar "Archive" dropdown is opened, it might reload the page before the selection is actually made. This commit solves this by detecting a distinct event when PostLink is activated on `<select>` element. Steps to reproduce: - Using Firefox - Install `website_blog` - Edit the blogs page - Activate the sidebar - Save - Open the "Archive" dropdown => The page was reloaded Forward-Port-Of: odoo/odoo#233202
The fleet tax reporting test and related query were moved into the Enterprise edition, where the required vehicle-linked data is available. This fixes community build failures while keeping the intended fleet reporting behavior available for Enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/enterprise#99288 Forward-Port-Of: odoo/enterprise#98650
This change allows outstanding accounts to be created even when a company does not use a standard chart template. It helps businesses with manually configured accounting setups avoid errors and continue processing expenses normally.
Original PR description
The creation of outstanding accounts when fallback should not require a chart template, since companies may have manually configured their chart of accounts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents errors when creating a new branch in Indian databases that do not yet have newly introduced taxes. It ensures the correct fiscal mappings are created for both intra-state and inter-state cases, avoiding failures during setup.
Original PR description
In cases, where new taxes are introduced in stable, and for the fiscal mapping are added as well. But for existing dbs, the new tax might not be available and when creating new branch it might lead to traceback because, we create new fiscals for intrastate and interstate --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents a permissions error that could stop sales orders from being confirmed in branch-company setups, especially when dropshipping is enabled. It ensures Odoo checks company-related taxes in a safer way so users only see records they are allowed to access.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Create a branch company B; 2. create a branch C for the branch company B; 3. change to branch C; 4. create a warehouse; 5. enable dropshipping; 6. add a…
Versions -------- - saas-18.4+ Steps ----- 1. Create a branch company B; 2. create a branch C for the branch company B; 3. change to branch C; 4. create a warehouse; 5. enable dropshipping; 6. add a vendor to a stored product with the Dropship route enabled; 7. log in as a sales user with access to branch C only; 8. add product to a sales order & confirm. Issue ----- > Access Error > Uh-oh! Looks like you have stumbled upon some top-secret records. > Sorry, Marc Demo (id=5) doesn't have 'read' access to: > - Companies, YourBranch (res.company: 3) Cause ----- The error gets thrown during the `_prepare_purchase_order_line` method, specifically on the line which filters `supplier_taxes_id` using `lambda x: x.company_id in company_id.parent_ids`. This passes via the field's `convert_to_record` method, which attempts to access the `active` field of the companies to filter out any that are archived[^1]. [^1]: https://github.com/odoo/odoo/blob/5b911a97a3885283d2f21ac30abb96cb10fe39d9/odoo/orm/fields_relational.py#L608-L612 In previous versions, this wasn't an issue, because the `active` field was still present in cache from the `_compute_parent_ids` which is called with `sudo`, but as of saas-18.4, it attempts to refetch these values, leading to the error. Solution -------- Instead of using `filtered`, use `filtered_domain` using the result of `account.tax._get_company_domain`. opw-5112625 Forward-Port-Of: odoo/odoo#231743
When opening a project from a sales order, the system now automatically focuses on the tasks linked to that specific sales order. This prevents users from first seeing unrelated tasks from the same project, making it easier to find the information they need.
Original PR description
Before this commit, when the user clicks on x projects and x tasks stat button in the sale order form view and that SO is linked to some task and more than one project, the user will be redirected in kanban view of projects and when he will click on a project, he will see all tasks linked to that project instead of seeing the tasks linked to SO inside that project. This commit makes sure a default search is added in the tasks views when the user open a project from an SO to be sure the user will first see the tasks linked to that SO.
This change prevents the chat system from crashing in cases where a member’s profile information is missing. It now uses a more reliable way to identify the current user’s member record, which keeps message tracking working correctly.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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#235338 Forward-Port-Of: odoo/odoo#235253
Opening some activity items from the Activities calendar could fail when the system did not provide enough information to display the record. This fix adds a safe fallback so the correct form view opens instead of showing an error, improving reliability for users.
Original PR description
When opening certain activity items from the Activity Calendar popover,
the backend returns an `ir.actions.act_window` result missing the `views` key.
The frontend attempted to call:
action.views.map(...)
which caused:
TypeError: Cannot read properties of undefined (reading 'map')
This patch adds a safe fallback:
if (!action.views) action.views = [[false, "form"]];
so that the action always has a valid view, preventing a crash and maintaining expected behavior.
Steps to reproduce:
- Go to Activities → Calendar
- Click on different activity items
- Click the "View" button
- JS error occurs for some items
After applying this fix, affected actions open a fallback form view instead of crashing.
This issue also occurs on official demo (demo.odoo.com).Saudi invoices could incorrectly show no tax on invoice lines when a Saudi customer was selected. This fix restores the expected tax behavior so invoices calculate and display taxes properly for Saudi Arabia setups.
Original PR description
Steps to reproduce: - With a SA company setup - Create an invoice - Set a Saudi Arabia partner - Add a product with 15% tax defined on it Issue: No tax shows up on the invoice line Analysis: This occurs because the default fiscal positions are all empty and empty fiscal positions remove all taxes. opw-5166882 Forward-Port-Of: odoo/odoo#234387
This update fixes two issues in mailing messages: an extra blank paragraph could be added in the email content, and some opened messages could keep expanding the page indefinitely. It improves the reliability of the email editor and makes saved mailings display correctly in read-only view.
Original PR description
This [commit] introduced 2 issues in `mass_mailing`: - when creating a mailing with the basic editor, it adds an empty paragraph above the `o_layout` block, even thought the entire mailing content…
This [commit] introduced 2 issues in `mass_mailing`: - when creating a mailing with the basic editor, it adds an empty paragraph above the `o_layout` block, even thought the entire mailing content should be enclosed inside the `o_layout` block. - when sending such an email (with the wrong paragraph) and consulting the readonly value in the `mass_mailing` Form view, the view started growing indefinitely. How to reproduce: - create a mailing using the basic editor and send the email - open the mailing in readonly Issues: - there is a paragraph outside the `o_layout` element in the DOM - the page scrolls indefinitely because `o_layout` has `min-height: 100%`. Resolution: - don't force `o_layout` to have a `min-height`, which will prevent the infinite scrolling for mailing that were sent with a wrongly placed paragraph. - configure the mailing so that the editable element has `contenteditable="false"`, and the element with `o_mail_no_options` coming from the basic template gets `contenteditable="true"` so that the editor is informed that the user is only allowed to edit the content of that node, not the outside of it, which will prevent the empty paragraph insertion. [commit]: https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d task-5263045
The signing process test now runs with a regular user instead of only an administrator, which helps catch permission-related mistakes that were previously missed. This prevents a signing error from slipping through when a salesperson field points to the wrong user and a customer tries to sign a document.
Original PR description
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard. The issue is that, on the model `res.partner`, the field `user_id` is the…
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard.
The issue is that, on the model `res.partner`, the field `user_id` is the Salesperson associated to this Contact, whereas the field `user_ids` contain the `res.users` that inherit this Contact, and `main_user_id` is the most appropriate User of `user_ids` when we need only one.
When testing as admin, all fields are the admin user, whereas when testing as Laurie Poiret (or any regular user), the Salesperson is still the admin while `main_user_id` is Laurie Poiret.
A regular user can access only its own `sign_signature` field, while an administrator can access the `sign_signature` of all users, so this bug remained undetected:
On a runbot, log in as `admin` to change the sales person of Marc Demo to Mitchel Admin, then log in as `demo` and click on "Sign Now" on the `Rental_Agreement.pdf` template.
You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
Operation: read
User: 5
Groups: allowed for groups 'Role / Administrator'This change ensures the system consistently reports when a WebSocket connection is lost and then recovered, even in a rare edge case where the closing process was incomplete. It helps keep connection status events accurate and also resolves an intermittent test failure in the background service.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 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#235319
This change fixes an issue in the Argentine localization where users could not generate a debit note from an existing credit note. It now lets businesses correct mistakes more smoothly by creating the proper reversing document without encountering an error.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#233875 Forward-Port-Of: odoo/odoo#225501
This change fixes a build failure affecting payroll tests by removing a field reference from modules that do not always have it available. It helps ensure payroll localizations can be tested reliably without unexpected errors during automated builds.
Original PR description
The issue occurs because the _get_whitelist_fields_from_template() method includes the overtime_from_attendance field, introduced in this https://github.com/odoo/enterprise/pull/92093. This field comes from the hr_work_entry_attendance module, which is not listed as a dependency in all payroll localisations. As a result, the field cannot be found during test execution. Solution: Remove the overtime_from_attendance field from all _get_whitelist_fields_from_template overrides in the localisation modules, and instead include this field by overriding the function in the hr_work_entry_attendance module. build error-243483 task-5169211
This fix brings back report variants that were no longer shown for companies using country-based availability rules without foreign VAT support. It ensures the correct report options appear again, so users can access the right local tax reports as expected.
Original PR description
Since this commit https://github.com/odoo/enterprise/commit/13b28f789e0b1d9c3e266a99aae65c48bb6ce8b6, no variants with the availability condition set to country and not allowing foreign vat were displayed anymore.
This update fixes a rounding problem in DHL shipping data that could cause shipment validation to fail for perfectly normal prices and weights. It helps ensure deliveries can be created smoothly without DHL rejecting the request due to tiny floating-point precision errors.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#99012 Forward-Port-Of: odoo/enterprise#96012
This update ensures the first line of a bank statement is computed correctly whenever key line details change. It prevents cases where the statement balance could be wrong because an internal index was not refreshed at the right time.
Original PR description
Ensure proper computation of first_line_index when line.internal_index or line.state changes. Previously, the computation of first_line_index was grouped with the date computation. However, due to a specific ORM behavior, the compute method is not triggered when one of the computed fields (in this case, the date) is provided in the create values. As a result, first_line_index could remain falsy, leading to an incorrect balance in the bank journal. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235561
This change prevents an error that could appear when creating multiple journals of the same type before naming them. Odoo now correctly keeps aliases unique even when no alias domain is set, avoiding a save failure for users.
Original PR description
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the…
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error. **Steps to Reproduce** 1. Navigate to Accounting > Configuration > Journals. 2. Create a new journal. 3. Set the Type to Sales before entering the Name. 4. Save the journal. 5. Repeat the process to create another journal of the same type. 6. Observe that an error occurs: alias name is already used. **Root Cause** The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly. **Fix** Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured. Opw-5028713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233101 Forward-Port-Of: odoo/odoo#225537
The Wave document layout no longer allows a multi-line footer to overlap invoice content when viewed on mobile. This improves the readability and appearance of portal previews and prevents document information from being hidden.
Original PR description
In the Wave layout, a multi-line footer overlaps document information when the portal view is opened from a mobile interface. Steps to reproduce: - Open Settings > General settings > Configure Document Layout - Select Wave layout and add a multi-line footer - Open an invoice, go to portal preview, switch to mobile view Issue: The footer overlaps invoice information. This occurs because the boundaries of the SVG drawing are not well defined and it will unexpectedly shrink. opw-5023032 Forward-Port-Of: odoo/odoo#230230
Regular users could experience a crash when receiving incoming calls because the system tried to update call details without the needed access rights. This update lets the call handler save the contact link safely, preventing the interruption and keeping incoming calls working smoothly.
Original PR description
In order to prevent users from tampering with their voip.call records, they aren't given direct write access to them. This leads to crashes in the get_contact_info function, which attempts to update the partner_id field of call records. This commit resolves the issue by switching to sudo mode for setting the partner_id.
Pasted web links in the message composer now turn into clickable links correctly. This improves the writing experience and helps users share links without needing to reformat them manually.
Original PR description
When pasting a URL in the html composer, the link was not being correctly parsed and converted into a clickable hyperlink. This commit fixes the issue by ensuring that the LinkPastePlugin is included in the composer plugin set, allowing for proper link detection and conversion. Also, this commit forced links to open in a new tab when being parsed with LinkPlugin. task-5259858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr