Tuesday, April 14, 2026
20 changes · saas-19.2
New functionality added to Odoo
This update allows users to efficiently update the partner associated with multiple invoices or move records directly from a list view. Previously, changing this information required individual updates for each record. This enhancement improves workflow efficiency for bulk partner adjustments.
Original PR description
[IMP] account: mass edit partner on move list This commit adds the feature to mass edit the partner field on moves when the user is in a move list view. A widget is created to display either the Many2one `partner_id` field (in case we're editing multiple moves) or the `invoice_partner_display_name` (in case we're displaying without editing) task-5986025 Forward-Port-Of: odoo/odoo#254340
Enhancements to existing features
This update enhances the budget report to automatically include tracking of asset accounts. Previously, budget reports only covered expense accounts. Now, when tracking expenses or both expenses and budgets, the system will include asset accounts like current, non-current, and fixed assets, providing a more complete financial picture.
Original PR description
Expand the scope of budget tracking to include asset accounts. Modified the account filtering logic so that when a budget type is set to "Expenses" or "Both", the query includes 'asset_current', 'asset_non_current', and 'asset_fixed' account types. task-5994048 Forward-Port-Of: odoo/enterprise#112239 Forward-Port-Of: odoo/enterprise#109496
Resolved issues and error corrections
This update resolves an error preventing customers from successfully connecting or refreshing their Shopee accounts through the `sale_shopee` module. The fix corrects a technical issue within the module's code that was causing an error during the authorization process. New automated tests have been added to ensure this functionality remains stable.
Original PR description
Currently, customers report errors when connecting or refreshing a Shopee account through the `sale_shopee` module. **Steps to reproduce:** - Install and configure the `sale_shopee` module - Attempt…
This update enhances the processing of point-of-sale transactions within the German tax reporting module (l10n_de_pos_cert). Specifically, it ensures accurate tracking of transaction times and automatically clears active transactions at the end of each session to align with tax reporting requirements. This improves data reliability and simplifies compliance.
Original PR description
In this commit: ------------------ - The transactions were shown to be processed within 0-1 seconds as we were used to call start and finish transaction calls on validation so in the case of retails it won't give actual data of start and end time so we need to improve this and called now for `start transaction` when first orderline added to a new order, calling `cancelled` if the order is deleted or all the orderlines are removed manually, and `finished` on validation of the order. - Also will delete all active transactions on the fiskaly at the time of closing of session so that no active order remains (if cleared cache) As a lot things are already handled in v19 Handled https://github.com/odoo/enterprise/pull/99216 pr's remaining updates here. Forward-Port-Of: odoo/enterprise#113669 Forward-Port-Of: odoo/enterprise#107530
Currently, customers report errors when connecting or refreshing a Shopee account through the `sale_shopee` module. **Steps to reproduce:** - Install and configure the `sale_shopee` module - Attempt to connect a Shopee account via the onboarding flow - Complete the authorization process **Observed behavior:** An error is raised during the authorization callback, preventing the Shopee account from being connected or refreshed. **Root cause:** In `onboarding.py`, the `shopee_return_from_authorization` controller incorrectly uses `utils.with_context(authorization_code=code)`. Since `utils` is an imported Python module, calling `with_context` on it attempts to set the context on the module itself rather than on a model instance, which raises an error. **Solution:** Move the `with_context` call from the `utils` module to the `temp_shop` record, which is the appropriate model instance that needs the context. Additionally, this commit adds regression tests for the controller to prevent future regressions, as this functionality was previously untested. opw-6092524 Forward-Port-Of: odoo/enterprise#113081
This update resolves an issue where certain holiday types were incorrectly being treated as working time, leading to inaccurate time tracking. The change allows administrators to exclude holidays that should be considered as fully paid time off, ensuring accurate payroll and reporting. This improves the reliability of our time management features.
Original PR description
…orking time We can't take leaves considered as working time. We should be able to task-6089849
This update corrects a bug where ticket submissions with emails using different capitalization would incorrectly create a new partner. Now, the system correctly identifies and uses the submitted email address to create the ticket, preventing the creation of unintended partner records. This ensures consistent and accurate ticket assignment.
Original PR description
**Steps to reproduce** - Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123"). - Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com"…
**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.
Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.
Behavior after this fix: no partner is created.
**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)
Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.
opw-5914064
Forward-Port-Of: odoo/enterprise#109393This update fixes an issue where subscription discounts were incorrectly calculated due to how the base plan price was being used. The fix ensures discounts are accurately applied by dividing the base plan price by its unit (e.g., month or year), resulting in more precise pricing on the website. This improves the accuracy of subscription offers for customers.
Original PR description
### Steps to reproduce: - Install Subscriptions and eCommerce modules - Create 3 recurring plans (3 months, 6 months, Yearly) - Create a service subscription product with the created recurring plans - Check the product's page on website - Notice each pricing has a discount tag and with incorrect numbers ### Cause: When calculating the discount we normally use the fixed price of the base plan as the price to compare with. This sometimes introduce inconsistencies if the base plan is not just one unit from the period (>1 week/month/year) ### Fix: We divide the base_plan_price by the unit of the plan so we can get the price of just one plan unit. opw-6048278 Forward-Port-Of: odoo/enterprise#112305
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in Documents, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and simplifies reconciliation.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#100846 Forward-Port-Of: odoo/enterprise#78380
This update resolves a problem where portal users were receiving an error message when viewing invoice payment information. The issue stemmed from the system attempting to access payment details, which portal users didn't have permission to view. This change prevents the error and ensures accurate payment information is displayed in the portal.
Original PR description
Steps to produce: --- - Install `Accounting` module. - Create a new customer. - From the gear icon, `grant Portal Access` to the customer. - Create an invoice for this customer. - Log in using the…
Steps to produce: --- - Install `Accounting` module. - Create a new customer. - From the gear icon, `grant Portal Access` to the customer. - Create an invoice for this customer. - Log in using the customer’s portal account. - Navigate to `My Invoices`. Issue: --- ``` You are not allowed to access 'Payment' (account.payment) records. ``` Root cause: --- - After the [commit], the system attempts to compute the next payment values for display in the portal. - This computation is triggered via `_get_invoice_portal_extra_values()`, which calls `_get_invoice_next_payment_values()`. - During this process, the method iterates over `reconciled_payment_ids`. Accessing this field triggers its computation (`_compute_reconciled_payment_ids`), which depends on `matched_payment_ids`. - Both `reconciled_payment_ids` and `matched_payment_ids` are relational fields pointing to `account.payment` records. - Since portal users do not have read access to the `account.payment` model, attempting to access these fields results in an AccessError [commit]: https://github.com/odoo/odoo/commit/b76836680540eb7687021f48b3532e8a495e771a opw-6042693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where sale orders were incorrectly using the analytic account from Company A instead of Company B when multiple companies were involved. The change ensures that the correct company's project and analytic distribution account are used, resolving potential discrepancies in financial reporting across different company environments. This improves the accuracy of sales data analysis.
Original PR description
Pre-requisites: ------------------------------------------ 1. Install `sale_project` and `project_account_budget` modules 2. Have two companies configured in the system 3. Enable Timesheets from the…
Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
* Timesheets
* Billable
Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
* Type: Service
* Create on Order: Task
* No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order
Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B
Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context
Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.
opw-5864452
Forward-Port-Of: odoo/odoo#257776This update resolves a memory issue that caused server crashes when calculating cumulated balances for large accounting systems. By optimizing the query to process only relevant move lines, the fix dramatically reduces memory usage and processing time, leading to a more stable and efficient system. This improves performance for users with extensive transaction data.
Original PR description
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move…
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move lines, the result returned by fetchall() hits the memory limit and the server crashes. We propose to encapsulate the original query to only return the result for the account move lines present in self. Benchmarks --------------- The following benchmarks were generated with a customization of the account.move.line list view to display the cumulated_balance field. Memory usage during the self.env.cr.execute and the dictionary population: | Operation | Before the fix | After the fix | |---------------|----------------|---------------| | populate dict | 1.5 GB | 17.1 MB | | execute query | 430 MB | 8.3 MB | 100 000 lines were displayed at the same time to get a significant size. So the number of records in self is more than 7 000 000 without the fix and 100 000 with the fix. Time spent in the _compute_cumulated_balance method: | No of AML | Before the fix | After the fix | |-----------|----------------|---------------| | 7 000 000 | 10.4 s | 6.8 s | opw-6053720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258207 Forward-Port-Of: odoo/odoo#255780
This update resolves an issue where COGS calculations were incorrect when products were partially delivered or held as consignment stock. The fix ensures that consigned quantities are properly accounted for, leading to accurate COGS values for sales invoices. This improves inventory valuation and reporting.
Original PR description
This forward port merges [PR1](https://github.com/odoo/odoo/pull/255043) (original PR from this forward port) and forward port of [PR2](https://github.com/odoo/odoo/pull/256383) which is improving…
This forward port merges [PR1](https://github.com/odoo/odoo/pull/255043) (original PR from this forward port) and forward port of [PR2](https://github.com/odoo/odoo/pull/256383) which is improving the fix. **Problems:** 1) cogs don't adapt to partially consigned quantities 2) no cogs at all if product partially delivered **Steps to reproduce:** Problem 1) - enable 'consignment' setting - create a tracked product with perpetual category (bug happens with avco, fifo and standard price category) - set a cost of 10 - add a quantity of 1 without owner and a quantity of 1 with an owner - create a sale order for a quantity of 2 of your produce - confirm, validate picking and confirm invoice -> the cogs is 20 -> the cogs should be 10 because the consigned quantity shouldn't be taken into account in the cogs Problem 2) - set the warehouse as 2 steps delivery - create a tracked product avco perpetual - set a cost of 10$ and a positive quantity - create and confirm a SO for 1 quantity - validate only the first picking - create and confirm the invoice -> there is no cogs lines in the invoice -> there should be cogs line for a cost of 10$ **Cause of the issue:** Problem 1) to compute the cogs line amount, we multiply the quantity of the line (2 in our case) by the price unit of the cogs. To compute the price_unit we call _get_cogs_value() https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move.py#L122-L123 In our case the price_unit (so the 'price per cogs unit') should be 5 because we have 2 units, 1 valued at 10 and 1 valued at 0 (the consigned one). But the value returned by _get_cogs_value() is 10. The reason for this is that _get_cogs_value uses the return value of _get_cogs_price_unit() because the delivery is validated. https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move_line.py#L67-L68 Inside get_cogs_price_unit, we use _get_valued_qty() to sum the valued quantity of each move. https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251 But inside get_valued_qty() for our second move, when calling get_out_move_lines(), no lines will be returned because should_exclude_for_valuation() will return True as the owner of the line is not the user. So total qty will be 1. https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L529 If the product is fifo, we return the total value of the moves (10 + 0) divided by total quantity (1). If the product is standard or avco we return the standard price. In both cases the return value is 10. But in both cases it should be 5. https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251-L255 Problem 2) Inside _get_cogs_value(), because there is done moves, we use _get_cogs_price_unit() https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move_line.py#L67-L68 But because there is no valued quantity (because the done moves are internal), the return value will be 0. https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253 So the cogs will have an amount of 0 and no line will be created https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L125-L126 **fix** Prob 1) The first thing to change is to not use the standard price when some quantities are consigned. The other thing is to add the quantities that would have been used if they weren't consigned because in this case we need them in the computation. Indeed these quantities are included in the invoice line quantity. At the end we are multiplying the unit price by the invoice line quantity which includes consigned quantity, so we need to take them into account also when computing the price per cogs quantity. Prob 2) If there is no quantity to value (consigned + not consigned) we fallback on the standard price (just as if there is no move). This solves the issue of partially delivered order because no moves are valued moves in this use case. If there is a quantity to value (and we're in a case where we want the average move value), we use the average move value (which will be 0 if all the moves are consigned, so the consigned use case is also ok) opw-6030161 opw-6001694 Forward-Port-Of: odoo/odoo#256231 Forward-Port-Of: odoo/odoo#255043
This update fixes an issue where portal users couldn't edit messages within the project chatter. The fix prevents a technical error that occurred when attempting to edit a message, ensuring portal users have the full functionality to manage project communications. This improves usability for all users.
Original PR description
## Issue When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything. ## Steps to reproduce 1. Install *Project* (`project`) 2. Create a Project P and a…
## Issue When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything. ## Steps to reproduce 1. Install *Project* (`project`) 2. Create a Project P and a Task T 3. In the Setting of Project P, click *Share Project* and select a portal user 4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button. 5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_** ## Cause The condition causing this error is the following: https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13 where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition. opw-6072570 Forward-Port-Of: odoo/odoo#258234
This update resolves an issue where searching for tags on tasks within the portal caused a system crash. The fix ensures that the search functionality correctly applies the necessary domain logic, preventing errors related to missing data fields in the task tag model. This improves the stability and usability of the task management feature for portal users.
Original PR description
Steps to reproduce: -------------------------- 1. Install Project and create a portal user. 2. Create a project and a task with tags added to it. 3. Share the project with the portal user (Edit…
Steps to reproduce:
--------------------------
1. Install Project and create a portal user.
2. Create a project and a task with tags added to it.
3. Share the project with the portal user (Edit access).
4. Log in as the portal user and open the task.
5. Click on the 'Tags' field and select 'Search More'
Issue:
----------
A traceback occurs:
```ValueError: Invalid field project.tags.display_in_project in condition ('display_in_project', '=', True)```
Cause:
----------
The [ProjectTaskRelationalModel](https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_relational_model.js#L4-L7) calls `_processSearchDomain.`
This method automatically appends a domain when 'showSubtasks' is not enabled.
https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_model_mixin.js#L5-L12
When clicking 'Search More' on the 'Tags' field, the same domain is
applied to the **project.tags** model. However, since **project.tags**
does not have the `display_in_project` field, the ORM raises a ValueError.
In portal, only `project.webclient` assets are loaded, causing
ProjectTaskRelationalModel to be used for all relational fields.
In contrast, internal users use the standard RelationalModel, so the
issue does not occur.
Solution:
-------------
Restrict the domain modification in _processSearchDomain to apply only
when the current model is `project.task` and `report.project.task.user`.
opw-5930427
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258656
Forward-Port-Of: odoo/odoo#249282This update resolves an issue where Point of Sale users were unable to refresh their Viva.com payment tokens, leading to payment processing failures. The fix allows the system to automatically refresh the token, ensuring Viva.com payments continue to function correctly for POS users without requiring administrative privileges.
Original PR description
Point of Sale users only have read access on pos.payment.method. When the stored Viva.com bearer token expires or the API returns invalid credentials, _bearer_token() fetches a new token . That write ran as the POS user and raised an AccessError, although the user was only paying—not editing configuration. Steps to reproduce: ------------------- * Configure Viva.com as payment method. * Open the POS as a user with only Point of Sale / User (not Administrator). * Pay with Viva until the OAuth token must be refreshed (e.g. after expiry or after Viva rejects the current token). > Observation: AccessError: You are not allowed to modify 'Point of Sale Payment Methods' (pos.payment.method) records. Why the fix: ------------ Persist the refreshed viva_com_bearer_token with sudo().write() so the ORM does not require write ACL on pos.payment.method for that internal side effect of an already authorized Viva RPC. opw-6078131 Forward-Port-Of: odoo/odoo#257842
This update resolves an issue where kit products were incorrectly rounding purchase order values due to how the cost share was calculated. The fix ensures that kit product costs are distributed accurately, preventing valuation discrepancies and improving the reliability of purchase order calculations. This impacts how kit products are valued during the ordering process.
Original PR description
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### >…
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10 There are two issues with purchased kit valuation addressed in this PR: ### Issue 1: Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38 This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48 ### Fix of this issue: We set the digits to `False` for stability reason as the columns have been initiallised as "numeric" values and needs to stay numeric: https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650 Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end: https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76 https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227 In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`. ### Issue 2: While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30 Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit). ### Fix of this issue: We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore). opw-5085457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257411 Forward-Port-Of: odoo/odoo#252034
This update fixes an issue where stock lot generation incorrectly used the standard product UoM (Unit) instead of the sales packaging UoM (Pack of 6). The change ensures that lots are created with the correct quantity based on the product's sales packaging, improving inventory accuracy. This resolves a discrepancy in lot quantities.
Original PR description
Steps to reproduce the issue:
- Enable "Units of Measure" and "Lots & Serial Numbers" in the inventory settings
- Create a storable product "P1":
- Tracking: Lot
- UoM: Unit
- Sales tab: Packagings > Pack of 6
- Create a receipt with 3 packs of 6 of P1
- Mark it as "To Do"
- Open the detailed operations and click on the "Generate Serials/Lots" button:
- First lot: Lot 1
- Quantity per Lot: 3 packs of 6
- Quantity received: 3 packs of 6
- Click on "Generate"
Problem:
A stock move line is created with 3 units instead of 3 packs of 6, because the UoM is not passed from the JavaScript side to the Python side. As a result, the default product UoM (Unit) is used.
opw-5933277
Forward-Port-Of: odoo/odoo#258392This update corrects a previous restriction in how the system identifies Spanish freelancers. Specifically, it now recognizes 'Comunidades de Bienes' (CBs) – entities taxed as freelancers – which were previously excluded due to a limited regex. This ensures accurate fiscal categorization and reporting for these businesses.
Original PR description
In Spain, "Comunidades de Bienes" (VAT starting with 'E') are entities without legal personality that tax via income attribution to their members. For accounting and tax reporting purposes, they must be treated as individuals/freelancers rather than corporations. The current _l10n_es_freelancer logic was too restrictive, only matching standard DNI (8 digits + letter) or NIE (starting with X, Y, Z). This caused CBs to be excluded from freelancer-specific logic, leading to incorrect fiscal categorization in reports and tax modules. The regex has been updated to optionally allow the 'E' prefix while ensuring the rest of the string maintains a valid format, effectively broadening the scope of what the system considers a Spanish freelancer. task-6014192 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258474 Forward-Port-Of: odoo/odoo#253087
This update fixes an issue where newly created stock move lines in the picking view would disappear after a refresh. The fix dynamically updates the view to always show all move lines associated with a specific picking, ensuring accurate inventory tracking and preventing data loss.
Original PR description
**Problem:** When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering…
**Problem:**
When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering "Put in Pack").
**Steps to reproduce:**
1. Open a receipt/picking operation
2. Click on the "Moves" smart button to open the detailed operations view
3. Create a new stock.move.line record
4. Click "Put in Pack" or manually refresh the page
5. Observe that the newly created line disappears
**Current behavior:**
The newly created stock.move.line disappears from the view after refresh, and only reappears if you navigate back to the picking and then return to the moves view.
**Expected behavior:**
The newly created stock.move.line should remain visible in the view after refresh or any action that triggers a view reload.
**Cause of the issue:**
The action_detailed_operations method uses a static domain [('id', 'in', self.move_line_ids.ids)] that captures a snapshot of move line IDs at the moment the action is opened.
https://github.com/odoo/odoo/blob/22ac818970f104a732cc7d24afc440cf0e6d74bd/addons/stock/models/stock_picking.py#L1204-L1212 When a new stock.move.line is created in this view, its ID is not included in the original static list. Any refresh (manual or triggered by operations like "Put in Pack") re-applies this static domain, filtering out the newly created lines because their IDs weren't captured in the initial list.
**Fix:**
Using a dynamic domain based on picking_id ensures all move lines belonging to the picking are always visible, regardless of when they were created. This aligns with the expected behavior of showing "all move lines for this picking" rather than "only the move lines that existed when the view was opened". The relational lookup [('picking_id', '=', self.id)] is re-evaluated on each refresh, automatically including any newly created lines that have the correct picking_id set.
opw-5398620
Forward-Port-Of: odoo/odoo#251619
Forward-Port-Of: odoo/odoo#247170This update resolves a stability issue in the spreadsheet pivot feature. Previously, the system incorrectly relied on a single field property, leading to crashes when encountering certain field types (like JSON). The fix ensures the system correctly identifies unsupported field types, preventing errors and improving the overall reliability of the spreadsheet pivot functionality.
Original PR description
Spreadsheet pivots only do not support all field types. But we were relying only on `field.groupable` to determine if a field could be grouped, which is wrong (eg. JSON fields can be groupable but are not supported). It leads to crashes for fields that were groupable, but didn't have an entry in `pivotNormalizationValueRegistry`. Added a test for all of the field types to ensure we have a correct behavior. Task: 6036075 Task: [6036075](https://www.odoo.com/odoo/2328/tasks/6036075) 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#258883 Forward-Port-Of: odoo/odoo#255571