Monday, March 24, 2025
17 changes · saas-17.4
Resolved issues and error corrections
Fixed an issue in the website editor where button styling could be removed after opening and closing the link editing tool. This keeps buttons visually intact while editing pages, reducing confusion and accidental layout changes.
Original PR description
**Problem**: When destroying the link tool, if an `<a>` tag with `btn` classes has no `href`, it gets unwrapped. This visually removes the button, leaving only its text content. While this has no effect on normal links, it makes buttons appear to disappear when closing the tool. **Solution**: Prevent unwrapping buttons (`<a>` with `btn` classes) when the link tool is destroyed. **Steps to Reproduce**: 1. Open the website editor. 2. Add "Blocks" > "Features" > "Items". 3. Click inside a button to show the link tool. 4. Click outside the editable area. 5. Click inside the button again. - **Issue**: The button disappears, leaving only text. **opw-4574401** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a recruitment offer is sent for signature, the resulting signing request is now linked back to the original offer. This helps HR teams keep offer records complete and easier to track after both parties sign.
Original PR description
Steps to reproduce: 1. In recruitment app, generate an offer for an applicant. 2. Send the offer by email and sign it by both parties. Bug: The generated sign request is not linked to the offer using the reference_doc field. Fix: Link the offer to the sign request upon creation in the submit endpoint. task-4607475
Approval requests now show eligible request owners from all currently selected companies, even when no approval category has been chosen. This prevents users from seeing an empty owner list and helps them complete approval requests without unnecessary blockers.
Original PR description
Fixed the `Request Owner` field to list all users in the selected companies. The previous domain was based on `company_id`, which was computed from the selected `category_id`. However, if no category was selected (`category_id` was null), no `request_owner_id` was listed. The new fix computes all selected companies from `self.env`. task-4637199
This update corrects an internal test so it only runs when the dropshipping feature it depends on is available. It helps avoid misleading test failures and keeps quality checks focused on valid scenarios.
Original PR description
The test requires `stock_dropshipping` to be installed to have sense, but the condition set to avoid the test running without it was insufficient. Since it was only checking on a string in the database, it wouldn't raise a ValueError, but just not find any matching record, thus running the test even without the module installed.
Miscellaneous changes
Currently, a traceback is occurs when the user tries to remove the date value, while creating a Bill. To reproduce this issue: 1) Install account 2) Create a Bills record from vendors 3) Change the `Auto-Post` value to `at date` from `other info` 4) Now remove the `Accounting Date` Error:- ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` When the user removed the date value, a compute method will be triggered in which a comparison is done
Original PR description
Currently, a traceback is occurs when the user tries to remove the date value, while creating a Bill. To reproduce this issue: 1) Install account 2) Create a Bills record from vendors 3) Change the `Auto-Post` value to `at date` from `other info` 4) Now remove the `Accounting Date` Error:- ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` When the user removed the date value, a compute method will be triggered in which a comparison is done between the record date and the today value. However, the user removed the record's date value, which leads to the above traceback from the below line https://github.com/odoo/odoo/blob/2adabe7321f26e67eea9853460948cbd4ac10a4a/addons/account/models/account_move.py#L626-L627 sentry-6402545255 Forward-Port-Of: odoo/odoo#202057
Description of the issue/feature this PR addresses: Odoo Individual Contributor License Agreement Current behavior before PR: Odoo Individual Contributor License Agreement Desired behavior after PR is merged: Odoo Individual Contributor License Agreement --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202642
Original PR description
Description of the issue/feature this PR addresses: Odoo Individual Contributor License Agreement Current behavior before PR: Odoo Individual Contributor License Agreement Desired behavior after PR is merged: Odoo Individual Contributor License Agreement --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202642
Steps to reproduce the bug: - Install accounting - Go to reporting, Invoice analysis - Select Product Quantity, Untaxed Total and Average Price in Measures Traceback is thrown that the field prive_subtotal is used twice for the combination Untaxed total and Average price. Another traceback is thrown that quantity field is used twice for the combination Product Quantity and Average price. This is because the override of the read_group in the account.account_invoice_report in case of ave
Original PR description
Steps to reproduce the bug: - Install accounting - Go to reporting, Invoice analysis - Select Product Quantity, Untaxed Total and Average Price in Measures Traceback is thrown that the field…
Steps to reproduce the bug: - Install accounting - Go to reporting, Invoice analysis - Select Product Quantity, Untaxed Total and Average Price in Measures Traceback is thrown that the field prive_subtotal is used twice for the combination Untaxed total and Average price. Another traceback is thrown that quantity field is used twice for the combination Product Quantity and Average price. This is because the override of the read_group in the account.account_invoice_report in case of average price in the fields it add fields of quantity and price_subtotal. By default the fields are added with the default agg, so they are as <field>:sum. And the Untaxed Total and Poruct Quantity by default add both quantity and prive_subtotal as well. So they are duplicate columns to show on pivot and view crashes. The override of the read_group was introduced in d741788306. opw-4638089 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#201155
#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity. Issue 2 ----- When using the "Update BOM" button for a confirmed manufacturing order, components
Original PR description
#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the…
#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity. Issue 2 ----- When using the "Update BOM" button for a confirmed manufacturing order, components used to produce a specific variant of a kit product are not added to the MO consumables. Commit breakdown ----- - Commit 1 (handle component quantities - first ticket): - use the correct exploded value for the quantity (divided by the original quantity as the ratio isn't done for the top-level bom) - update test_update_mo_from_bom_with_kit with correct values - extend test_update_mo_from_bom_with_kit for when the kit components' quantities are updated - Commit 2 (handle components for specific variants - second ticket): - adapt the filtering of bom lines to keep them based on the kit's attribute instead of the end product one's - add a new test_update_mo_from_bom_with_kit_vraiants - Commit 3 (handle confusion of multi-variants/UoM kits - additional issues): - change bom_lines_by_id to a defaultdict to consolidate quantity of components - update test_update_mo_from_bom_with_kit to test for multiple UoMs - update test_update_mo_from_bom_with_kit_variants to test for multiple variants ----- Tickets: opw-4473337 opw-4480039 Forward-Port-Of: odoo/odoo#196227
An error occurs when a simplified invoice contains an OSS with a non-Spanish partner, and the Bizkaia tax agency is selected. This causes the B4_2000027 error to be returned by Bizkaia. Steps to reproduce: - Install l10n_es_edi_tbai and l10n_eu_oss - Set the Tax Agency to Bizkaia - Create a simplified invoice - Set fiscal position to OSS B2C - Poland - Use a Polish partner - Add a product - Validate the invoice - Attempt to send to Bizkaia The error raised is: `B4_
Original PR description
An error occurs when a simplified invoice contains an OSS with a non-Spanish partner, and the Bizkaia tax agency is selected. This causes the B4_2000027 error to be returned by Bizkaia. Steps to…
An error occurs when a simplified invoice contains an OSS with a non-Spanish partner, and the Bizkaia tax agency is selected. This causes the B4_2000027 error to be returned by Bizkaia.
Steps to reproduce:
- Install l10n_es_edi_tbai and l10n_eu_oss
- Set the Tax Agency to Bizkaia
- Create a simplified invoice
- Set fiscal position to OSS B2C - Poland
- Use a Polish partner
- Add a product
- Validate the invoice
- Attempt to send to Bizkaia
The error raised is:
`B4_1000002: Todos los registros incluidos en la petición son incorrectos.
B4_2000027: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando la factura es completa y, además, existe destinatario extranjero (tipo IDOtro o que sea NIF que empiece por N) o la Clave de IVA es 02.`
After investigation, it appears this issue occurs only with Bizkaia. This fix ensures that `DesgloseFactura` is used instead of `DesgloseTipoOperacion` for this specific case.
Reference:
https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII_Descripcion_ServicioWeb_v1.1_en_gb.pdf?utm_source=chatgpt.com
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4464223)
opw-4464223
Forward-Port-Of: odoo/odoo#202905
Forward-Port-Of: odoo/odoo#200391When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this warning, we check if the partner has any related `employee_ids`. However, if the user does not have the `"Employees / Officer: Manage all employees"` access rights, they cannot check the `employee_ids`, leading to an access error when opening the vendor bill. Steps to Reproduce: 1. Create a vend
Original PR description
When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this…
When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this warning, we check if the partner has any related `employee_ids`. However, if the user does not have the `"Employees / Officer: Manage all employees"` access rights, they cannot check the `employee_ids`, leading to an access error when opening the vendor bill. Steps to Reproduce: 1. Create a vendor bill where the vendor is set to your own company. 2. Try to access the vendor bill with a user who does not have `"Employees / Officer: Manage all employees"` access rights. Issue: An error occurs because the user lacks permission to check the related `employee_ids` for the vendor. Refer to this [video](https://drive.google.com/file/d/1hIUTbNYhZxT4aOtNq8XE1z7uy7K_HJM1/view) for clearer steps. opw-4539017 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202033
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#202636
Original PR description
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#202636
Steps to reproduce: - Create two products, both in AVCO cost method - Create another product with a standard_price of 100 - Create a bom to produce an AVCO product and has the other one as byproduct. Also use the last one as component - Create a MO for 1 unit of that bom and produce it - Unbuild the MO Issue: The valuation layer created for the byproduct in the unbuild will use the value of the main product of the MO instead of its counterpart. opw-4623337 --- I confirm I have si
Original PR description
Steps to reproduce: - Create two products, both in AVCO cost method - Create another product with a standard_price of 100 - Create a bom to produce an AVCO product and has the other one as byproduct. Also use the last one as component - Create a MO for 1 unit of that bom and produce it - Unbuild the MO Issue: The valuation layer created for the byproduct in the unbuild will use the value of the main product of the MO instead of its counterpart. opw-4623337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201627
Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users. Now, the error will be shown on the ui only if we are in debug mode TASK-ID: 4600145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202875
Original PR description
Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users. Now, the error will be shown on the ui only if we are in debug mode TASK-ID: 4600145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202875
It's due to other module creating leaves on the 40h/week calendar. Since it's set on the workorder. During the productivity loss creation the duration could cost for 0 minutes if it's during the leave of a workcenter opw-moc 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#197995
Original PR description
It's due to other module creating leaves on the 40h/week calendar. Since it's set on the workorder. During the productivity loss creation the duration could cost for 0 minutes if it's during the leave of a workcenter opw-moc 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#197995
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - Spanish partner - Amount > 3005.06 (mod347 threshold) - Type for mod 347: Regular operation - Create and confirm a jounral entry with: - Payable account, debit 4000 - Receivable account, credit 4000 - Type for mod 347: Regular operation - Check Mod 347 Tax Report Issue: 'Total number of persons and entities' shows 0 This occurs because some lines of mod 347 report need to be grouped by
Original PR description
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - Spanish partner - Amount > 3005.06 (mod347 threshold) - Type for mod 347: Regular operation - Create and confirm a jounral entry with: - Payable account, debit 4000 - Receivable account, credit 4000 - Type for mod 347: Regular operation - Check Mod 347 Tax Report Issue: 'Total number of persons and entities' shows 0 This occurs because some lines of mod 347 report need to be grouped by partner, only keeping the partners whose balance for the line is above 3005.06€, so we first get all the partners that match the domain but don't reach the threshold. We exclude these partners with a 'NOT IN' clause. However, when the partner is not set, a NULL values is retrieved causing the clause to be evaluated NULL instead of False and the total count will be 0 opw-4544950 Forward-Port-Of: odoo/enterprise#81687
Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop. This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries. Benchmarks: |num res.partner | time before | no. queries| time after | no. queries after| |-----|-----|----|------|----| | 80 | ~18s | 80 | ~0.4s | 1| Forward-Port-Of: odoo/enterprise#81438
Original PR description
Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop. This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries. Benchmarks: |num res.partner | time before | no. queries| time after | no. queries after| |-----|-----|----|------|----| | 80 | ~18s | 80 | ~0.4s | 1| Forward-Port-Of: odoo/enterprise#81438
Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - P
Original PR description
Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 20 (correct). OPW: 4599614 Forward-Port-Of: odoo/enterprise#81888 Forward-Port-Of: odoo/enterprise#80214