Daily updates from Odoo
Tuesday, July 29, 2025
25 changes · 18.0
Enhancements to existing features
Task searches in Projects were slowed down by checking task IDs alongside task names. This change removes the ID check from the standard search form, making name searches much faster on large databases while preserving the main task search experience.
Original PR description
### Issue Slowness when searching for tasks in a database containing ~430K `project.task` records. ### Analysis When searching for tasks by name, the `id` field is passed to the filter domain. This results in a suboptimal query plan, as the `id` field is cast as `text` in an `OR` leaf: ` [...] AND ((unaccent((name)::text) ~~* '%test%'::text) OR ((id)::text ~~* '%test%'::text)) [...]` Furthermore, since refactoring the web routes, the necessity of searching for an `id` in the search form has greatly diminished. ### Benchmarks Benchmarking the generated query using `\timing` in `psql`: | Number of records | Before | After | | -- | -- | -- | | 430K | 2.3s | 3ms | During high-usage periods, the query took up to ~10.8 seconds. #### References opw-4845258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219959 Forward-Port-Of: odoo/odoo#219901
Updating account codes through account mapping is now optimized to avoid unnecessary recalculations across many accounting entries. This helps prevent memory errors and improves reliability for companies with large accounting datasets.
Original PR description
Description of the issue this commit addresses: Changing the account code via account mapping triggers a recompute of all related account.move fields (such as always_tax_exigible), which can cause memory errors or severe performance issues when many moves are concerned. --- Desired behavior after this commit is merged: Memory errors are avoided. --- Details on the fix: Optimize account code updates by batching SQL writes and only updating codes that have actually changed, avoiding unnecessary ORM recompute cascades and improving performance for large datasets. --- opw-4951670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
After a successful self-order payment, customers are now taken directly to the next step instead of seeing an extra confirmation screen. This streamlines the checkout experience and reduces unnecessary waiting or taps.
Original PR description
Before: = - A payment confirmation screen used to appear after a successful transaction. After: = - The flow now skips the payment confirmation screen and moves directly to the next Screen. Task: 4836123 Forward-Port-Of: odoo/odoo#213481
Resolved issues and error corrections
When products valued by lot are revalued, the lot's standard price is now updated to match the value increase or decrease. This keeps inventory valuation and lot-level product costs aligned, improving accuracy in stock and accounting reports.
Original PR description
### Steps to reproduce 1. Create a product with valuation by lot in AVCO 2. Purchase 10 quantity and validate the transfer 3. In the valuation report, group by product and revaluate the product ### Before this commit The lot is correctly revaluated, but its standard price is not updated ### After this commit The standard price is updated to reflect the value increase/decrease. opw-4890361 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Large product images shared through the purchase portal are now shown at an appropriate size instead of overwhelming the page. This keeps purchase documents readable and professional for external viewers opening shared links.
Original PR description
Issue ----- Images on the purchase portal are displayed in their original size instead, making it a visual mess. Steps to reproduce ----- - Create a product with a large image - Create a purchase for…
Issue ----- Images on the purchase portal are displayed in their original size instead, making it a visual mess. Steps to reproduce ----- - Create a product with a large image - Create a purchase for the product - Click the cog wheel > Share - Open the link in a new tab (with no active session, eg private window) --> The image is way too big Cause ----- Images are now converted to Webp: https://github.com/odoo/odoo/commit/1a978183001e0503104285f4bd5bed983beb0efb The problem is that Webp images cannot be resized through the Python backend: https://github.com/odoo/odoo/blob/0c6622294b7117ec5eb1cbf8a9270636b2dd807f/odoo/tools/image.py#L81-L83 However, the product model has multiple sizes for the image: https://github.com/odoo/odoo/blob/3ddf2bcdf16b5b43db4c4abe2cdbc4384cf683cc/addons/product/models/product_product.py#L91-L94 What we can do is load the smallest possible image and then use styling to limit the display size. The 48px comes from the hardcoded values in https://github.com/odoo/odoo/blob/0c6622294b7117ec5eb1cbf8a9270636b2dd807f/addons/purchase/controllers/portal.py#L99 This fix will no longer be needed when (if) Webp images get resized in backend. Comparison ----- Left is before, right is after fix.  Image used -----  ----- Ticket: opw-4625113
Employees can now place or update lunch orders when the total is within their wallet balance plus the configured overdraft allowance. This prevents valid orders from being blocked and keeps the Lunch dashboard and product screens consistent with company settings.
Original PR description
**Current Behavior:** The overdraft amount (`lunch_minimum_threshold`) is configured in Lunch settings is ignored when employees create or update lunch orders. As a result, even if the total order…
**Current Behavior:** The overdraft amount (`lunch_minimum_threshold`) is configured in Lunch settings is ignored when employees create or update lunch orders. As a result, even if the total order amount is within the allowed overdraft limit, the system blocks the action. **Steps to Reproduce:** 1) Install the Lunch module. 2) Set an overdraft amount in the Lunch settings. 3) Ensure an employee's wallet balance is less than a desired order total. 4) Attempt to create a lunch order or increase product quantity such that the total is more than the wallet balance but within the wallet + overdraft amount. **Issue:** - In both the product view (`_compute_display_add_button`) and the dashboard (`canAdd` logic), the wallet balance is calculated using `get_wallet_balance(include_config=False)`. - This call excludes the overdraft threshold, causing incorrect warnings and hiding of the `Add to Cart` or `+` buttons. **Solution:** - Remove the explicit `include_config=False` argument so the default True is used, ensuring the overdraft is included. - In the dashboard logic, enhance _make_info() to return a wallet_with_config key using get_wallet_balance(include_config=True) and update the canAdd check to use this value. opw-4782564
The Spanish Modelo 390 VAT report now avoids counting vendor refunds twice and includes all relevant manual adjustment lines in line 64 totals. This helps businesses submit more accurate VAT declarations and reduces the risk of reporting discrepancies.
Original PR description
This commit addresses two issues in the Mod 390 report:
---
1. Vendor refunds were being reported twice:
- Once correctly via the tax grid.
- And again incorrectly through the cross-formula on lines 639 and 62, which are meant for special manual adjustments only.
➤ Fix: Lines 639 and 62 are now treated as external values, making them
editable and excluding them from automatic computation.
2. Line 64 was missing part of the total:
- It did not include balances from lines 661 and 62, resulting in an incomplete total.
➤ Fix: Updated the computation of line 64 to sum all relevant manual lines.
---
task-4972473Manufacturing orders with very small work center costs could fail during validation because totals were rounded inconsistently. The fix rounds values before adding them, preventing accounting imbalance errors and showing the correct cost in the manufacturing overview.
Original PR description
Steps to reproduce:
- Create two work centers with different expense accounts:
- First: hourly cost of 0.01
- Second: hourly cost of 0.01
- Create an MO for a product with real-time valuation and 2 work orders
(one per work center).
- Each work order has an expected duration of 30:02
- Attempt to click on "Produce All" button.
This leads to an unbalanced move error.
This fix rounds the values before summing them to prevent rounding issues
and unbalanced moves. It also corrects the displayed value in the
Manufacturing Order overview.
opw-4631409Invoice emails generated after online payments are now sent using the proper salesperson/system context instead of the customer portal user's context. This prevents confusing emails that appear to be sent from and to the administrator, improving customer communication accuracy.
Original PR description
**Steps to reproduce**: 1. Enable automatic invoicing `Settings -> Sales -> Invoicing -> Automatic Invoice` 2. Configure a payment provider like `Stripe` (not demo) 3. Open the website in an…
**Steps to reproduce**: 1. Enable automatic invoicing `Settings -> Sales -> Invoicing -> Automatic Invoice` 2. Configure a payment provider like `Stripe` (not demo) 3. Open the website in an incognito browser and log in as a portal user 4. Add a product to cart and checkout with the portal user's delivery address 5. Complete payment using test card credentials 6. Navigate to the created invoice in Sales **Observed behavior:** The invoice email is sent to both the portal user (customer) and the system admin, appearing as if the email is sent "from admin to admin" instead of from the assigned salesperson. **Root cause:** When automatic invoicing is enabled and a portal user completes a website purchase, the `_send_invoice()` method uses `self.env['account.move.send']` which runs in the portal user context. The portal user is selected as author, and the email template uses `partner_to` so it is also selected as partner. While sending mail, this triggers the `mail_notify_author` context. Additionally, due to the portal user not having proper email sending permissions, the system adds admin as fallback. As a result, emails are sent by admin, and because of `mail_notify_author`, mail is also sent to admin. **Solution:** Changed `self.env['account.move.send']` to `tx.env['account.move.send']` in the `_send_invoice()` method. Since `tx` is created with `SUPERUSER_ID` context, this ensures the invoice sending runs with proper system permissions and uses the transaction's context instead of the portal user's context. This ensures emails are authored by the correct salesperson, not the portal user. opw-4760568
This update refreshes the spreadsheet engine and fixes several everyday editing issues. Users should see more reliable row sizing, formula recalculation, cell editing, pasting, validation lists, and pivot behavior in Odoo spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0f3b11a81 [REL] 18.0.38 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0f3b11a81 [REL] 18.0.38 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5e9706fa6 [FIX] header_sizes_ui: preserve row sizes on insert and move ops [Task: 4885579](https://www.odoo.com/odoo/2328/tasks/4885579) https://github.com/odoo/o-spreadsheet/commit/e1c4e6255 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710) https://github.com/odoo/o-spreadsheet/commit/17cd60e8f [FIX] GridComposer: Recompute composer position if we change edited cell [Task: 4879186](https://www.odoo.com/odoo/2328/tasks/4879186) https://github.com/odoo/o-spreadsheet/commit/ec8a90d51 [FIX] auto_complete: remove toggle button for data validation [Task: 4854464](https://www.odoo.com/odoo/2328/tasks/4854464) https://github.com/odoo/o-spreadsheet/commit/c693c6ee0 [FIX] Composer: Remove formatting when pasting external content [Task: 4910559](https://www.odoo.com/odoo/2328/tasks/4910559) https://github.com/odoo/o-spreadsheet/commit/ba683b429 [FIX] spreadsheet_pivot: empty row when number added to char field [Task: 4878778](https://www.odoo.com/odoo/2328/tasks/4878778) https://github.com/odoo/o-spreadsheet/commit/41c774ac1 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369) 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: Ronak Mukeshbhai Bharadiya <rmbh@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>
Employees can no longer create time off requests through a shortcut when the time off type requires an approved allocation. This closes a loophole so the same business rules apply consistently across all request creation paths.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves. - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208214
This fixes a rounding issue that could create unnecessary stock valuation entries when purchasing in foreign currency with higher product price precision. Vendor bills that should be editable can now be reset to draft without being blocked by those erroneous entries.
Original PR description
**Current behavior:** Modifying the "Product Price" global precision and purchasing some product in a foreign currency sometimes leads to problematic SVL creation, which will make a posted vendor…
**Current behavior:** Modifying the "Product Price" global precision and purchasing some product in a foreign currency sometimes leads to problematic SVL creation, which will make a posted vendor bill unable to be reset to draft when it logically should be permitted. **Expected behavior:** No SVL, can reset vendor bill. **Steps to reproduce:** 1. Activate a foreign currency, set the "Product Price" precision from 2 -> 3, make an exchange rate to the foreign currency with a rate: `0.2710027100271003` 2. Make a product with avg costing, real time valuation, with a standard price = `0.875` 3. Create a purchase order in the foreign currency for the avco product: * `price_unit: 0.237` * `product_qty: 5500` 4. Confirm -> receive -> create invoice -> post * Can't reset the bill to draft * There is an additional SVL that shouldn't have been generated **Cause of the issue:** There will be a negligible rounding diff between the price units of the journal item and SVL created on reception. When the invoice is posted, this will captured and when multiplied by a large enough invoicing qty, will create a large enough value to trigger creation of pdiff SVL. **Fix:** Zero out the price unit difference if it is functionally equivalent to zero when rounded according to the maximally precise "precision record" involved in the sequence, that is: A) The bill currency B) The SVL currency C) The "Product Price" global precision value opw-4873246
This fix prevents Odoo from creating duplicate stock quantity records when moving entire packages while other packaged products are reserved. It helps keep inventory counts accurate and avoids confusion during package transfers and delivery preparation.
Original PR description
### Steps to reproduce: - In the settings enable "packages" and Multi-Step Routes - Create a 3 storable products: P1, P2, P3 - Put on hand quantities for each of them: - 1 x P1 in PACK001 in stock -…
### Steps to reproduce:
- In the settings enable "packages" and Multi-Step Routes
- Create a 3 storable products: P1, P2, P3
- Put on hand quantities for each of them:
- 1 x P1 in PACK001 in stock
- 1 x P2 in PACK001 in stock
- 1 x P3 in PACK002 in stock
- Create and confirm a delivery with 3 moves:
- 1 x P1
- 1 x P2
- 1 x P3
- Go to Inventory > Configuration > Warehouse Management > Operation type
- Modify internal transfers to "Move entire packages"
- Create and confirm and internal transfer for PACK001 from stock to the sublocation stock/shelf1
- Mark the package as done and validate the transfer
#### > You end up with 2 quants for PACK002 in stock
### Cause of the issue:
When validating the internal transfer for PACK001, we launch an `_action_done` on the moves lines of the internal transfer. In particular, during this action done, a `quant_cache` will be set for to fetch and use the quants for P1 and P2:
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_move_line.py#L679-L681 https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_quant.py#L933-L949 This cache is correctly use in order to update our move lines during the `synchronize_quant` that will follow:
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_move_line.py#L684-L692 However, they are not in the `_free_reservation` because this call will reassign the move line and then `_check_entire_pack` for the entire picking:
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_move.py#L1980-L1981 In particular, it will update the reservation for the move related to P3. But, since the `quant_cache` is taken from the context and did not change it can not find the quants related to P3 and a new quant will be created in addition to the already existing one: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/stock/models/stock_quant.py#L1055 https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/stock/models/stock_quant.py#L1101
opw-4922032
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prDuplicating a pivot table in Spreadsheet now correctly carries over applicable global filters. This prevents copied pivot reports from showing unfiltered or misleading data, saving users from manually reapplying filters.
Original PR description
Steps to reproduce: - insert a pivot in a spreadsheet - create a global filter matching one of the pivot fields - use the global filter to restrict the values - duplicate the pivot => the filter is not applied on the duplicated pivot Task:4966634 opw-4950469 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
Fixed an issue where certain combo products in Point of Sale skipped the needed product configuration step. The configurator now opens when required and avoids asking cashiers to choose variant options that were already selected, reducing ordering mistakes and checkout friction.
Original PR description
When a combo contained a product that had variant with type 'no_variant' and 'always', if you added the product to the cart the product configuration popup would not open. Also, in the combo you can…
When a combo contained a product that had variant with type 'no_variant' and 'always', if you added the product to the cart the product configuration popup would not open. Also, in the combo you can only select product_product and not product_template, so the product configuration popup should not propose the variant linked to the 'always' type, as you already selected a product template in the combo configuration popup. Steps to reproduce: ------------------- * Create a product attribute PA1 with type 'no_variant' and 2 values V1 and V2 * Create a product attribute PA2 with type 'always' and 2 values V3 and V4 * Create a product template PT1 with PA1 and PA2 * Create a combo choice PC1 with the 2 variants of PT1 * Create a combo product CP1 with PC1 * Open PoS and add CP1 to the cart * The combo configurator popup opens, click on the version with V2 > Observation: The product configurator popup does not open > Second fix: The product configurator allows you to select the variant linked to the 'always' type, which is not correct as you already selected it through the combo configurator popup Why the fix: ------------ The first fix just make sure that the product configuration popup opens when it is necessary. The second fix filters the variants proposed in the product configuration popup to only show the variants that are not linked to the 'always' type. But this only happens when we do it from the combo configuration popup. opw-4719258
Updating account codes in the chart of accounts now avoids unnecessary bulk data loading that could exhaust server memory. This makes account code changes more reliable for companies with large volumes of accounting entries.
Original PR description
Description ----------- Writing a new code for an account in the mappings of a COA will retrigger expensive recomputations for all moves linked to the accounts via its lines. This can lead to quick…
Description ----------- Writing a new code for an account in the mappings of a COA will retrigger expensive recomputations for all moves linked to the accounts via its lines. This can lead to quick exhaustion of the memory budget for the processing of the request (2 GiB by default). The commit odoo/odoo@8c5bfff4667ac2f8ec349278dda77d980242aae1 was supposed to address this issue by disabling the fields prefetcher when either 'code' or 'account_type' are being written to, but there is a logical oversight in the condition. ```py prefetch_fields=any(field in vals for field in ['code', 'account_type']) ``` Means "activate prefetch if it exists a field 'code' or 'account_type' in the vals". This is the opposite of what was intended, if the fields *do not* exist, only then we prefetch. So we can just negate the condition. Benchmark --------- For a database where updating the code of an account in the COA mapping, which impacts ~370K account.move and their related ~1.56M account.move.line, saving the new code memory took: | | Before | After | |-------------------|----------|---------| | Peak Memory Usage | 2.78 GiB | 879 MiB | Reference --------- opw-4951670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Video calls in chat windows now display the call area at a more useful size when at least one participant has video enabled. This makes video streams easier to see, improving the calling experience for users who rely on visual communication.
Original PR description
Before this commit, when in a discuss call in a chat window with at least 1 video, clicking on no main card had all cards sized for avatar, including the video stream. This is a problem because the video stream are very small, barely visible, which is unfortunate because when there are video streams they are usually the most important thing that call participants want to see. This commit fixes by adding a new CSS rule in chat window with call: when user in a call with at least 1 video stream, the size of call view matches the size of a 16:9 video stream when focused. Part of task-4967123 Before / After <img width="381" height="634" alt="Screenshot 2025-07-28 at 17 57 37" src="https://github.com/user-attachments/assets/878bae9f-01e5-4f81-9d61-b43180d4f809" /> <img width="385" height="637" alt="Screenshot 2025-07-28 at 17 57 17" src="https://github.com/user-attachments/assets/0261d716-e52c-4a72-ad6a-007c8d01a362" />
The Philippine BIR 2307 spreadsheet export now includes partner ZIP codes and uses the correct tax description for the payment nature. It also formats company and individual taxpayer names more accurately, helping businesses produce clearer and more compliant tax reports.
Original PR description
The BIR 2307 XLS export was missing the `ZIP_code` and incorrectly showing the `nature` of payment from the invoice line instead of the tax description. In this commit: --- - Added a new column `zip_code` to show the ZIP from the `partner`. - Changed the `nature` column to use the `tax-description` instead of `product-name`. - Displaying `companyName` only when the commercial partner is a company. - Displaying `surName`, `firstName`, and `middleName` only when the commercial partner is an individual. task-4880921 Enterprise-PR: odoo/enterprise#91120 Forward-Port-Of: odoo/odoo#220606 Forward-Port-Of: odoo/odoo#214940
Users working across multiple companies can now send signature requests from templates they created in any company they are allowed to use. The fix prevents an access error caused by using the creator's default company instead of the current company for template emails.
Original PR description
Problem: In a multi-company environment, users are unable to send templates in non-default companies despite them creating the template. A traceback gets thrown because the template is using the…
Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.
Purpose: The user should be able to send templates they created in any allowed companies.
Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access
[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown
```
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
value = env.cache.get(record, self)
File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'
During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.
Records: BE Company CoA (id=2)
User: Marc Demo (id=6)
This restriction is due to the following rules:
- company rule employee
Note: this might be a multi-company issue.
Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/>
```
opw-4706828
Forward-Port-Of: odoo/enterprise#85402Employees can no longer create time off requests without a valid approved allocation by using the Time Off type shortcut. This keeps absence requests consistent with company policy and prevents accidental bypasses of allocation controls.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236
This update corrects how Mexican electronic invoicing documents are returned so the download process receives the expected format. It helps prevent failures when users request invoice legal documents, including cases involving multiple file types.
Original PR description
`_get_invoice_legal_documents` should, and is expected to, return a dict. however, if called with `filetype = all`, it returns, because of `_get_invoice_legal_documents_all`, a list which breaks calling code as they expect a dict not a list, and this part of the code is not used anywhere nor tested. - remove the line causing `_get_invoice_legal_documents` to return a list. - make `download_invoice_documents_filetype` work with multiple filetypes related PR: https://github.com/odoo/odoo/pull/220170 no-task
Field service sales orders with Anglo-Saxon accounting now correctly show zero-priced products as ready to invoice. This lets businesses create invoices for no-charge products or services linked to field service tasks instead of being blocked by an incorrect status.
Original PR description
Before this commit: When Anglo-Saxon accounting is enabled and a product with sale price of zero is added to SO through field service, the invoice_status show 'Nothing to Invoice'. After this commit: With Anglo-Saxon accounting enabled, adding product with a zero sale price to an SO through field service will display the invoice_status as 'To Invoice' instead of 'Nothing to Invoice'. task-3957962 Forward-Port-Of: odoo/enterprise#70132
French companies using a fiscal year that does not end on 31 December can now generate annual tax reports with the correct dates. This prevents incorrect warnings during tax closing and better supports legitimate French reporting periods such as a June year-end.
Original PR description
In France, some of our users choose a different fiscal period, like finishing on 30 June. If they try to generate their tax report annually, they will have a warning when doing their tax closing, and the dates will be wrong. But it should be possible (form 3517-S-SD mention CA 12) A setting exists for it but was not made generic to avoid providing useless settings for everybody. So add France to these countries. opw-4968327
Users can now change the dates of recurring planning shifts without encountering a missing record error. The Sale Planning app now verifies that shifted records still exist before continuing, preventing crashes and making recurring shift edits safer.
Original PR description
Version: 17.0 Steps to reproduce: - Install sale_planning - Create a recurrence shift. - Change the date of second shift which is created by recurrence. - Give the edit value as All shifts. - save record, missing error occured. Issue: When a user changes the date of a shift created by recurrence, the system crash with the message, "Record does not exist or has been deleted." Cause: There was an issue between "Planning" and "Sale Planning". When a user moves a shift, "Planning" removes the old shift from the system except the first one, But 'sale planning' was still trying to work with that removed shift. Fix: Now, after 'Planning' does its work, 'Sale Planning' checks again to see that shifts are still there. It only works with shifts that actually exist. So crash no longer happens. Users can now safely change the date of recurring shifts without errors. task-4859892 Forward-Port-Of: odoo/enterprise#88234
Bank statement imports started from the accounting dashboard now continue through all batches instead of stopping after the first portion of the file. The import page also shows the correct file name, making the process clearer for users handling large bank statement files.
Original PR description
**PROBLEM** When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the…
**PROBLEM** When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the behavior of the import done from the reconcilation page. Also, on the import page, the file name is incorrect (it's always `bank_statement_import.csv`) **STEP TO REPRODUCE** file to reproduce the issue : [MP 2280260435_movements_-2025-04-01-191536.xlsx](https://github.com/user-attachments/files/20880784/MP.2280260435_movements_-2025-04-01-191536.xlsx) 1. install the accounting module 2. goes on the dashboard, click on the 3-dot button on the kanban for the bank account, and import a file. 3. make sure the file will be imported in multiple batches (reduced the batch size to 200) and click on import. 4. notice how only the first batch was imported. **CAUSE** In python, The `AccountBankStmtImportCSV` class override the execute_import method of the `base_import.import`. In this override, we add a entry in the `messages` list. (see `enterprise/account_bank_statement_import_csv/models/account_bank_statement_import_csv.py`) In JS, all entry in messages are treated as errors, and the import is interrupted. (see `odoo/addons/base_import/static/src/import_model.js`) https://github.com/odoo/odoo/blob/389b355e7ec761fe8dc2908ac5aec540b0345c48/addons/base_import/static/src/import_model.js#L410-L417 The message entry added in the python was used in the past to automatically open the reconcillation page with the statement lines added. This feature was removed, but not the message. **FIX** - Remove the problematic message entry. - Fix the name of the file in the import action. opw-4823808