Daily updates from Odoo
Thursday, July 3, 2025
19 changes · 18.0
Enhancements to existing features
This update improves the performance of replenishment planning by processing reorder point calculations in batches. It also corrects related purchasing logic so purchase requests are counted accurately and unnecessary database-wide searches are avoided.
Original PR description
The method `orderpoint._compute_qty_order_computed` was batched in commit 17a2de9 then reverted in commit a58b995 because of a bug introduced when purchase_stock is installed. It should still be beneficial performance-wise to batch the calls to `orderpoint._quantity_in_progress` so this commit reintroduces the batching. The part that led to the issue was the override of `_quantity_in_progress` in the purchase_stock module. In this commit we fix the `_quantity_in_progress` method. Thanks to that, the test introduced in 606dc71 is passing even with the batched version of `_compute_qty_to_order_computed`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Aged Partner reports now retrieve invoice dates from the existing accounting line data instead of scanning the related invoice table. This reduces unnecessary database work and can significantly speed up large Aged Receivable or Payable reports, with observed savings of around 10 minutes on very large datasets.
Original PR description
The Aged Partner reports query in `_aged_partner_report_custom_engine_common` is joining on the `account_move` table solely to get the `invoice_date` column. As this `invoice_date` is aggregated in `ARRAY_AGG(DISTINCT invoice_date)` and there's already a denormalized field `invoice_date` on `account_move_line` that is a related stored field, we can drop the join and use this field instead. This saves us the need to scan the account.move table when running the reports query. In a database with 37M amls, 10M account.move (and a really bad correlation for account_move_line.move_id), this saves us around 10 minutes for the Aged Receivable report's query.
The budget generation wizard now lets users choose whether new budgets are for revenue, expenses, or both. This helps companies create budgets that better match their financial planning structure, while keeping the change limited to the wizard workflow.
Original PR description
### Description of the Issue/Feature The budget split wizard currently does not allow the user to specify the type of budget being created, which limits its usability for companies that distinguish…
### Description of the Issue/Feature The budget split wizard currently does not allow the user to specify the type of budget being created, which limits its usability for companies that distinguish between revenue and expense budgeting. ### Current Behavior The wizard generates budgets without considering the nature (type) of the budget. ### Desired Behavior after PR A new field `budget_type` is introduced as a required selection in the wizard, with the options: - Revenue - Expense - Both The selected type is propagated to the resulting `budget.analytic` records. ### Changes Made - Added a `budget_type` selection field to `budget.split.wizard` - Extended `action_budget_split` to store this value on created budgets - Updated the form view to include the new field ### How to Test 1. Open the *Generate Budget* wizard. 2. Select a date range, a period, and one or more analytic plans. 3. Select a budget type. 4. Click "Split". 5. Confirm that created budgets reflect the selected type. ### Notes This change is backward-compatible and isolated to the wizard. It does not modify any core models or affect other modules.
Document requests can now be linked to the correct company when created. This improves accuracy for organizations using multiple companies by ensuring requested documents are assigned to the right business entity by default.
Original PR description
[IMP] documents: Add `company_id` field to the document request wizard This pull request introduces the following improvements to the `documents` module: - Added a `company_id` field to the `documents.request_wizard` model, allowing users to specify the company associated with a document request. - The `company_id` field is set to default to the current company if not provided. - Updated the form view to support multi-company functionality for the `company_id` field. - Incorporated the `company_id` in the document creation process within the `request_document` method, ensuring that documents are associated with the correct company. Related Issues: N/A Task: N/A Technical Review: - The change ensures that documents can now be correctly associated with the company where the request originates, improving the handling of multi-company environments. - No backward compatibility issues are expected as `company_id` is optional and defaults to the current company.
Resolved issues and error corrections
This fix ensures the refund process waits for the previous refund step to finish when Spanish TicketBAI POS and Peruvian POS e-invoicing are both installed. As a result, users see the required refund reason popup reliably, helping avoid incomplete refund handling.
Original PR description
When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 Forward-Port-Of: odoo/odoo#216379
This fix prevents manufacturing orders from being created with duplicate names when automated replenishment and multi-step manufacturing are used together. It helps avoid scheduler failures that could interrupt replenishment and production planning.
Original PR description
__Issue:__ Condition used for MOs triggered under the `pbm_sam` manufacturing flow only checks the start of the group name, not the whole name, which could fail in case triggered by reordering rules where the origin might be a compound string such as: "OP/00001,WH/MO/00001" __Steps to reproduce:__ 1.) Install sales; inventory; manufacturing 2.) Enable multi-step routes 3.) Unarchive MTO 4.) Set warehouse manufacture steps to: Pick components, manufacture, then store products (3 steps) (manufacture_steps == 'pbm_sam') 5.) Create product A-bom (enable manufacture and mto routes) 6.) Create product B (enable manufacture) 7.) Add Product A as bom for product B 8.) Add a reordering rule (manufacture) for product B 9.) run SA Procurement: run scheduler Error: duplicate key value violates unique constraint opw-4866263 bug found: [[#c50cb9d]](https://github.com/odoo/odoo/commit/c50cb9d552f352bde4e3b8d92e8509476f194830)
This fix prevents Backspace from breaking the structure of columns and table cells in the HTML editor. It keeps editing hints correctly positioned and preserves proper empty content areas, making page editing more reliable for users.
Original PR description
**Current behavior before PR:** - Pressing backspace while a column is selected could cause the column hint to be incorrectly positioned. This happened because the base container inside the column was removed during the backspace action. - When a table row or column was not fully selected, pressing Backspace would replace the contents of the selected `td` elements with a `br` tag. **Desired behavior after PR is merged:** - If the base container is removed during backspace, it is now reinserted to ensure the column hint remains correctly positioned. - Pressing Backspace in a partially selected row or column now replaces the content of the selected `td` elements with a base container instead of a `br` tag. task:4783325
Creating records that use mail aliases no longer fails when a company has no email domain configured in a multi-company setup. This prevents installation or setup errors in apps such as Field Service, Project, or CRM when company domain settings differ.
Original PR description
Before this commit, creating a mail alias mixin (typically a project) with an unspecified domain in a multi-company setup could lead to access errors "We could not create alias Inactive Alias because domain <client domain> belongs to company <company 1> while the owner document belongs to company <company 2>" Steps to reproduce: 1. Start with a clean DB 2. install an app that uses mail (e.g. CRM or Project) 3. Create a second company 4. Set a domain for the 1st company (the one created by default) 5. Erase the domain of the second company (the one created at step 3) 6. Try to install the Field Service app After this commit, not specifying the domain gets correctly interpreted and a default None value is used. opw-4051655 Forward-Port-Of: odoo/odoo#173999
Payments made with an existing third-party check now use the currency of that check by default. This prevents incorrect currency conversions and blocks combining checks in different currencies, reducing payment errors for businesses using Latin American check workflows.
Original PR description
**Steps to reproduce:** - Install accountant, l10n_ar and l10n_latam_check - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Make sure that USD currency has a rate different than…
**Steps to reproduce:**
- Install accountant, l10n_ar and l10n_latam_check
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)
- Make sure that USD currency has a rate different than 1
- Create a journal:
* Journal Name: Checks journal
* Type: Cash
- Save the journal
=> a Cash Account should be automatically created
- In "Incoming Payments" tab of the journal, set:
* "New Third Party Checks" with the Cash Account
* "Existing Third Party Checks" with the Cash Account
- In "Outgoing Payments" tab of the journal, set:
* "Existing Third Party Checks" with the Cash Account
- Create an invoice:
* Customer: [an Argentinian customer] (e.g. ADHOC SA)
* Currency: ARS
* Invoice Lines:
- Quantity: 1
- Price: 150000.00
- Taxes: VAT 21%
- Confirm the invoice
- Pay the invoice:
* Journal: [the created Checks journal]
* Currency: ARS
* Checks: [add a line with the amount of the invoice]
- Create a bill:
* Vendor: [an Argentinian customer] (e.g. ADHOC SA)
* Currency: USD
* Invoice Lines:
- Quantity: 1
- Price: 500.00
- Taxes: VAT 21%
- Pay the bill:
* Journal: [the created Checks journal]
* Payment Method: Existing Third Party Checks
* Checks: [add a line and select the check used to pay the invoice]
**Issue:**
When the check (from the invoice) is selected to pay the bill, the original amount (in ARS) is used but the currency stays in USD, which is not correct.
If the currency is changed to ARS, the currency rate is applied on the amount that is already the amount in ARS, which generates a higher incorrect amount.
**Solution:**
Use the currency set on the existing check by default.
Also prevent adding several checks with different currencies.
opw-4741607
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPortal chatter now distinguishes between the logged-in user and the portal partner represented by an access token. This avoids confusing labels, messages, and mentions that previously made two different people appear as the same user, while still allowing token-based actions where permitted.
Original PR description
Since [1], discuss considers both the logged in and the portal partner as "self". However, even if the token grants access to act as the portal partner, it doesn't mean that both users are the same. Visually, it's confusing that every hint in the UI assimilate the current user to the portal partner (messages, mentions, ...). This commit fixes that by separating the concept of portal partner and "self". The user providing the portal token can access portal partner actions (editing/deleting message) but is considered a different user. [1]: https://github.com/odoo/odoo/pull/211204 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
Work entries now use the employee's company when one is set, instead of defaulting to the currently selected company. This prevents entries for employees in another company from being recorded under the wrong company in multi-company setups.
Original PR description
BUG - when you select 2 companies in the multi company widget (A & B, default : A) and I create a work entry for an employee of company B. The work entry will be related to company A. Expected behavior: - The default company should be the employee one if has a one FIX - check if the employee has a company add it to the create vals_list Task: 4781100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209011
Mass converting duplicate CRM leads with deduplication enabled no longer crashes when one of the selected leads has already been merged. This makes bulk lead conversion more reliable for sales teams and avoids interrupting their workflow with missing-record errors.
Original PR description
Currently, when mass converting leads that contain duplicates, you are met with an error. ### Steps to reproduce * Install `crm` * Activate leads in CRM settings * Pick a lead in the list of leads…
Currently, when mass converting leads that contain duplicates, you are met with an error. ### Steps to reproduce * Install `crm` * Activate leads in CRM settings * Pick a lead in the list of leads and duplicate it * Select both the original and the duplicate leads → Action → Convert to Opportunity * In the wizard, ensure that "Apply deduplication" is enabled You will be met with the following error message: ``` Missing Record Record does not exist or has been deleted. (Record: crm.lead(...), User: ...) ``` ### Cause When mass converting leads with "Apply deduplication" enabled, the system processes each selected lead and attempts to deduplicate it by merging it with matching leads and deleting the duplicates. However, if one of the selected leads is also identified as a duplicate and gets deleted earlier in the loop, the process fails when it later tries to access the already-deleted lead. Although logic to skip already processed leads exists, there's a small mistake: it compares the lead record (`lead`) to a set of IDs (`merged_lead_ids`), which always fails. opw-4893775 Forward-Port-Of: odoo/odoo#216527
Marketing automation test runs can again include tracked link clicks, allowing teams to validate more realistic campaign flows before launch. The update also prevents overlapping tests for the same campaign and recipient details, reducing confusing or incorrect test results while still allowing separate tests to run in parallel.
Original PR description
Previously, marketing campaign testing (through debug) could cause an issue where tracked links could cause a traceback if a marketing activity was edited after a test was attempted. To work around…
Previously, marketing campaign testing (through debug) could cause an issue where tracked links could cause a traceback if a marketing activity was edited after a test was attempted. To work around this, #13665 deactivated link tracking in marketing campaign tests. However, this meant that flows including click actions could no longer be tested. As this issue has been resolved in odoo/odoo#48845, this commit reverts https://github.com/odoo/enterprise/pull/13665 to once again permit marketing automation testing. -- Additional changes are needed to fix other issues: Tests using one's own coordinates are prone to breaking due to newer mailing traces attaching themselves to the oldest marketing trace. This commit makes it so that marketing campaign tests for the same marketing campaign and coordinates cannot run concurrently, by cancelling older test campaigns upon starting a new one. Different tests can still run concurrently on distinct partners/leads/ etc. Additionally: - Running tests are now visible on campaigns in the "New" state; - Activities don't mark themselves as needing sync unless their campaign is in the "Running" state. task-4557855 Forward-Port-Of: odoo/enterprise#88274 Forward-Port-Of: odoo/enterprise#78793
This fix ensures WinBooks imports create all journals even when their original codes are longer than the allowed length and start with the same characters. A clear temporary code is assigned to duplicates so businesses can complete imports reliably and adjust codes afterward if needed.
Original PR description
**Steps to reproduce:** - Install accountant, l10n_be and account_winbooks_import - Switch to a Belgian company (e.g. BE Company CoA) - Go to "Accounting / Configuration / Settings" - Click on…
**Steps to reproduce:** - Install accountant, l10n_be and account_winbooks_import - Switch to a Belgian company (e.g. BE Company CoA) - Go to "Accounting / Configuration / Settings" - Click on "Import (for full history)" in "Accounting Import" section - Click on "Import WBK" in "Winbooks" section - Upload a Winbooks file containing several journals having their "DBKID" value longer than 5 characters with the 5 first characters being identical (e.g. "SALES001", "SALES002",...) - Import **Issue:** Some journals are not imported. **Cause:** The code of a journal is limited to 5 characters and is unique per company. When a code is longer than 5 characters, only the 5 first characters are kept. In this case, several journals to create have the same 5 first characters. Therefore, only one of them is created. **Solution:** If the code of a journal to create has the same first 5 characters of a journal that has already been created (and the same last 5 characters), we use a generic code formatted with a starting "*" char followed by a number that is incremented. This format allows to quickly find it if we want to change its value once imported. This solution is limited to 9999 journals that have a code that can starts with the same 5 characters than another journal, but it should be more than enough. opw-4812655
New bills created from GSTR-2B matching now keep their JSON attachments properly linked. This prevents bookkeepers from seeing a 404 error when opening the supporting attachment, improving reliability in the Indian GST workflow.
Original PR description
**Before this PR:** - The GSTR-2B JSON was attached to the message but not linked to the newly created bills (`res_id` was not set). - As a result, when a Bookkeeper user created a new GSTR-2B bill and tried to open the attachment, it raised a 404 error: `"The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again."` **After this PR:** - The issue is resolved. - During GSTR-2B matching, unattached message attachments are now properly linked to the newly created bills by updating their res_model and res_id fields. Task ID : 4831758 Forward-Port-Of: odoo/enterprise#89250 Forward-Port-Of: odoo/enterprise#86785
This fix ensures the refund reason popup appears when Spanish TicketBAI POS and Peruvian POS e-invoicing are both installed. It prevents staff from missing required refund information, helping keep refund workflows compliant and complete.
Original PR description
When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 Forward-Port-Of: odoo/enterprise#88813
Payroll work entry exports now respect the companies available to the user, instead of only using the current company. Belgian Group S exports also require the company Group S code to be set before exporting, helping avoid incomplete or rejected payroll files.
Original PR description
* = l10n_be_hr_payroll_group_s before this commit only the current company was taken into account when exporting work entries now another company can be selected if multiple companies are active for the current user In addition to that this commit also add a check for the company's group s code to enforce the user to set it before exporting work entries task-4213675
The Work Entries Analysis report now only shows payroll data for the companies selected by the user. This prevents users in multi-company environments from seeing unrelated company data in the report, making analysis clearer and more accurate.
Original PR description
BUG - In multi-companies env the report shows all the companies no matter what is selected in the company selection menu Expected behavior: - Only selected company data is presented in the view FIX - add a domain to the report action to show only allowed companies data Task: 4781100 Forward-Port-Of: odoo/enterprise#85690
Bookkeeper users can now open the required follow-up screens when a customer is missing email or address details. This prevents access errors during automatic follow-ups or manual reminders, helping teams continue overdue payment follow-up work without interruption.
Original PR description
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic…
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic Follow-ups For the Automatic Follow-ups action, the user wasn't able to access the 'missing information view' For the Followup Button (manual_reminder), that's in the follow-up report view, the user wasn't able to access either the 'manual_reminder view' or the 'missing information view' ## Steps in runbot 17.0: - Create an invoice with a past due date and a new customer (leave email empty) - Go in Accounting > Customers > Follow-up Reports - Select the In need of action report for your new customer - In Actions, click on Process Automatic Follow-ups - An AccessError should be displayed ## To test the manual reminder: - Create the invoice as before and go to Follow-up Reports - Open the report linked to your new customer - Click on the Follow up Button - An AccessError should be displayed opw-4848745 Forward-Port-Of: odoo/enterprise#88168