Monday, August 4, 2025
30 changes · saas-18.3
Resolved issues and error corrections
In multi-website setups, customers will now only see and use payment providers configured for the website they are visiting. This prevents confusion and reduces the risk of payments being started with providers that are not meant for that site.
Original PR description
In a multi-website environment, payment providers are often configured specifically for each website using the `website_id` field. While the checkout page (`/shop/payment`) correctly filters providers by the current website, other routes such as `/my/payment_method` or `/payment/pay` flows do not apply this filtering consistently. This patch ensures that the `website_id` constraint on payment providers is respected across all relevant flows, improving consistency and preventing users from seeing or using providers that are not available for their current website. Without this patch, users may see or select payment providers that are not intended for their site, leading to potential confusion, incorrect transactions, or access to providers that are not supported on the current website. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218985 Forward-Port-Of: odoo/odoo#218089
This update brings the spreadsheet component up to its latest maintenance version and fixes an issue where chart-related extensions could load too late. Users should see more reliable spreadsheet chart behavior, with a small supporting improvement to demo error handling.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9499d989e [REL] 18.3.15 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8c41a1bc3 [FIX] chart: chartJS extensions loaded too late [Task: 4954034](https://www.odoo.com/odoo/2328/tasks/4954034) https://github.com/odoo/o-spreadsheet/commit/f921fe1d7 [IMP] demo: Add error handler [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Updating an Odoo chart in a spreadsheet now keeps the spreadsheet's global filters applied. This prevents chart data from unexpectedly ignoring shared filters, helping users see consistent and accurate reporting after edits.
Original PR description
The global filters were not re-applied when updating an oodo chart domain. Task: [4965683](https://www.odoo.com/odoo/2328/tasks/4965683) 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#221534 Forward-Port-Of: odoo/odoo#220764
Spanish VeriFactu POS now checks the configured simplified invoice limit instead of relying on a fixed €400 threshold. This keeps invoice handling aligned with current localization settings and reduces the risk of incorrect simplified invoice decisions.
Original PR description
In 18.0+ there is a field that determines the amount up to which an invoice can be simplified (`l10n_es_simplified_invoice_limit`). After this commit we use that instead of the hardcoded limit of 400 € that was used in 17.0. task-None Forward-Port-Of: odoo/odoo#221347
Portal users who follow a project task can now open the task from the “View Task” link in notification emails. This fixes a permissions issue that prevented the link details from being read, improving access for external collaborators.
Original PR description
To reproduce: ============= - on a project task where a portal user is follower send a message - the portal user should receive an email with a link to the task on the button "View Task" -> the link is not working Problem: ======== starting from 18.3, a method to check field access was added to the project task model, `access_token` and `access_url` were not in set of readable fields for portal users, so the link was not working. Solution: ========= add `access_token` and `access_url` to the set of readable fields for portal users. opw-4939913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Past-date inventory reports now avoid counting internal warehouse transfers as customer deliveries. This prevents available stock from being overstated for products using multi-step delivery routes, making historical stock reports more reliable for operations and planning.
Original PR description
Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report For products using multi-step delivery routes, the…
Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report For products using multi-step delivery routes, the `_compute_quantities_dict()` method incorrectly treated internal moves as outgoing moves As a result, the same outgoing quantity was added multiple times, leading to an overestimation of the available stock This commit adds a filter to the `domain_move_out_done` domain used for past dates, excluding internal moves based on `location_dest_usage`` ## Steps to reproduce: - Create a new product - Active the multi-step routes in Settings - Set the Warehouse's Outgoing Shipments to Pick, Pack, then Deliver - Create a RFQ for 100 products and Receive Products - Create a Quotation for 20 products - Validate each delivery steps - Go to Inventory -> Report -> Stock - Click on Inventory At - Set the date to 2025-01-01 - Search for your product - The `In Hand` quantity should be 0 but is 40 before the fix opw-4848473 Forward-Port-Of: odoo/odoo#217732
Branch-only users can now open the Chart of Accounts without being blocked by an access error. This ensures accounting configuration remains available to users who are correctly limited to a branch, avoiding disruption in multi-company setups.
Original PR description
#### Steps to reproduce
- Create a branch in a company that has a CoA installed.
- Create a user that only has access to the branch
- Login as the user
- Try to open Accounting > Configuration > Chart of Accounts
- You get an AccessError in your face.
#### Analysis
- When calling `web_search_read` on `account.account`, the `company_ids` field is loaded into cache by `search_fetch`.
- Since the user does not have access to the parent company, the parent company will not be in the account's `company_ids` in cache.
- When calling `_check_access` in `fetch`, the `filtered_domain` (even though it is called behind `sudo`) will use the `company_ids` in cache to determine whether the accounts can be accessed, triggering the `AccessError`.
#### Solution
- Set `depends_context=('uid',)` on the `company_ids` field to keep separate sudo / non-sudo caches for the field.
opw-4730107
Forward-Port-Of: odoo/odoo#220294
Forward-Port-Of: odoo/odoo#217752The delivery package type list now respects the sequence set by inventory users instead of showing items by creation order. This makes package selection more predictable and aligned with the configured business workflow.
Original PR description
#### Step to reproduce: - Go to Inventory > Configuration > Settings and enable Packages - Go to Inventory > Configuration > Package Types - Inverse the order of two packages types. The goal is for…
#### Step to reproduce: - Go to Inventory > Configuration > Settings and enable Packages - Go to Inventory > Configuration > Package Types - Inverse the order of two packages types. The goal is for the sequence order to differ from the id order. (you can display id with studio) - Go to Inventory > Overview > Delivery Orders - Create a new delivery order - Add a line - In 'Additional Info' add a Carrier - Go to Barcode > Operations > Delivery Orders - Select the delivery order (you might need to remove filters) - With the 'Add Product' button add a product - Click on 'Put in Pack' - A 'Package Details' wizard should have opened. In this wizard there is a field 'Delivery Package Type'. #### Current behavior: - In the delivery package type dropdown list, packages are ordered by id #### Expected behavior: - In the delivery package type dropdown list, packages should be ordered by sequence #### Cause of the issue: As no order was defined, stock.package.type was ordered by id which is the default behavior opw-4824064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220327
Archived time off types are now hidden from the Employee app, so employee profiles only show active and relevant time off balances. This prevents outdated or inactive leave categories from confusing HR teams and employees.
Original PR description
In this bug, if a time off type is archived, it is still displayed in employee app. Steps to reproduce the bug: 1- Create a database with employee and time off modules installed 2- Allocate a time off to an employee 3- Archive the time off type 4- Open Employee app and go to the employee profile 5- The archived days are still displayed opw-4900060 Forward-Port-Of: odoo/odoo#221335 Forward-Port-Of: odoo/odoo#217517
Fixed an issue where the website event “Registered” banner could appear or disappear inconsistently because cached event pages reused the wrong display state. Visitors now see more reliable event registration status across sessions and refreshes.
Original PR description
We had an inconsistent display of the Registered banner for events on the website. The banner would appear or disappear randomly, regardless of whether the user was logged in or not. Steps to reproduce: ------------------- - start the server - log in as a user that does not have access to website editor - get a ticket for an event - go to the event list -> event is marked register - go to the event page in a new browser session (incognito) -> event is still marked register > Observation: On refresh, Registered green banner on events appear and disappear randomly Why the fix: ------------ Keys that are not stored on the table of event should be added to the cache key to force a re-render when they change, or t-nocache should be used opw-4819021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220053
This fix prevents an error when users receive almost all subcontracted goods and choose not to create a backorder for the small remaining quantity. The system now correctly cancels the leftover manufacturing order instead of trying to set it to zero, allowing the receipt process to finish smoothly.
Original PR description
Steps to reproduce the bug: - unarchive the subcontracting route - Create a storable product C1 with the following route: - Buy + Resupply Subcontractor on Order - Create a storable product P1 with:…
Steps to reproduce the bug:
- unarchive the subcontracting route
- Create a storable product C1 with the following route:
- Buy + Resupply Subcontractor on Order
- Create a storable product P1 with:
- BoM type: Subcontracting - Type: subcontracting - Subcontractor: Azure Interior - Component: C1
- Create a purchase order for 20 units of P1
- Confirm the purchase order
- Validate the resupply transfer
- Go to the receipt of P1
- Record 19.8 units of the component (ignore the remaining 0.2)
- Validate the receipt with no backorder
Problem:
A user error is raised:
```
The operation cannot be completed: The quantity to produce must
be positive!
```
When clicking No Backorder, the `process_cancel_backorder` method is
called:
https://github.com/odoo/odoo/blob/18.0/addons/stock/wizard/stock_backorder_confirmation.py#L75-L77
This triggers the validation of the picking, so updates the subcontract
order quantity:
https://github.com/odoo/odoo/blob/16a1d9b19b8b07435a9c4b4db2cad3c1e37e4e17/addons/mrp_subcontracting/models/stock_picking.py#L53
At this stage, we check whether it should reduce the MO quantity or
cancel the order entirely. However, the logic compares the quantity to
remove against the initial order quantity without using `float_compare`,
which leads to minor rounding differences. This results to update the
MO quantity to zero instead of canceling it, which then triggers an SQL
constraint error because the MO quantity cannot be zero:
https://github.com/odoo/odoo/blob/e7e2a088495eed3c2886a69054af689c01628f32/addons/mrp_subcontracting/models/stock_move.py#L304-L311
https://github.com/odoo/odoo/blob/29d1f637d3ec6f3ebb218d103001a6182af1b8a4/addons/mrp/models/mrp_bom.py#L93-L95
opw-4905031
Forward-Port-Of: odoo/odoo#221451
Forward-Port-Of: odoo/odoo#219650This fixes a crash in the Indian localization when a company removes its VAT/GST number and then uses the GST warning update action. Users can now leave the VAT field empty without encountering an error, improving stability in company tax setup workflows.
Original PR description
Currently, a traceback is occurring when the user clicks on the update button of GST warning after removing the vat. To reproduce this issue: 1) Install l10n_in 2) Open the Indian company 3) Change…
Currently, a traceback is occurring when the user clicks on the update button of GST warning after removing the vat. To reproduce this issue: 1) Install l10n_in 2) Open the Indian company 3) Change the VAT to get the GST warning 4) After getting the GST warning remove the VAT and click the `update it` button Error:- ``` TypeError: 'bool' object is not subscriptable ``` On company, VAT is not a required field, so the user can indeed remove it. When the user removes the vat and clicks on the `update it` button from GST warnings, the `action_update_state_as_per_gstin` method triggers. https://github.com/odoo/odoo/blob/c96d2b1d1ee917b1c665842010c56c23df91ccd3/addons/l10n_in/models/res_partner.py#L99-L101 From the above method we try to access the vat value. Here in our case, the `VAT` value is False. So it leads to the above traceback. We can resolve this issue by adding check, which makes the code more robust. sentry-6151570042 Forward-Port-Of: odoo/odoo#190840
Applying a partnership grade to a company or contact now affects only that specific partner, not its related child contacts. This restores the intended behavior and prevents unintended partnership status changes on linked contacts.
Original PR description
This reverts commit 9d1857e so that applying a grade no longer adds it to the children of the partner as well. TASK-4985900
Updating a blog cover image or filter now avoids saving unintended changes to the underlying website template. This helps prevent duplicated styling information and keeps blog pages stable after editing cover images.
Original PR description
Since summernote was replaced by the editor, the record cover template becomes `o_dirty` and therefore gets saved when a cover image is changed. This commit solves this by marking the record cover components readonly inside the DOM. Steps to reproduce: - install website_blog - set a blog cover image or specify its filter - save => The `record_cover` template was saved with the modifications, thus combining `t-att-style` and `style` attributes. task-jke Forward-Port-Of: odoo/odoo#219013
This fix prevents an error when validating a returned delivery linked to a sales order whose original line was deleted. It helps users complete stock return workflows reliably, even after a sales order has been cancelled and changed.
Original PR description
The error occurs when a SO line is deleted, and a return is processed for the associated delivery using a different product, after which the return is validated. Steps to reproduce: --- - Install the `sale_management` and `stock` modules - Create & Confirm an SO for one product - Now cancel that SO and remove that product - In Stock > Deliveries > Open that delivery(Cancelled) - Click on the `Return` button and add any product > Return > Validate Traceback: --- `ValueError: max() iterable argument is empty` At [1], a ValueError is raised because there are no SO lines, resulting in an empty sequence is being passed to the max() function. [1]- https://github.com/odoo/odoo/blob/deab3cafc8b3cd79dcc52fddd9511a38a7e77afa/addons/sale_stock/models/stock.py#L68 sentry-6709665025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The activity menu now shows only ongoing activities, so completed items no longer remain visible as late or pending work. This reduces confusion for users and keeps activity counts aligned with what still needs attention.
Original PR description
**Current Behavior:** When users click on the activities icon, both active and archived activities are displayed. This can lead to confusion, as users expect to see only ongoing (i.e., pending or…
**Current Behavior:** When users click on the activities icon, both active and archived activities are displayed. This can lead to confusion, as users expect to see only ongoing (i.e., pending or overdue) activities. **To reproduce this issue:** 1) Install the Contacts module and create two partner records. 2) Create a late activity for each of the two records. 3) Mark one activity as Done by clicking the DONE button. 4) Open the Late Activities for Contacts from the top-right corner. **Issue:** Even after marking one activity as done, both activities are shown. This results in two late activities appearing, instead of just one active one. **Cause:** When an activity is marked as Done, the `action_feedback` method is called via `markAsDone`. https://github.com/odoo/odoo/blob/7fa14f9b8e2e886243d68d8e04b0798cd801615b/addons/mail/static/src/core/web/activity_model_patch.js#L44-L48 This method archives the corresponding `mail.activity` record. https://github.com/odoo/odoo/blob/7fa14f9b8e2e886243d68d8e04b0798cd801615b/addons/mail/models/mail_activity.py#L556-L557 But because of the recent changes from the below-mentioned commit, we are now showing the archived records. https://github.com/odoo/odoo/commit/f05c2f9c7942943140c98174f8c86917fc72fc9b#diff-cacfccf65b597df222b166a1c6d80d125bb75a1f2aeabf2eed2e88e189c144f0R59 However, this change was intended to display archived model records that still have active activities, not to show archived or completed activities themselves. **Solution:** Apply a domain filter to ensure that only active (non-archived) activity records are displayed. opw-4946120
Accounting system logs now keep error messages in a consistent original language, making issues easier to investigate across different language settings. User-facing error messages remain translated, so day-to-day users continue to see messages in their preferred language.
Original PR description
Currently, error messages in logs are translated, which can make it difficult to debug issues — especially in multi-language environments or when analyzing logs programmatically. This commit ensures logs use the original, untranslated message templates for clarity and consistency, while keeping translations for user-facing errors. sentry-6763108230 Forward-Port-Of: odoo/odoo#221498
The French POS inalterability check report now loads only the data it needs when verifying order integrity. This greatly improves performance and reduces memory pressure for businesses with large volumes of POS orders, helping audits complete reliably instead of timing out.
Original PR description
### Problem: Pos inalterability Check report is specific to French localization. It verifies whether POS orders have been modified by computing a hash of the order data and comparing it to the previously stored hash. _compute_string_to_hash method is computationally expensive and leads to significant performance and memory issues when processing more than 50,000 orders. ### Benchmark Before: | Orders | Time | Memory | |--------|---------|--------| | 1k | 15s | 10MB | | 10k | 77s | 81MB | | 20k | 102s | 110MB | | 40K | timeout | 256MB | After: | Orders | Time | Memory | |--------|------|--------| | 1k | 5s | 7MB | | 10k | 9s | 42MB | | 40K | 20s | 174MB | | 100k | 42s | 550MB | | 330k | 126s | 1.2GB | ### Solution: Fetching only required fields to compute _compute_string_to_hash opw-4901994 Forward-Port-Of: odoo/odoo#221218 Forward-Port-Of: odoo/odoo#217348
The Website settings label for Google Search Console has been corrected from an awkward word order to the proper product name. This makes the setting clearer for users configuring Google Search Console integration.
Original PR description
Before this commit, the Google Search Console label in the settings was wrongly displayed as "Console Google Search". This commit replaces this field label with "Google Search Console". task-3839274 Forward-Port-Of: odoo/odoo#182790
Invoice and sales email subtitles now avoid displaying “False” when sent to invoice-address contacts without a contact name. This keeps customer-facing emails cleaner and more professional in common accounting and sales workflows.
Original PR description
**Steps to reproduce:** 1. Install *Accounting* and *Contacts*. 2. Create a company contact with a name & address. 3. Add a child contact: Type = “Invoice address” **Leave the Contact Name blank** 4. Configure an outgoing mail server. 5. Create & confirm a customer invoice for created invoice‑address contact. 6. Click Send, send the invoice email, and check subtitle — it displays `False`. **Issue:** - When the invoice is emailed to a contact without a name, the email subtitle shows False, for example: `INV/2025/00006 - False` **Note: Same issue for Sales** **Cause:** - The rendering logic only checked that `partner_id` existed, not whether `partner_id.name` was non‑empty - Since name was not mandatory for address-type Invoice Address, this resulted in `False` appearing in the email subtitle. **Solution:** - Add an check for the validity of partner_id.name when generating the email subtitle. **opw-4939158** Forward-Port-Of: odoo/odoo#219881
Payment links for recurring sales orders now use the next invoice amount instead of adding past payments or transactions. This prevents customers from seeing incorrect payment amounts after previous subscription billing cycles.
Original PR description
Before this commit,when a payment link was generated for a recurring SO already invoiced, the default values of amount and amiunt_max would take into account all previous transactions. As a result, the amount would be badly computed as recurring order have many transactions (at least once or each period). This commit ensure to use the next invoice amount. taskid: 4352396 Forward-Port-Of: odoo/enterprise#83934
Bank reconciliation now preserves the original foreign currency amount when recalculated values are close enough, avoiding artificial one-cent differences caused by exchange-rate rounding. This helps invoices reconcile correctly and reduces unnecessary accounting discrepancies for multi-currency transactions.
Original PR description
The aim of this commit is to keep the original foreign amount currency if the computation ends up close enough to it. Before this commit: The reconciliation process was losing so much precision that…
The aim of this commit is to keep the original foreign amount currency if the computation ends up close enough to it. Before this commit: The reconciliation process was losing so much precision that it could mess up the reconciliation of one single invoice. After this commit: We keep the original amount as it is most probably the correct one. Context: With a rate of 1 US$ = 5.421327349 R$ and an invoice of 143.62 R$, we convert the amount in US$ which is 26.491668921649627 US$. As we have to round it for the accounting, we end up with 26.49 US$ as company currency amount, losing the rest of the decimals. During the reconciliation process, we convert back the US$ to R$ ending up with 143.61096147501 R$ that have to be rounded to 143.61 R$. This creates a difference of 0.01 R$ which surfaces later on. Chosen solution: As we still have the original currency amount and the rate, we are able to recompute the raw numbers and we are able to make "fairer" comparison between the amounts. If we can confidently tell that the amounts are close enough, we can just keep the original amount and prevent all those rounding errors to be taken into account. opw-4937508
Fixes several cases where importing WinBooks accounting files could fail because of account, tax, journal, or deprecation validation rules. This helps businesses complete accounting data imports more reliably, even when source files contain inconsistent references.
Original PR description
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it…
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80 *Note* Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines **Issue 2** Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal **Issue 3** Account created during import may be marked for deprecation, which occurs at the end of the import process. However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error. https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028 opw-4850314 Forward-Port-Of: odoo/enterprise#89426
Fixed an issue where administrators could not preview certain subscription sale orders if no salesperson was assigned in website settings. This prevents an error page and keeps subscription order review working normally after portal purchases.
Original PR description
**Steps to reproduce:** 1. Install sale_subscription, payment_demo and eCommerce 2. Go to Website → Configuration → Settings and clear the Salesperson field 3. Create a subscription product with recurring plan and publish it. 4. Place an order for this product as a portal user and complete payment. 5. Log back in as admin, open the related Sale Order, and click Preview **Issue:** A traceback occurs:- ```"ValueError: Expected singleton: res.users()"``` This happens in _prepare_partner_addresses because user_id is not set on the Sale Order. **Cause:** https://github.com/odoo/enterprise/blob/6b449769d4bf2cdf6517a026706fd6ea55832975/sale_subscription/controllers/portal.py#L233 The code calls has_group on order_sudo.user_id without checking if user_id exists, leading to an empty recordset and singleton error. **Solution:** Add a fallback to handle cases where user_id is not defined, defaulting to False for multiple_addresses_enabled. opw-4947508
This fixes partner commission and subscription partnership behavior so applying a grade to a company or contact no longer automatically applies it to related child contacts. It also restores the needed module dependency so partnership removal works correctly when installing partner commission.
Original PR description
This reverts commit 14001a8a0216750be0c897d0e1bf31fccfc51c6a so that applying a grade no longer adds it to the children of the partner as well. This commit also fix the issue of not having sale_subscription_partnership in the manifest of partner_commission, which results in the _remove_partnership method not working when installing partner_commission. TASK-4985900
This fix prevents barcode scanning from failing on iOS when the confirmation sound is unsupported or blocked by browser permissions. Users can continue scanning normally, while any sound playback issue is safely logged instead of interrupting the workflow.
Original PR description
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan…
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan a barcode --> Traceback Discussion ----- There are 2 issues occuring here. 1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''. https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value This means that when we do https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37 We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy. To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail: https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46 2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors. ----- Ticket: opw-4820022 Forward-Port-Of: odoo/enterprise#91158
This fixes an error that could occur when a user manually entered a tracking reference for a Sendcloud delivery. Instead of crashing, the system now handles missing Sendcloud parcel data cleanly and shows the normal user-facing error flow.
Original PR description
**Steps to reproduce:** 1. Install delivery_sendcloud. 2. Create a new shipping method (Inventory -> Configuration) - Provider: sendcloud - Put the public and secret key - Assign Delivery Product 3.…
**Steps to reproduce:** 1. Install delivery_sendcloud. 2. Create a new shipping method (Inventory -> Configuration) - Provider: sendcloud - Put the public and secret key - Assign Delivery Product 3. Create a sales order with a deliverable product 4. Confirm the sale order 5. Go to the delivery 6. Manually enter a random tracking reference. 7. Make sure carrier is set to the Sendcloud delivery method 8. Click on "tracking," or get back to the sales order (click "preview"). 9. A traceback occurs. **Issue:** `A TypeError: 'bool' object is not subscriptable` when accessing sendcloud_parcel_ref, which is expected to be a list or JSON but is instead a boolean. **Causes:** The code assumes the presence of valid Sendcloud parcel reference data, but manually entering a tracking reference bypasses the [_send_shipment](https://github.com/odoo/enterprise/blob/6ecf0af6b6874460d300ede6cc7c092927607810/delivery_sendcloud/models/sendcloud_service.py#L102) method that populates this field. As a result, sendcloud_parcel_ref can remain False. https://github.com/odoo/enterprise/blob/df924ef8adffb3e42419a44ecf22fec3059917c4/delivery_sendcloud/models/delivery_carrier.py#L196 **Solution:** Return None if there is no Sendcloud parcel reference, which will raise a UserError from the below line https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L288 Co-Author By - alsh@odoo.com opw-4894677 Forward-Port-Of: odoo/enterprise#89444
The point of sale settlement process now loads only invoices linked to the selected POS configuration, instead of trying to load every invoice in the system. This prevents memory failures in large databases and keeps POS operations more reliable.
Original PR description
Issue: - The `_load_pos_data` method was fetching all `account.move` records instead of only those related to the POS orders of the selected configuration. - This caused MemoryError Cause: - The [_load_pos_data](https://github.com/odoo/enterprise/blob/saas-18.3/pos_settle_due/models/account_move.py#L18-L20) method used an empty domain (`[]`) because the `_load_pos_data_domain` method was not properly implemented. - As a result, `search_read` fetched all available `account.move` records in the system, regardless of the POS config context. Fix: - This commit implements `_load_pos_data_domain` to: - Retrieve only POS orders for the current config with linked invoices. - Extract their related `account.move` IDs. - Return a domain to limit the search to only those move IDs. ``` rari_3017353=> select count(*) from account_move; count --------- 1607249 (1 row) ``` task-4920625
Restaurant bookings made through the website now show the correct number of guests when opened in the PoS booking view. This prevents staff from seeing a misleading zero guest count and helps them prepare tables accurately.
Original PR description
Steps to reproduce: --- - Install `pos_restaurant`, `pos_appointment`, and `website` modules. - Book a table appointment via the website for X people. - Open the Restaurant PoS and go to the "Booking" tab. - Open the appointment created above. Issue: --- - The people count shows as 0, even though the appointment was booked for X people. Cause: --- - In version 18.3, a new field was introduced to track the number of people. - This field was not being populated when the appointment was created outside the PoS UI. Fix: --- - Ensure the new people count field is set correctly when the booking is not created from the PoS interface. task-4848208
Fixed an issue that could cause spreadsheet thumbnail updates to fail when several records were processed at the same time. This improves reliability for users working with spreadsheet-linked records, such as sales order spreadsheets.
Original PR description
The `_inverse_display_thumbnail` method raised a `ValueError` when called on multiple records, due to direct access to `self.display_thumbnail` on a multi-record recordset. Traceback: `ValueError: Expected singleton: sale.order.spreadsheet(43, 44, 45, 46)` At [1], the code now correctly iterates over each `spreadsheet` in `self` to ensure accurate processing for each record. [1]- https://github.com/odoo/enterprise/blob/9d51f5171b3c2478599dde1ce991c90fa6fed32b/spreadsheet_edition/models/spreadsheet_mixin.py#L619 sentry-6615551353