Monday, April 14, 2025
27 changes
5 changes
Enhancements to existing features
Performance test coverage for the Documents app has been consolidated into the Documents module. This helps teams monitor efficiency in one place and catch slowdowns earlier without changing user-facing behavior.
Original PR description
Centralizing performance tests for documents in documents. To come: Other tests for bridges features implemented in documents should also be tested in documents. Task-4548076
This update removes unnecessary request details from the session information loaded by IoT and Studio. It helps keep startup data lighter and better aligned with the main Odoo platform change, with no expected change to normal user workflows.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/205725
This update adjusts Odoo Studio’s test setup so it works with a new caching service for actions and views. The change supports more reliable validation of Studio behavior as caching is introduced, with no direct impact on day-to-day users.
Miscellaneous changes
Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one. The issue was introduced in Odoo 18.0 with commit [1]. - Create a product.template, add it some variants and for each variants have a different price (eg through the variant extra price). - That product should be a service one - Create an appointment, enable "Up-front payment" in the "Options" tab and add it one of the variant product. Note that it's a vari
Original PR description
Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one. The issue was introduced in Odoo 18.0 with commit [1]. - Create…
Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one. The issue was introduced in Odoo 18.0 with commit [1]. - Create a product.template, add it some variants and for each variants have a different price (eg through the variant extra price). - That product should be a service one - Create an appointment, enable "Up-front payment" in the "Options" tab and add it one of the variant product. Note that it's a variant product that you set there, not a template. - You should see next to the variant product you just selected a price per booking being displayed. It is correctly showing the product variant price and not the product template price. - Repeat those 2 steps with the other product variants: create a new appointment and select another variant, you can see the price is correct in the form view. - Now, go to the website appointment page `/appointment`, you will see that all those appointments will show the same price which is the one from the first variant. - The same price error will appear once you click on an appointment (you should land on something like `/appointment/4?`) - Note that if you go further in the appointment booking and land on the shop cart page, the price will be correct there, using the correct variant one. (You'll need to assign a user on the appointment in the backend to be able to book a slot) Side note: Commit [1] seems to have broken commit [2] too. [1]: https://github.com/odoo/enterprise/commit/26fb20ace27b7b522a1105c221e4a52cf224a508#diff-5ffc6d13c61e692b22e4c2fec9218cf96c0c86201aeac951ef36e53e7baa7620R4-R9 [2]: https://github.com/odoo/enterprise/commit/5068b0ae7d38cb03318ad1e97124021121fd66cb opw-4678998 Forward-Port-Of: odoo/enterprise#83104
20 changes
Enhancements to existing features
This update adds tests that clarify how contact addresses should synchronize between companies, parents, children, and siblings. It helps reduce the risk of future changes accidentally altering address behavior for customers and contacts.
Original PR description
Improve coverage of address sync fields. Purpose is to make cases clearer and cover a bit more current code branches * first contact: updates void parent, not parent with address; * child sync / siblings sync: limited to one level; * invoice / delivery / other adresses are never synchronized; * no upstream update of addresses; Task-4708358 Part of Task-4377720
Description ----------- When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or inherited through parent articles ( stopping at the first desynchronized article). In databases where articles have numerous associated members, the `_get_article_member_permissions` method suffers from severe performance issues. It retrieves *all* articles and their associated members, collects all paren
Original PR description
Description ----------- When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or…
Description ----------- When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or inherited through parent articles ( stopping at the first desynchronized article). In databases where articles have numerous associated members, the `_get_article_member_permissions` method suffers from severe performance issues. It retrieves *all* articles and their associated members, collects all parent articles in the hierarchy, and only then applies grouping and filtering based on the `id` of `self`. This process includes a `LEFT OUTER JOIN` on related tables to fetch specific `fields` passed as arguments, resulting in an O(n^2) complexity on large tables such as `res.partner` and `knowledge.article.member` (the latter being a Many2many relationship that typically contains a high volume of rows). This patch improves performance by shifting the grouping and filtering logic to the start of the process, effectively injecting all preconditions at the base of the recursion. This reduces the hierarchy of articles and memberships to explore. Additionally, the computation of inherited permissions—sourced from the "closest" ancestor article—is now handled at the SQL level instead of Python. This eliminates unnecessary rows in the process, avoiding unnecessary work in the business logic afterward. Benchmark --------- On a client's database with around 600 articles, 5k partners and 15k knowledge.article.member in total, for a specific article which has a total of 1.7k members (direct and inherited): | Request | Before | After | Speed-up | |--------------------------------|---------|-------|-----------| | `_get_article_permission_data` | 4.7+min | 150ms | **1880x** | Reference --------- opw-4603551 Forward-Port-Of: odoo/enterprise#81264
Custom guided tours can now better control where help tooltips appear, making instructions clearer when default placement is awkward. The tour flow also handles dropdown loading states more reliably, reducing the chance that a guided process gets stuck.
Original PR description
Before this commit, changing the tooltip position of a custom tour was impossible. So, if the tooltip was missplaced, like when pointing at the button to return to the home. Now, the tooltip position of the step can be changed in the custom tour view and the default value is "bottom". TASK-ID: 4623449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Pricelist reports using the DIN 5008 document layout now receive the right report context, preventing them from being mislabeled as invoices. This helps sales users produce customer-facing pricelist documents with the correct title.
Original PR description
Steps to reproduce: 1) Install sales, l10n_din5008_sale and enable pricelist from settings 2) Change the document layout to `DIN 5008` from settings 3) Open the pricelist from sales and print the pricelist report with a product Issue:- Pricelist report gets printed with "Invoice" title Cause:- This is because in the `DIN 5008` report, we print the invoice title by default if there are no `docs` or `object` values. https://github.com/odoo/odoo/blob/c80db0e6ff96ed4d8a00f01817694a4edcca6c64/addons/l10n_din5008/report/din5008_report.xml#L93 Solution: Provide the docs value to the pricelist report values. opw-4680444
Manufacturing order users with the right project permissions can now see the Project field without needing Inventory Administrator access. This fixes an access mismatch so project and manufacturing teams can link work to projects more easily.
Original PR description
Reproduce: Give user Inventory User rights > MO > Miscellaneous > Project Solution: Removed the group for Inventory Admin from the field project_id in mrp_production view Description of the issue/feature this PR addresses: The project field in an MO is only visible if you are administrator of Inventory. If you have admin rights to MRP and/or projects you can't see the field. Current behavior before PR: In MO under Miscellaneous page we can not see project field without Inventory admin group Desired behavior after PR is merged: In MO under Miscellaneous page user can see project field with group project admin only. opw-4708084
This fixes a crash that could occur when the Sales Timesheets app is used without the subscription timesheet app installed. Businesses can continue creating or processing related invoices without hitting an unexpected error from a missing parameter.
Original PR description
From this #205029 If sale_timesheet is installed standalone sale_subscription_timesheet is not installed, the get_range_dates method will crash as the parameter is not defined. TypeError: AccountMove._get_range_dates() takes 1 positional argument but 2 were given See https://github.com/odoo/odoo/pull/205816 OPW-4723777 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 a display issue where a Kanban record dropdown menu could overlap the Kanban header during scrolling. This keeps actions and headers visually separated, making Kanban boards easier to use and read.
Original PR description
Before this commit: When scrolling, the Kanban record drop-down menu overlap Kanban header. After this commit: The Kanban record drop-down menu should not overlap with the Kanban header while scrolling. Task-4686607
This fix ensures the Sales Timesheets app works correctly on its own when the subscription timesheet app is not installed. It prevents an internal error during invoice date range handling, helping users avoid interruptions in billing workflows.
Original PR description
### Currently From this https://github.com/odoo/odoo/pull/205029 if `sale_timesheet` is work standalone and not installed `sale_subscription_timesheet` then the func `_get_range_dates` still need to work aswell ### Potential Error: TypeError: AccountMove._get_range_dates() takes 1 positional argument but 2 were given ### Expected: This PR will fix this --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When multiple taxes are applied to a sales order or invoice, the combined tax total is now labeled generically as "Taxes" instead of using the name of the first tax group. This avoids misleading tax summaries for customers and accounting users.
Original PR description
If you have multiple taxes on a sale order or invoice, then the total tax amount is displayed with the name of the first tax group. Rename it to show a generic "Taxes" group. This was done before for sale orders but was lost in d5da2b62263f85fbce0f2548085c066cbbf10371. opw-4673667
This fixes a crash that could occur when the timesheet sales app is used without the subscription timesheet app installed. Businesses can continue creating or processing related invoices without an unexpected error interrupting the workflow.
Original PR description
If sale_timesheet is installed standalone sale_subscription_timesheet is not installed, the get_range_dates method will crash as the parameter is not defined. TypeError: AccountMove._get_range_dates() takes 1 positional argument but 2 were given See https://github.com/odoo/odoo/pull/205816 OPW-4723777
Code cleanup and technical improvements
This update reworks how Odoo’s automated web tours find and act on page elements during testing. It should make website and web interface tests more predictable, reducing random failures and improving confidence in future releases.
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
Miscellaneous changes
There has been a recent change to the specs where they changed the endpoint to send B2C invoices: `uploadb2c`. So now, - if an invoice is made to a commercial partner that is of type company, we keep sending it to the old endpoint (no change); - if it is made to a non-company customer, then we send to the new endpoint. task-4645442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205720 Forward-Port-Of: odoo/odoo#203743
Original PR description
There has been a recent change to the specs where they changed the endpoint to send B2C invoices: `uploadb2c`. So now, - if an invoice is made to a commercial partner that is of type company, we keep sending it to the old endpoint (no change); - if it is made to a non-company customer, then we send to the new endpoint. task-4645442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205720 Forward-Port-Of: odoo/odoo#203743
Steps to reproduce the issue: - Enter Website edit mode. - Click on the "Theme" tab. - Pick a black color for the website background (4th color button). - Click on a link in the website navbar to make the link popover appear. - Bug: The popover arrow is black. Bug introduced by this commit [1], where popover colors were updated to match the website's theme. It was fixed since version 17.0 by this commit [2]. But during the forward-port to saas-17.4, the fix no longer works because of t
Original PR description
Steps to reproduce the issue: - Enter Website edit mode. - Click on the "Theme" tab. - Pick a black color for the website background (4th color button). - Click on a link in the website navbar to make the link popover appear. - Bug: The popover arrow is black. Bug introduced by this commit [1], where popover colors were updated to match the website's theme. It was fixed since version 17.0 by this commit [2]. But during the forward-port to saas-17.4, the fix no longer works because of the upgrade to Bootstrap 5.3 done in this commit [3]. In this commit, we adapt the CSS code introduced by commit [2], so that it fixes the arrow color in the same way as it does in 17.0. [1]: https://github.com/odoo/odoo/commit/0d96be06faf8aad1a92183bd2b6371253980c7e6 [2]: https://github.com/odoo/odoo/commit/bf59d2aba488931ba89512d5d6489ecb48ef2aa3 [3]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935 task-4422810 Forward-Port-Of: odoo/odoo#205317
Problem --------- As of Jan 01, 2025 the Romanian tax authority will accept blank tax IDs for recipient individuals of an e-invoice in the form "0000000000000". However, in Odoo a blank tax id number for an individual contact is denoted as '/'. Objective --------- When creating the Invoice XML, if the res.partner has an empty Tax ID, or a tax ID that is "/" or <2 characters, replace the value by 0000000000000 in the produced XML. task-4610149 --- I confirm I have signed the CLA a
Original PR description
Problem --------- As of Jan 01, 2025 the Romanian tax authority will accept blank tax IDs for recipient individuals of an e-invoice in the form "0000000000000". However, in Odoo a blank tax id number for an individual contact is denoted as '/'. Objective --------- When creating the Invoice XML, if the res.partner has an empty Tax ID, or a tax ID that is "/" or <2 characters, replace the value by 0000000000000 in the produced XML. task-4610149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205565 Forward-Port-Of: odoo/odoo#200977
Before this PR, Setting the on-hand quantity from the product form would correctly set the product's quantity but also reset the inventory quantity to 0. While this behavior is correct,it caused a line decoration warning to appear in the Inventory Adjustment tree view. Steps to Reproduce =================== - Create a storable, non-tracked product. - Update its quantity by clicking the "Update Quantity" button, ensuring multi-location is disabled. - Go to Inventory Adjustment and
Original PR description
Before this PR, Setting the on-hand quantity from the product form would correctly set the product's quantity but also reset the inventory quantity to 0. While this behavior is correct,it caused a…
Before this PR, Setting the on-hand quantity from the product form would correctly set the product's quantity but also reset the inventory quantity to 0. While this behavior is correct,it caused a line decoration warning to appear in the Inventory Adjustment tree view. Steps to Reproduce =================== - Create a storable, non-tracked product. - Update its quantity by clicking the "Update Quantity" button, ensuring multi-location is disabled. - Go to Inventory Adjustment and locate the newly created product. The inventory quantity is correctly set to 0, but it is highlighted with a warning. Issue ====== Although the inventory quantity is correctly set to 0, the `inventory quantity set` field is not reverted, causing the line decoration warning to appear. This commit resolves the issue by using an existing method that clears the inventory quantity and sets the `inventory quantity set` field to false. task: [4579053](https://www.odoo.com/odoo/my-tasks/4579053) Forward-Port-Of: odoo/odoo#199598
Description of the issue/feature this PR addresses: If we try to reload the template, an error is raised. So, we will raise the error if the change has some meaning Current behavior before PR: an Error is raised when updating a German plan Desired behavior after PR is merged: no Error is raised @alialfie --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205480
Original PR description
Description of the issue/feature this PR addresses: If we try to reload the template, an error is raised. So, we will raise the error if the change has some meaning Current behavior before PR: an Error is raised when updating a German plan Desired behavior after PR is merged: no Error is raised @alialfie --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205480
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Vendors / Bills" - Upload a PDF having an embedded factur-x XML with no tax or a tax that doesn't exist in the database **Issue:** The bill generated from the embedded XML has the default purchase tax set on it. **Cause:** At the beginning of the process, an empty account move is created and then it is populated with the data retrieved from the XML. At the creation of the account move, the default tax is set. When the
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Vendors / Bills" - Upload a PDF having an embedded factur-x XML with no tax or a tax that doesn't exist in the database **Issue:** The bill generated from the embedded XML has the default purchase tax set on it. **Cause:** At the beginning of the process, an empty account move is created and then it is populated with the data retrieved from the XML. At the creation of the account move, the default tax is set. When the taxes are populated, if there is no tax or if it doesn't exist, "tax_ids" fields of the account move line is set to the empty list (i.e. []). However, if "tax_ids" has already a value (e.g. the default tax), setting it to `[]` will not remove it, unlike `False`. opw-4600822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205646 Forward-Port-Of: odoo/odoo#205498
The demo product 'Drawer' was initially configured to be tracked by quantity, but a lot was incorrectly created, and the stock quant was subsequently created for the 'Drawer' with lot. Steps to reproduce =============== - Install the 'stock' module with demo data. - Navigate to Inventory > Products > Products and search for 'Drawer'. - Observe that 'Drawer' is set to track by quantity (Tracking field). - Check Inventory > Operations > Physical Inventory and locate the stock quant
Original PR description
The demo product 'Drawer' was initially configured to be tracked by quantity, but a lot was incorrectly created, and the stock quant was subsequently created for the 'Drawer' with lot. Steps to reproduce =============== - Install the 'stock' module with demo data. - Navigate to Inventory > Products > Products and search for 'Drawer'. - Observe that 'Drawer' is set to track by quantity (Tracking field). - Check Inventory > Operations > Physical Inventory and locate the stock quant for 'Drawer'. - Note that a lot exists and is linked to the product 'Drawer', despite the quantity tracking setting. This commit modifies the demo data to enable lot tracking for the product, aligning its configuration with the existing lot and stock quant data for consistency. Forward-Port-Of: odoo/odoo#204803
Before this commit, it was possible to have a `videoError` caused by (or happening during) the destruction of the video component. This error should not be retained as playing the video is no longer useful when the component is destroyed. Forward-Port-Of: odoo/odoo#204518 Forward-Port-Of: odoo/odoo#204470
Original PR description
Before this commit, it was possible to have a `videoError` caused by (or happening during) the destruction of the video component. This error should not be retained as playing the video is no longer useful when the component is destroyed. Forward-Port-Of: odoo/odoo#204518 Forward-Port-Of: odoo/odoo#204470
### Steps to reproduce: - In the settings enable by products. - Create two products FP and SN where SN is tracked by serial numbers - Create and confirm an MO for FP where SN is a by product - Open the shopfloor > Register By-Product > generate serial numbers > input SN0012 > Generate > Save #### > your input was not taken into account, not lot was created. ### Cause of the issue: Clicking on `Register By-Product` and generate serial numbers will open the `stock.generate_serial_d
Original PR description
### Steps to reproduce: - In the settings enable by products. - Create two products FP and SN where SN is tracked by serial numbers - Create and confirm an MO for FP where SN is a by product - Open…
### Steps to reproduce: - In the settings enable by products. - Create two products FP and SN where SN is tracked by serial numbers - Create and confirm an MO for FP where SN is a by product - Open the shopfloor > Register By-Product > generate serial numbers > input SN0012 > Generate > Save #### > your input was not taken into account, not lot was created. ### Cause of the issue: Clicking on `Register By-Product` and generate serial numbers will open the `stock.generate_serial_dialog`. Clicking on Generate will then call the `_onGenerate` method and an rpc call of the `action_generate_lot_line_vals` will be made: https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/lots_dialog.xml#L12 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/generate_serial.js#L34 However, if you triggered these actions from the shopfloor, you never provided a `default_picking_type_id` in the context so that the lot will never be created by any mean: https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L919-L927 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L945-L948 opw-4544734 Forward-Port-Of: odoo/enterprise#82355
Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp. This f
Original PR description
Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However,…
Commits fc49984a and 2644a63b introduced changes to:
- Prevent rejections for invoices older than 72 hours (error 301).
- Use the correct partner/branch timezone when generating the CFDI.
However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp.
This fix ensures that the same emission timestamp (stored in `l10n_mx_edi_post_time`) is reused for subsequent stamping attempts, producing an identical XML and preventing duplicates on the SAT.
Steps to reproduce the original issue:
1. Create and confirm an invoice.
2. Stamp the invoice.
3. Manually set the EDI status to “to_send”: ```python record.edi_document_ids.write({"state": "to_send"}) ```
4. Stamp again without persisting the emission timestamp => a new CFDI is generated.
Expected result after the fix:
- The system reuses the same emission timestamp (l10n_mx_edi_post_time) for each attempt, preventing duplicate CFDIs on the SAT.
According to the [SAT
documentation](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf)
the attribute `Fecha` must be the expedition date.
Forward-Port-Of: odoo/enterprise#83234
Forward-Port-Of: odoo/enterprise#81882