Monday, September 7, 2026
30 changes · master
Resolved issues and error corrections
The website shop header now uses the already saved cart quantity when available instead of reloading the full cart each time. This avoids unintended cart resets or recovery actions while customers are browsing or completing payment, improving checkout reliability.
Original PR description
`header_cart_link` computed the badge quantity with `request.session.get('website_sale_cart_quantity', request.cart.cart_quantity)`. Python evaluates the default argument unconditionally, so every render resolved `request.cart` even when the quantity was already cached in the session. Resolving the cart runs `_get_and_cache_current_cart`, which can mutate the session (cart reset, abandoned-cart recovery) as a side effect of merely rendering the header.
Read the cached quantity directly when the session key is present, falling back to `request.cart` only when it is absent.
This is needed for https://github.com/odoo/odoo/pull/268897 to prevent the cart from being reset while waiting for the user to do the payment.This fix validates key French Flow 10 e-invoicing report fields before sending them to the public platform. It helps prevent full report rejections by flagging affected journal entries when text, tax, company, or address values do not meet required limits.
Original PR description
Some Flow 10 values are generated without applying the length and format constraints expected by the PPF. Long free-text values, oversized VAT numbers, and invalid address data can therefore cause an entire report to be rejected. Limit product names and invoice notes to their allowed lengths and normalize country codes. Validate the declarant SIREN, VAT number lengths, and address values before sending so affected journal entries are marked as errors and excluded from the report. No Task id Forward-Port-Of: odoo/odoo#286887 Forward-Port-Of: odoo/odoo#286536
Internal users assigned to tasks in invitation-only projects can now open their assigned task links without being blocked by project-level access errors. The fix preserves project privacy, so users can access only the task they are assigned to without exposing other project tasks.
Original PR description
Issue: Internal users assigned to a task in an "Invited internal users" project can read the task but may receive an access error when opening it. Adding them as project followers avoids the error…
Issue: Internal users assigned to a task in an "Invited internal users" project can read the task but may receive an access error when opening it. Adding them as project followers avoids the error but also exposes the project's other tasks. Steps to reproduce: - Set a project's visibility to "Invited internal users". - Assign an internal Project user to one of its tasks. - Keep the user out of the project's followers. - Open the assigned task through its access link. Cause: The task form loads feature flags whose computations read their values from the parent project. These computations run as the assignee, who can read the assigned task but not the invited-only project, causing a project access error. Additionally, the project many2one widget declares `is_template` as a related field. This makes web_read request `project_id.is_template` even though the widget uses the task's own `is_template` value. https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L277 https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L295 https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/static/src/components/project_many2one_field/project_many2one_field.js#L36-L39 Solution: We need to compute the inherited task feature flags with elevated access so their values do not depend on the assignee's access to the parent project. declare `is_template` as a dependency of the current task instead of a related field of `project_id`. The task form therefore no longer reads the inaccessible project while its access restrictions remain intact. opw-6475880 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284196
The AI chat agent filter now loads and paginates results using the selected agent from the start, instead of filtering only what was already loaded. This prevents the chat list from getting stuck with too few conversations and keeps agent-specific chat views consistent when navigating back.
Original PR description
The AI chat tab has a dropdown allowing to filter it on a specific agent. The filter is applied client-side only, which is incompatible with lazy loading. A `load_more` batch fetched from the unscoped tab domain can come back mostly unrelated to the selected agent. Once filtered down it may render too little content to overflow the scrollable area. The bottom scroll trigger that requests the next batch then never fires again, leaving the tab stuck showing fewer matching channels than actually exist. The dropdown now sets its own filter through `mail`'s new `MessagingMenuUIState.pluginFilters`, which goes through the real fetch and pagination: the agent scope is resolved server-side and ANDed into the tab's domain community: https://github.com/odoo/odoo/pull/286451
This fixes an issue that prevented users from adding extra images to products from the eCommerce tab. Product teams can now upload additional product media without encountering an error during the add process.
Original PR description
Steps to reproduce: 1. Open a product form view. 2. Go to the eCommerce tab. 3. Click on 'Add Media'. 4. Upload an image. 5. Click on 'Add'. Issue: - Adding an image fails with `ERR_INVALID_URL` because the generated data URL contains `[object Object]`. Cause: - The `raw` value returned by `searchRead` is a binary object containing `filename`, `content`, and `size`, but `convertToWebpFormat` passes the whole object as the image data to `generateImageVariants`. Fix: - Pass the `content` of the binary value to `generateImageVariants` instead of the whole `raw` object. opw-6542393
This fixes Spanish TicketBAI reporting for point-of-sale orders that use gift cards. Gift card refund amounts are now shown with the correct sign, preventing mismatches between line totals and the overall invoice total.
Original PR description
The issue fixed in commit[1] is again reproducible after commit [2] the pos order line for gift card is now not considered as a refund Step to reproduce: - Install pos_loyalty and…
The issue fixed in commit[1] is again reproducible after commit [2] the pos order line for gift card is now not considered as a refund Step to reproduce: - Install pos_loyalty and l10n_es_edi_tbai_pos with demo data - Create a gift card (add a tax to the discount product, any 0%) - start pos, add a product and use the gift card - fulfill the order - go to backend and open that order - In the TicketBAI XML, the values for the giftcard product will be positive, causing an inconsistency between the product line total and the invoice total [1] https://github.com/odoo/odoo/commit/0bbc5ebdcc7e014d87130b2ff9cee98e3aa7479a [2] https://github.com/odoo/odoo/commit/b17c9713e7a3305c240298fa54fcf1bc87a9bb8c FIX - we used to determine `sign` based on each order line's `is_refund` property - this property is quite sensitive as it depends on factors like line's qty, price, is reward or not. - so its better to depend on order's refund property for sign reversal https://github.com/odoo/odoo/blob/4fef2c5b69fac10594fac81b149d542ee4621b13/addons/point_of_sale/models/pos_order.py#L1768 opw-6226003 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286448 Forward-Port-Of: odoo/odoo#278042
Dark mode color palettes now load correctly and include the full set of colors used by the interface. This prevents missing or incorrect colors in items such as kanban cards, tags, badges, and color lists, improving visual consistency for users working in dark mode.
Original PR description
1) The "$o-colors" css variable was rebuilt in "secondary_variables.dark.scss", which loads after community's "primary_variables.scss" already assigned it via !default. The dark "$o-colors: ()!default;" reset was silently skipped, so dark colors were appended onto the light ones instead of replacing them, doubling "$o-colors" to 24 entries. => Moving this logic to "primary_variables.dark.scss", which correctly loads first. 2) "$o-colors-secondary-original" only listed 18 colors instead of the 44 used in the original "$o-colors-secondary" of light mode, meaning the dark mode's total palette had far fewer entries than the light mode leading to missing coloring in kanban, tags, badges and colorlist. => Extending the list so that the dark mode "$o-colors-secondary-original" matches the original "$o-colors-secondary" light mode's 44 colors. related: https://github.com/odoo/odoo/commit/1dd67666ce06a9ee44a193e8006cf61aa71479c3
When a contact linked to multiple active users is mentioned, all of those users now receive the notification immediately instead of only one seeing it right away. This ensures teams sharing a contact record do not miss timely mention alerts and avoids relying on a page reload to see them.
Original PR description
Before this commit, mentioning a partner that has two users notified only one of them. The other user saw the mention on reload only. This happens because the notification is sent on the single user that _notify_get_recipients picks for a partner, and since "[REF] bus, mail: use user rather than partner as bus target" a user is its own bus channel, so the other users of that partner are no longer reached. The notification record is stored per partner, which is why a reload shows it. This commit fixes the issue by sending to every active user of the notified partner. https://github.com/odoo/enterprise/pull/129969 Forward-Port-Of: odoo/odoo#286290 Forward-Port-Of: odoo/odoo#283836
When a partner is mentioned, all active users connected to that partner now receive the notification immediately instead of only one user seeing it before reload. This improves reliability of real-time communication, with related test updates to reflect the extra processing needed.
Original PR description
Before this commit, mentioning a partner that has two users notified only one of them. The other user saw the mention on reload only. This commit raises the query counts of the activity tests: the fix in odoo resolves each notified partner to its active users, which costs one query per post with an inbox recipient. https://github.com/odoo/odoo/pull/283836 Forward-Port-Of: odoo/enterprise#130206 Forward-Port-Of: odoo/enterprise#129969
Users can now access the correct reconciliation models from bank statement lines when the bank journal uses a foreign currency. This fixes a search issue where currency labels in journal names prevented matching models from appearing, helping accounting teams manage bank reconciliation setup reliably.
Original PR description
### Issue before this commit: When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal. ### Steps…
### Issue before this commit: When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal. ### Steps to reproduce the issue: 1. Download Accounting 2. Go to Currencies and activate another currency like EUR 3. Go to Journals and create a new one with bank type and curency EUR 4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal 5. Go to test bank journal and create a new bank matching 6. After the line is created click the 3 dots and go to Manage Models 7. See that the new model Tester created does not appear ### Cause of the issue: Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added. https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100 ### Reason to introduce the fix: The filter is not working correctly. In this case it's better to change it to a domain instead of a default filter. opw-6481970 Forward-Port-Of: odoo/enterprise#129992
Fixed an issue where embedded journal-entry actions in Documents could be removed by the cleanup process when users were working in a different company. This helps multi-company users keep their configured document shortcuts intact while preserving company-specific access behavior.
Original PR description
Step to reproduce: - You must have at least 2 companies with an account Journal - Create a New Journal Entry actions (child or parent) - Embed it to a folder - Set your company on a different one than the journal's one - Run the Garbage collector cron (Base: Auto-vacuum internal data) - The embed action has been removed The cause of this is that in the `_get_base_server_actions_domain` method in `documents_account` module there is a check on company to avoid using/running the actions when not in the right company. But the garbage collector don't need to have this check. Task-6147618 Forward-Port-Of: odoo/enterprise#122821
FedEx deliveries can now use a phone number from either the main customer contact or the selected delivery address. This prevents shipments from failing when one related contact record is missing a phone number but the other has it.
Original PR description
Issue ----- Users cannot deliver to a contact's delivery address if the contact address itself doesn't have a phone number. Steps to reproduce ----- - Setup Fedex - Create a contact with no phone number - Create a delivery address for the contact (with phone number) - Create a SO with the contact using Fedex & confirm - Change the partner on the picking to use the delivery address - Validate the picking > Error: missing phone number Cause ----- To populate the `soldTo` part of thepayload, we call `_get_contact_from_partner` with the contact specified on the SO https://github.com/odoo/enterprise/blob/8e60f910a52e3b836e997e54a0b704e5786a28f2/delivery_fedex_rest/models/delivery_fedex.py#L171 https://github.com/odoo/enterprise/blob/8e60f910a52e3b836e997e54a0b704e5786a28f2/delivery_fedex_rest/models/fedex_request.py#L447-L452 The phone number is then taken directly from the contact. ----- Ticket: opw-6427962 Forward-Port-Of: odoo/enterprise#127434
Fixed an issue where completed field service shifts linked to sales orders could incorrectly reset planned hours to zero. This prevents completed work from being shown as still needing planning, improving visibility of scheduling progress.
Original PR description
## before: When marking a shift linked to SO as complete. The `allocated_hours` of this shift is reset to 0. So when the `Planned` button tries to compute the `planning_hours_planned` it adds zero to the planned hours, making all the hours go to the `To Plan`, which is incorrect ## after: prevents the `allocated_hours` from being recomputed when making the shift as complete to avoid this issue. This will leave the hours to be calculated in the `Planned` stat button instead --- task-6425357 Forward-Port-Of: odoo/enterprise#129833 Forward-Port-Of: odoo/enterprise#126396
Fixed an issue where exporting time entries could fail for employees whose contract had multiple versions. This helps payroll users complete exports reliably after contract changes without encountering an error.
Original PR description
## Steps to Reproduce: - Install the hr_work_entry module. - Create an employee. - Payroll tab > create a contract by setting only the start date (leave the end date empty). - From the contract…
## Steps to Reproduce:
- Install the hr_work_entry module.
- Create an employee.
- Payroll tab > create a contract by setting only the start date (leave the end date empty).
- From the contract version timeline (navigation bar), click the "+" button and create a new version.
- Open the cog menu (gear icon) and click 'Export Time Entries'.
## Error:
`ValueError - Expected singleton: hr.version(257, 258)`
## Cause:
Method `_get_contract_versions()` returns multiple versions for the given period.
for example:
`contract_dict = {datetime.date(2026, 8, 1): hr.version(1, 2)}`
The code assumes each value is a singleton and builds the recordset using `c.id`,
`[c.id for c in contract_dict.values()]`
Since `c` contains multiple records, accessing the ID will raise an error.
## Fix:
Instead of accessing `id`, it will access `ids`, and it returns the list of all records (`[1, 2]`).
`chain.from_iterable()` flattens this list into one iterable sequence `(1, 2, ...)`, and
then it will convert into a list and be passed to `browse()` to fetch the corresponding recordset.
sentry-7623869169
Forward-Port-Of: odoo/odoo#278858Belgian CodaBox SODA imports now use the actual last import date when checking for new statements, instead of relying on accounting entry dates. This prevents valid payroll statements generated within the same accounting period from being skipped.
Original PR description
Before v19.1, we used to set the date on the journal entry based on the generation date of the SODA statement during the import. So it was possible to use the last date found in the salary journal as a `date_from` filter when fetching new SODA statements. Starting from v19.1, we now set the date on the journal entry as the last day of the accounting period referenced in the SODA file. However, we didn't change the fetching logic accordingly. If a SODA statement is generated on July 7 for the accounting period of July, the date on the journal entry would be July 31 and, consequently, any other SODA statement generated in-between those dates would be filtered out during the fetch. Ticket: opw-6214589 Forward-Port-Of: odoo/enterprise#130183
The stock allocation report has been refined to work better on mobile, avoid over-allocating already reserved quantities, and prevent errors from repeated quick actions. Users can now allocate or unallocate directly from the forecast report, while validation flows no longer open the allocation report automatically.
Original PR description
This PR fixes issues with [the recently merged](https://github.com/odoo/odoo/pull/264299) allocation report. Main changes are: - Add specific design for mobile device; - Don't allocate already reserved quantity; - Allocation report won't open itself automatically when validating an operation from the Barcode app, no matter the configuration (a setting is planned to be added in `master` to let the possibility if the user wants); - Add the possibility to allocate from the forecast report. For more details on these changes or other fixes, check the corresponding commit's message. _________ **Enterprise PR:** odoo/enterprise#122258 task-4894566 Forward-Port-Of: odoo/odoo#272722
The barcode app’s print button now prints labels for the allocated products instead of the allocation operation report. This helps warehouse users get the right labels directly from barcode lines, reducing confusion and manual reprints.
Original PR description
Before this commit, the print button on barcode line printed the allocated operation's report instead of the allocated products' labels. This commit fixes that. _________________ **Community PR**: odoo/odoo#272722 [task-4894566](https://www.odoo.com/odoo/966/tasks/4894566) Forward-Port-Of: odoo/enterprise#122258
Adds checks before sending Turkish Nilvera e-invoices so users are warned when invoice lines are missing required taxes or product/CTSP details. This helps prevent invoices from being rejected by Nilvera, while avoiding unnecessary warnings for note or section lines.
Original PR description
Nilvera does not accept invoices with lines that do not have taxes, so we added a valiation check for sending the invoice to warn the user. Additionally, we raise a warning when a line does not have a product and has an empty CTSP. However, if the line is a note or section, this warning should not be triggered. task-6404409 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#284969 Forward-Port-Of: odoo/odoo#284377
Restarting a live chat chatbot session now correctly shows the available answer choices again. This prevents visitors from getting stuck or confused when they restart a conversation before it has been fully saved.
Original PR description
Before this commit, after restating a chabot session, the chabot question answers were not shown. This happens since the change in [1], introducing the field `selectedAnswerEver` in order to solve problems of stale server writes. However when a session is restarted, the first chatbot steps without a "real" message record (before the session is persisted) resolve to the same records of the earlier session. In turn this leads to said step having a selected answer already and thus not showing the choice. This commit solves the issue by clearing the selected answer fields when going to the next step, which is acceptable against stale writes since it's a purely client side decision. task-6535116 [1] https://github.com/odoo/odoo/pull/278597
Turkish credit notes created from existing invoices now use the dedicated sales return account from the sales journal instead of incorrectly keeping the original sales account. This improves accounting accuracy for Turkish companies while preserving exact matching for cancellation reversals.
Original PR description
The Turkish chart of accounts keeps sales and sales returns on separate accounts, and the sales journal carries the account to use for returns. A credit note typed in by hand already lands on it, but one created from an existing customer invoice did not. Reversing an invoice copies `account_id` over from the invoice line, and since that field is a stored compute without depends, nothing ever recomputes it, so the return kept the sales account. Set the journal account on the copied product lines instead. Reversals made to cancel an entry are left alone, as those have to mirror the original move exactly for the two to net out, and a plain duplicate is untouched. Task-6438412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284808 Forward-Port-Of: odoo/odoo#282858
E-invoice imports and exports no longer include internal deferred revenue dates that are only relevant to the vendor's accounting process. This prevents customers from receiving irrelevant date information and avoids creating deferred entries when importing vendor bills.
Original PR description
The current implementation of the Peppol XML export incorrectly populates the <cac:InvoicePeriod> nodes with internal deferred entry dates. These dates are intended for the vendor's revenue recognition process, and the customer has nothing to do with these dates. This commit ensures that: - deferred entries are never created when importing vendor bills. - <cac:InvoicePeriod> is no longer exported in invoices (for now). task-6014315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281348 Forward-Port-Of: odoo/odoo#265796
Fixes a Razorpay FPX payment issue that could cause checkout to fail when customers returned from the payment page. The payment flow now handles missing return details correctly, improving reliability for merchants using Razorpay FPX.
Original PR description
Issue: --- Paying with Razorpay using FPX raises `KeyError: 'amount'` when the customer returns from checkout. Steps to reproduce: 1- Enable Razorpay with FPX as a payment method. 2- Pay an order using FPX. Cause: --- In FPX, Razorpay returns without `amount`/`currency`. `_apply_updates` fetches the full payment from the API to determine the state, but that fetched entity is local to the method and never reused for amount validation, so `_process` still calls `_validate_amount` / `_extract_amount_data` with the original, amount-less redirect data. This issue is introduced after c34992ffd94ba4594731400839332b677fdc2b32, which removed the check in `_extract_amount_data` that returned `None` (skip validation) when `amount`/`currency` were absent. opw-6467815 Forward-Port-Of: odoo/odoo#286476
Stripe SEPA payments no longer use the order reference as the bank statement descriptor, avoiding failures when an order number contains only digits. The descriptor now uses the company name again, making SEPA payments more reliable for affected customers while preserving expected statement information.
Original PR description
**Steps to reproduce:** 1. Install Sales, l10n_be, payment_stripe and switch to belgian company 2. Switch the admin user's company to the belgian one, and update their contact address to be in…
**Steps to reproduce:** 1. Install Sales, l10n_be, payment_stripe and switch to belgian company 2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium 3. Enable stripe payment provider 4. Add SEPA payment method in stripe configuration 5. Create a sale order with a name that doesn't include any characters (numbers only), confirm, click preview and attempt to make a payment using SEPA **Issue:** `The statement descriptor must contain at least one Latin character.` **Cause:** The previous fix (4fde0232b821c9a1d46d589ff14495f4e19029f4) passed the order reference directly, assuming it will contain characters. The intended behavior is to actually have the company name used in the statement descriptor field: https://support.stripe.com/questions/what-is-a-statement-descriptor-and-how-do-i-update-it This was the existing behavior before the fix, so will revert back to it. opw-6497127 Forward-Port-Of: odoo/odoo#286620 Forward-Port-Of: odoo/odoo#286287
Colombian retention reports now calculate the taxable payment amount correctly when vendor bills include partial credit notes. This prevents credit notes from incorrectly increasing the reported tax base, improving accuracy for retention certificates and related tax reports.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_co_reports and account_accountant 2. Create a bill, with a line with a retention tax (3.50% RteFte). 3. Create a partial credit note (unit price less than what's on the bill). 4. Goes to the report 'Certificado de Renteciòn en Fuente', and notice the Monto del Pago Sujeto Retenciòn is not correct. **CAUSE** The sql query multiply tax_base_amount by -1 if debit > 0, which means (because we are dealing with vendor bills) the line is from a credit note, but tax_base_amount is already a signed value so credit notes ends up contributing to the tax base amount while they should reduce it. opw-6235830 Forward-Port-Of: odoo/enterprise#130340 Forward-Port-Of: odoo/enterprise#119716
Invoice import and export now avoids using internal deferred revenue dates that are only relevant to the vendor. This prevents customers from receiving irrelevant accounting dates in Peppol invoice data while preserving the needed Colombian support document behavior.
Original PR description
The current implementation of the Peppol XML export incorrectly populates the <cac:InvoicePeriod> nodes with internal deferred entry dates. These dates are intended for the vendor's revenue recognition process, and the customer has nothing to do with these dates. This commit ensures that: - deferred entries are never created when importing vendor bills. - <cac:InvoicePeriod> is no longer exported in invoices (for now). But it is kept for the colombian localization in case of support documents though. task-6014315
Changing Peppol Reception Mode to receive invoices as documents no longer triggers an error. This helps Belgian companies using Peppol complete setup smoothly without interruption.
Original PR description
Steps to reproduce: - Install `documents_account_peppol` and `l10n_be` module - Switch to BE Company > `Activate Peppol` - Change `Peppol Reception Mode` -> `Receive as Documents` Traceback: `AttributeError: 'res.company' object has no attribute '_peppol_allows_document_reception'` Problem: Changing the `Peppol Reception Mode` to `Receive as Documents` causes an `AttributeError` because `_compute_peppol_purchase_journal_required()` calls `_peppol_allows_document_reception()` on `config.company_id`, but the method is defined on `res.config.settings`. Cause: The method is available on the `res.config.settings`, not on the `res.company`. Solution: Add `_peppol_allows_document_reception()` method in `res.company` and call company's method from the `res.config.settings` method. opw-6470552 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286517
Fixed an issue in Documents where choosing “Search More...” from fields like Owner or Customer could immediately close the selection window. Users can now interact with that window normally, making it possible to search, sort, and select the right related record without interruption.
Original PR description
Steps to reproduce: 1. Install Documents 2. In the Documents list view, select a document to display the inspector. 3. Edit a field such as Owner or Customer which uses a Many2one widget. 4. In the…
Steps to reproduce: 1. Install Documents 2. In the Documents list view, select a document to display the inspector. 3. Edit a field such as Owner or Customer which uses a Many2one widget. 4. In the field dropdown, click "Search More..." to open a modal dialog. 5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers). Issue: - The modal dialog immediately closes, and the contact cannot be selected. Root cause: - When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack. Solution: - Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer. Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear the main selection and destroy the inspector field. opw-6253360 Forward-Port-Of: odoo/enterprise#128812 Forward-Port-Of: odoo/enterprise#119262
Manual quality checks created from a picking can now record a partial failed quantity without blocking the transfer. This prevents validation errors and lets warehouse teams continue processing orders when only some units fail inspection.
Original PR description
Version: -------- - 19.0+ Steps to reproduce: ------------------- - Install `quality_control` module - Create a picking order with a product - From the gear menu, create an on-demand Quality Check -…
Version:
--------
- 19.0+
Steps to reproduce:
-------------------
- Install `quality_control` module
- Create a picking order with a product
- From the gear menu, create an on-demand Quality Check
- Set the check to *Control per Quantity* and back to the picking
- Set the done quantity to 10
- Open the Quality Check wizard
- Try to fail 3 units
Issue:
------
Validating the partial failure raises a `ValidationError`:
- Missing required value for the field 'Team' (team_id)
The quality check split is not performed and the picking cannot be processed.
Cause:
--------
Quality checks created on-demand from the picking (via the gear menu) have
no associated `quality.point` or `stock.move.line` — only
`picking_id` is set at creation time.
https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L457
In `_move_to_failure_location()`, the `move_line` branch assumes
`check.move_line_id` is populated. Since it is empty for on-demand
checks, the split logic operates on an empty recordset.
The new quality check for the split is then created via:
https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L493
At this point both `failed_move_line` (a copy of the empty move line) and
`check.point_id` are empty. `_get_check_values(False)` cannot derive
fields normally sourced from the quality point (`team_id`, `company_id`,
`measure_on`, `test_type_id`, etc.), causing the `ValidationError` on record creation.
Fix:
----
- If the quality check is not linked to a move line, find the matching move line
from the picking before splitting the failed quantity.
https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/stock_move_line.py#L94-L97
- `_get_check_values()` normally takes values from a Quality Point.
Since on-demand quality checks do not have one, fill the missing
values (`team_id`, `measure_on`) from the original quality check instead.
This allows manually created quantity-based quality checks to be
split correctly after a partial failure.
---
opw-6428749
Forward-Port-Of: odoo/enterprise#130275
Forward-Port-Of: odoo/enterprise#126505Fixed an issue where importing multiple Belgian SODA files at once could copy accounting lines from the first file into the second. This helps ensure imported payroll accounting data stays accurate and avoids duplicate or incorrect entries.
Original PR description
Due to this commit: https://github.com/odoo/enterprise/commit/93c05b380e3c939e3c0b44eafcd7a41e86042d2d When importing 2 sodas from drag and drop. Due to the placement of the line_ids variable, the second move would have the line of first. By placing the variable in the loop we don't have that problem anymore task-6528101 Forward-Port-Of: odoo/enterprise#130190
The Shopee sales integration now continues processing shipment label batches even if one batch has incomplete or unexpected data from Shopee. This reduces failed background jobs and helps remaining shipments keep moving without manual intervention.
Original PR description
Currently, an error occurs when the `sync_shopee_pickings` cron tries to fetch shipment labels for multiple batches of shipments. If some shipments do not contain the required data in the Shopee API…
Currently, an error occurs when the `sync_shopee_pickings` cron tries to fetch
shipment labels for multiple batches of shipments. If some shipments do not
contain the required data in the Shopee API response, the error causes the
cron to stop, preventing the remaining batches from being processed.
Error:
`ValueError: KeyError('status') while evaluating 'model._sync_shopee_pickings()'`
This issue was introduced by a recent refactoring commit [1] focused on linting
and formatting the Python file. The commit replaced the generic `Exception`
with `UserError` when handling errors during batch label printing.
As a result, errors other than `UserError` are no longer handled at the batch
level. When such an error occurs, the entire cron process stops instead of
failing only the affected batch and continuing with the remaining batches.
This commit fixes the above issue by handling generic `Exception` during
shipment label generation, ensuring that the error is handled for the
affected batch while the remaining batches continue to be processed.
[1]: https://github.com/odoo/enterprise/commit/cfe5d947579739ad770ac3f1525ce157af530846#diff-e072c3ecf980add685bb4a4f25cf2b0ab5d4625988e4afc2c4d4faeae687ca88R199
sentry-7685943988
Forward-Port-Of: odoo/enterprise#130295
Forward-Port-Of: odoo/enterprise#130181