Daily updates from Odoo
Tuesday, October 7, 2025
23 changes · saas-18.3
Resolved issues and error corrections
This fix resolves an issue where users could be blocked from validating a backordered delivery in warehouses using a two-step delivery flow. It ensures stock reservations are adjusted correctly when lot-tracked products are split across packages and backorders, helping deliveries proceed without manual workarounds.
Original PR description
# Problem Unreserve issue preventing users from validating a delivery order with 2-step delivery warehouse configuration. Introduced in the following commit:…
# Problem Unreserve issue preventing users from validating a delivery order with 2-step delivery warehouse configuration. Introduced in the following commit: https://github.com/odoo/odoo/commit/13567aa27250f5798bbe42648eeac82241dbb780 # Steps to reproduce on the runbot: - Activate packages - Edit the warehouse to deliver in 2-steps - Create a product tracked by lot - Create two lots with 5 qty each - Create a sale order with 10 qty and confirm - Check the delivery order and assign: => 2 units to lot1 and create a pkg for it => 1 units to lot1 without pkg => 3 to lot2 without package - Validate the delivery and create a backorder - go to pick backorder and try to validate - Unreserve issue pops up - For further details, check: [#225948](https://github.com/odoo/odoo/issues/225948) # Solution: Conditional subtracting limited to new lines only. Task ID: opw-5086289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229994 Forward-Port-Of: odoo/odoo#229420
The bank journal message shown when no transactions are found now displays correctly instead of showing raw HTML text. This improves clarity for users when fetching bank transactions or changing filters with no matching results.
Original PR description
Before this commit : - The help message shown when no transactions were fetched by the 'Fetch Transactions' button in the 'Bank' journal contained raw html tags, as markup was not getting applied. - Also, removing a filter (without reloading) and applying another filter that resulted in no matches, the same issue occurred. After this commit: - The help message is now consistently rendered with markup applied. task-4942234 Forward-Port-Of: odoo/enterprise#95514
Removing formatting from a selected table cell no longer triggers an error when color formatting was applied to the whole table. This makes the HTML editor more reliable for users editing styled tables.
Original PR description
Problem: When having a `table` with `color` and selecting a cell to remove format, we get a traceback: "Infinite Loop in removeAllColor()." Cause: The color is applied on `table`, but we only process `td` for color removal. As the color remains on `table`, each attempt to remove it keeps reapplying, leading to an infinite loop. Solution: When removing color, also remove it from the `table`. Then apply the color to all child `td`. This ensures `td` colors are later removed automatically if selected, avoiding the loop. Steps to reproduce: 1. Add a `color` property to a `table` and `td`. 2. Select the `td`. 3. Click "remove format" from the toolbar. 4. Observe traceback. opw-5112088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229878
Closing the email validation banner now keeps it hidden instead of making the “email sent” message appear again. This avoids confusing repeat prompts and gives users a smoother profile experience.
Original PR description
### Issue Closing the banner triggered `/profile/validate_email/close` RPC, which reset `validation_email_done` to false. This mistakenly caused the “email sent” banner to reappear, confusing users. ### Solution Set `validation_email_sent = False` so the banner stays hidden after being closed. Task-5049533 Forward-Port-Of: odoo/odoo#229913 Forward-Port-Of: odoo/odoo#225872
Credit notes created after a sales down payment now correctly reverse the cost of goods sold. This keeps inventory and accounting entries accurate when customers are refunded after partial invoicing.
Original PR description
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on…
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on ordered quantity - set the category of the product as avco and "inventory valuation" of the category as automated - set an onhand quantity and a positive cost - create a SO for 1 quantity of this product and confirm - click on create invoice, select downpayment percentage and 25% - click on create draft and confirm it - click on create invoice, select regular, create draft - confirm and select credit note - write something in the reason field and click on reserve - confirm it **Current behavior:** if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once) **Expected behavior:** There should be: - A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product. - A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product. **Cause of the issue:** Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/commit/4f9c52c03c65a497937053530e8d6c775d305e35), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L114 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L131 Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L163-L164 As a consequence, - qty_to_invoice will become - qty_to_invoice - account_move will be populated - therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L166-L174 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/product.py#L915 **fix** The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one : - SO for qty of 10 (product invoiced on delivered qty). - 100% downpayment. - deliver 6. - invoice. In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id. opw-5041783 Forward-Port-Of: odoo/odoo#229156 Forward-Port-Of: odoo/odoo#226809
Belgian EC sales reports now correctly handle company VAT numbers even when users entered them without the Belgian country prefix. This prevents valid VAT numbers from being shortened incorrectly and helps keep Belgian reporting accurate.
Original PR description
It could happen that the user set his vat number without the country code before the number. In this case, we removed the two first digits of the vat number. Also changing other occurrence using the company_vat to get the country, since we are in the belgian ec sale list, the country_code should be 'BE' everytime task-5039969 Forward-Port-Of: odoo/enterprise#93377
This fixes an inventory valuation issue where FIFO product costs could be updated from the wrong starting value after a manual revaluation. Product costs now stay aligned with the actual stock valuation, improving inventory and accounting accuracy.
Original PR description
**Steps to reproduce:** - create a storable product with fifo category - update the cost to 200 - click on the on hand smart button and add a quant of 1 quantity - update the cost to 300 - click on…
**Steps to reproduce:** - create a storable product with fifo category - update the cost to 200 - click on the on hand smart button and add a quant of 1 quantity - update the cost to 300 - click on the on hand smart button and update the quantity to 2 - the value should be 500, which makes a 250 value per product - open Inventory/valuation and search your product - group by product, select your product and click on "+" icon to open the revaluation widget - add 200 (so +100 per unit) - go back to the product form **Current behavior:** the cost is now at 400 **Expected behavior:** the cost should be at 350 (250 + 100) If we change the standard_price we should change it in accordance with the valuation **Cause of the issue:** In action_validate_revaluation, during the update of the standard_price, the current standard_price (set by the user and disconnected from the valuation) is used in the computation. https://github.com/odoo/odoo/blob/5118f7cb80744f901d7028dc75c29aba9591b83b/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L127 opw-5028848 Forward-Port-Of: odoo/odoo#228457
Employees with flexible working hours will no longer see weekends incorrectly marked as unavailable in the timesheet grid. This avoids confusion for people who can work on any day and makes time entry reflect their flexible schedule.
Original PR description
To reproduce: ============= 1- Update employee worktime to be flexible 2- Go to timesheets -> saturday & sunday are marked grey Problem: ======== Can't apply https://github.com/odoo/odoo/blob/ce2d134d3e8e5c0d96529c1d0490f1e0c5e28294/addons/resource/models/resource_calendar.py#L511 This logic cannot be applied when an employee's work time is flexible, since they can work whenever they want. Fix: ==== When employee work time is flexible we just return empty list for the unavailable dates. opw-5031144 Forward-Port-Of: odoo/enterprise#96181 Forward-Port-Of: odoo/enterprise#94346
Spanish Point of Sale orders now keep the fiscal position selected by the cashier when the order is validated. This prevents incorrect receipt totals where a previous tax amount could appear as change after switching to a no-tax fiscal position.
Original PR description
Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change. Steps to reproduce: ------------------- *…
Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change. Steps to reproduce: ------------------- * Install l10n_es_pos, switch to es company * In the config of a shop, use fiscal position, set some as available, one as default * Open shop session * Add a product that has taxes * Switch fiscal position to one that has 0% taxes * There should not be taxes in the cart at this point * Go to pay the order (cash or bank) > Observation: On the receipt the previous tax value is counted as change Why the fix: ------------ The issue happens because of the simplified invoice mechanism present in the ES localization. When you validate an order and that order can apply for simplified invoice, if there is no customer on the order the partner is set with the simplified partner. When setting a partner on the order we update the fiscal position and pricelist. https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L929 The fiscal position is updated with the partner's fiscal position or the default one if none on the partner. https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L986-L995 Instead of the fallback on the default fiscal position in the case it is not set on a partner we fallback on the order current fiscal position. If it is different than the default one is means that it was changed intentionally and there's a high chance we want to keep it, otherwise it will already be the default fp. opw-5051231 Forward-Port-Of: odoo/odoo#229237
Reconciled bank statement lines that were marked for checking are now automatically marked as checked, preventing them from getting stuck in a pending review state. When automatic checking is disabled, users can now act directly from the dropdown instead of relying on less convenient activity reminders.
Original PR description
When reconciling a statement line that needs to be checked, the statement line will automatically be checked. We do that because the buttons in the dropdown are not accessible by the user anymore, so to avoid the case where a statement line will stay as to check forever, we just set is as checked. Also when auto-check on post was set to false, we created an activity but it wasn't really easy to use for users. Now they can use the button in the drop down. task-5022806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening the Quality Points button from a product in Point of Sale no longer triggers an error. The fix ensures the correct quality control view is opened, preventing users from being blocked when reviewing quality points for products.
Original PR description
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue**…
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue** `UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: ""quality.point"."product_variant_count" field is undefined."` **Root Cause** https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/point_of_sale/views/product_view.xml#L23-L25 - View reference is passed in the context. - When this context is propagated to `action_see_quality_control_point`, https://github.com/odoo/enterprise/blob/7b777bffbebfb6503bb348005e9ce076825926e4/quality_control/models/quality.py#L579-L584 https://github.com/odoo/enterprise/blob/2e08282ca275bf1e66c58e28391f11f8bd7884d2/quality_control/views/quality_views.xml#L859-L868 - Than traceback occurs because the action does not pass a `view_id`. - When the context contains `list_view_ref`, it attempts to load the product template list view with the `quality.point` model. - This leads to a traceback since the fields defined in that view do not exist on the `quality.point` model. **Solution** - Pass a proper `view_id` from the Python side to ensure the correct view is loaded, preventing `list_view_ref` from forcing to load an invalid template. **opw-** **5090505**
The bank reconciliation dropdown now includes options to mark statement lines as checked or requiring review. This helps accounting users keep reconciliation status accurate even when lines are reconciled and the dropdown is no longer available.
Original PR description
This commit will add buttons in the dropdown to allow users to set the statement line as checked or to check. Also, the community pr will allow that when reconciled the statement line is automatically set as checked since the dropdown is not there anymore. (Known issue is that in this case the filter is not refreshed) task-5022806
Razorpay payment processing now avoids using two authentication methods at the same time, which could cause payment failures in some mobile checkout flows. This helps customers complete payments more reliably when the provider has both standard credentials and OAuth configured.
Original PR description
In a specific context, Razorpay rejects connections using both Key ID/Secret and an access token simultaneously. To reproduce, it's require a real production Razorpay account since Oauth is not available in test mode. Step to reproduce: - Configure Key ID/Secret and connect via OAuth on the Razorpay payment provider. - On iOS/Android, making a payment on the website triggers a "403 Forbidden" error because Razorpay redirect to /payment/razorpay/return and the signature from Razorpay not correspond to the expected signature computed with the Key Secret. This fix prioritizes call with Key ID/Secret over token authentication. opw-5100194 opw-4989944 opw-5039880 opw-5099580
This fix makes an automated cleanup test for signed documents more reliable by avoiding timing-related failures. It helps keep internal validation stable without changing day-to-day user behavior.
Original PR description
Steps to reproduce
==================
Launch the test `test_gc_clear_bin` a few times
It will eventually fail:
documents.document(544,) is not false :
trash document should be deleted after gc_clear_bin
Cause of the issue
==================
The domain for wether a record should be deleted contains `('write_date', '<=', fields.Datetime.now() - relativedelta(days=deletion_delay)`
The tests fails when the write_date is in the same second as the test run.
This is because fields.Datetime.now() replaces microseconds by 0.
https://github.com/odoo/odoo/blob/14073faf1fa272b8d3411b4fe6f42c279058459d/odoo/fields.py#L2378
Solution
========
Since records needs to be at least "deletion_delay" old, we add a margin of 30 seconds to make sure they match
runbot-224207
Forward-Port-Of: odoo/enterprise#95926The Unrealized Currency Gains/Losses report now correctly creates draft adjustment entries even when users customize report grouping. This prevents a misleading "No adjustment needed" error and supports more flexible report configurations.
Original PR description
**Steps to reproduce** - Edit "Unrealized Currency Gains/Losses" report configuration as follows: - Lines > Accounts To Adjust, set GroupBy to 'currency_id, partner_id, account_id, id' - Lines > Excluded Accounts, set GroupBy to 'currency_id, partner_id, account_id, id' - In Options, check 'Unfold All' - View the report > Click 'Adjustment Entry' **Issue** Instead of creating a draft journal entry an user error "No adjustment needed" will block the action **Solution** The issue occurs because when retrieving the lines we assume they are grouped as per default, by 'currency_id, account_id' In case users modify the expression line default grouping to something else, like 'currency_id, partner_id, account_id', we no longer collect values correctly. In order to fix the issue we can unfold all and manually group values by currency_id, account_id opw-4792502 Forward-Port-Of: odoo/enterprise#90894
Users who can print and send SEPA direct debit mandates can now generate, send, and reopen the related PDF attachments without needing an extra accounting read-only role. This removes a permission mismatch that could block mandate emails or make generated attachments inaccessible to the users who created them.
Original PR description
Removing the groups restriction from the `mandate_pdf_file` field in model `sdd.mandate` because it was causing issues when using the `sdd.mandate.send` wizard. Any user who has access to the `sdd.mandate` model can use this wizard to print and send the record. During this process, the system generates a PDF and stores it in the `mandate_pdf_file` binary field, linking the resulting attachment to the record. The previous group restriction prevented users who were not part of the `account.group_account_readonly` group from sending the email with the attachment. Even if the email was somehow sent, those users still couldn’t access the attachments they themselves had generated and sent. With this change, any user who is allowed to send and print `sdd.mandate` records will also be able to generate and later access the corresponding attachments. Forward-Port-Of: odoo/enterprise#96119
Point of Sale now saves large local data sets in smaller steps instead of trying to process everything at once. This reduces the chance of failed or slow data saves, improving reliability when handling high volumes of sales data.
Original PR description
When saving large datasets to IndexedDB, all batches were started in parallel. This could cause excessive open transactions, long execution times, and premature transaction aborts due to the timeout. With this commit, batches are now processed one at a time, ensuring that each batch completes before starting the next. This improves stability and prevents transaction overload when handling high volumes of data. opw-5052956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updates the spreadsheet component to a newer version with several fixes that make spreadsheets more reliable. Users should see fewer issues with formatting, pivot calculations, sheet renaming, and spreadsheet headers.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4764cba65 [REL] 18.3.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4764cba65 [REL] 18.3.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/01de174f41 [FIX] format: wrong internal format conversion [Task: 5126306](https://www.odoo.com/odoo/2328/tasks/5126306) https://github.com/odoo/o-spreadsheet/commit/e53c7f5125 [FIX] Evaluation: remove spread relations [Task: 5105030](https://www.odoo.com/odoo/2328/tasks/5105030) https://github.com/odoo/o-spreadsheet/commit/7a80bf28f1 [FIX] spreadsheet: prevent sheet name edit from losing focus [Task: 5109129](https://www.odoo.com/odoo/2328/tasks/5109129) https://github.com/odoo/o-spreadsheet/commit/0b6565e4de [FIX] headers: can add lots of headers [Task: 5092626](https://www.odoo.com/odoo/2328/tasks/5092626) https://github.com/odoo/o-spreadsheet/commit/af28911cdb [FIX] pivot: add deferred calculated measure [Task: 5096156](https://www.odoo.com/odoo/2328/tasks/5096156) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Manufacturing order overviews can now be opened even when the order has no linked bill of materials. This prevents an error after completing such orders and helps users review production information without interruption.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Create a manufacturing order to produce one unit of P1: - add any component - Mark the MO as done - Try to open the MO overview Issue: An error is raised because the MO has no BoM. But in the function we try to compute the missing quantity in the BoM's UoM, but since no BoM is linked, there is no UoM available. Error message: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure %(product_unit)s defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category." Fix: Skip the computation of missing BoM quantities when no BoM is linked, allowing the MO overview to be opened without error. opw-5112132 Opw-5105544 Opw-5119897 Forward-Port-Of: odoo/odoo#229707
This change removes a non-essential test check that could fail unpredictably when product lists changed. It helps keep point-of-sale loyalty testing stable without affecting customer-facing behavior.
Original PR description
Before this commit, some tests could fail randomly if a new product was included in the list of limited loading products. The part of the test that checked whether the product was not loaded was not essential, so it has been removed to prevent unnecessary failures. opw-5109838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unreliable automated test for bus notifications by making sure every notification in a received batch is checked. The change helps reduce false test failures and improves confidence in release validation without changing user-facing behavior.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. However, the listener only consider the first notification of the batch (`conn.notifies.pop()`) and ignore the rest. When the expected notifications come as part of a bigger batch, they can be ignored thus making the test fail. This commit ensures we read every notification received. fixes runbot-233185 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#230117 Forward-Port-Of: odoo/odoo#230054
Unmarking a completed package in Inventory now correctly clears the related picked status, so delivery orders no longer get stuck waiting and can check availability again. The fix also preserves picked status when users manually enter done quantities after starting from zero stock, avoiding a new workflow regression.
Original PR description
### Issue: To reproduce the bug: 1. Activate `Packages` settings in Inventory: 2. Activate `Move entire packages` on picking type `delivery orders` 3. Create new product `Test move package` 4. Update…
### Issue:
To reproduce the bug:
1. Activate `Packages` settings in Inventory:
2. Activate `Move entire packages` on picking type `delivery orders`
3. Create new product `Test move package`
4. Update quantity in `WH/Stock` with a newly created package and a qty (eg 5)
5. Go to the delivery orders and create a new picking with the created product and a quantity of 5
6. Click on `Mark as Todo`, the picking is set as ready and a package level is created automatically to move the quantity we did put in stock in the package.
7. Mark the checkbox `Done` on the package level (this will mark the move line and the move as picked)
8. Unmark the checkbox `Done` on the package level.
The package level is deleted, as well as the stock move line,
but the stock move still has the checkbox picked that is
marked.
The picking is then in waiting state and we cannot check
availability again.
Currently to be able to check the availability, the picked
check should be undone manually.
### Cause of issue
Currently, in `_compute_picked` in `stock_move`, we don't
update value of move.picked if there is `no move_line_ids`
present which is wrong.
### Fix:
In the fix, picked is set to False when there no
`move_line_ids`
### Issue 2
This fix cause another issue, in which the move loses its `picked` status after manually setting the done quantity when no stock was initially available,
### Cause of issue 2
To be more specific this fix on `_compute_picked`
```diff
- elif move.move_line_ids:
move.picked = False
+ else:
move.picked = False
```
has the following side effect:
- On a confirmed picking, pick a move with a quantity of 0 then change the quantity to 10 the move is unpicked -> undesirable.
After you picked the move, when you set the quantity, you will set `move_line_ids` on your move to match the quantity increase here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L2157-L2165
However,`self._set_quantity_done_prepare_vals(qty)` does not return a `stock.move.line` record set but a `Command.create` whose values do not contain any info on the picked value of the move *line*:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
The fact that the `move_line_ids` is set on the move to this command.create, flags the `picked` field of the stock move to dirty and adds it to the field to recompute because of the dependency `move_line_ids.state`:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L208-L209
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/odoo/api.py#L795-L800
THEN, the creation of the move.line happends and since the value of the picked was not set in the command.create, we populate it based on the picked value of the move:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move_line.py#L347-L348
However, at this point since the picked value of the move has been flagged as dirty it is recomputed using the `compute_method` modified in our fix.
And since the move does not have any move line at this stage, it is computed to be picked = False resetting the picked value.
### Fix of Issue 2:
We should set the picked values in the vals here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
opw-4964561
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222034This fix clears invalid saved device identifiers before sending UK HMRC requests. It helps prevent rejected submissions caused by outdated or corrupted browser data, improving reliability for UK tax reporting users.
Original PR description
There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086 Forward-Port-Of: odoo/enterprise#96409 Forward-Port-Of: odoo/enterprise#87335