Daily updates from Odoo
Saturday, November 23, 2024
6 changes · 18.0
Miscellaneous changes
Steps to reproduce: - Create a product tracked by lot with a BOM - Create and confirm an MO for 5 units of that product - Assign a producing lot via the [+] smart button, and produce all - Create, confirm, and validate the shipping for a SO of 3 items of that product - Go back to the MO, unlock it, and change the quantity producing to 10 - Go to the product page, click on "On Hand" > See that there exists 12 products with a lot id, and -5 **without** a lot id Expected behavior: Ther
Original PR description
Steps to reproduce: - Create a product tracked by lot with a BOM - Create and confirm an MO for 5 units of that product - Assign a producing lot via the [+] smart button, and produce all - Create,…
Steps to reproduce:
- Create a product tracked by lot with a BOM
- Create and confirm an MO for 5 units of that product
- Assign a producing lot via the [+] smart button, and produce all
- Create, confirm, and validate the shipping for a SO of 3 items of that product
- Go back to the MO, unlock it, and change the quantity producing to 10
- Go to the product page, click on "On Hand"
> See that there exists 12 products with a lot id, and -5 **without** a lot id
Expected behavior:
There should be 7 products with lot it, and **NO products without lot id**
Cause of the issue:
When increasing the quantity producing, the newly created stock move line
(SML) is created without a lot id: https://github.com/odoo/odoo/blob/d5a7a3d02e3e2b4e47977abc8b9fc0d5d6135937/addons/stock/models/stock_move.py#L1471-L1477
Then only later, we update this new created move line to give it a lot_id
https://github.com/odoo/odoo/blob/a4ca3a3d6eb368bebcbcad00d81e098ee86a8610/addons/mrp/models/mrp_production.py#L900-L901
This update will first cause an undo of some move lines, calling `_synchronize_quant` (first call)
https://github.com/odoo/odoo/blob/49d25c58db2329d097566dc222d97cd8988d640d/addons/stock/models/stock_move_line.py#L459-L461
then, the actual lot_id update is committed
https://github.com/odoo/odoo/blob/49d25c58db2329d097566dc222d97cd8988d640d/addons/stock/models/stock_move_line.py#L473
then after that, another call to `_synchronize_quant` is being made to apply the changes (second call) https://github.com/odoo/odoo/blob/49d25c58db2329d097566dc222d97cd8988d640d/addons/stock/models/stock_move_line.py#L476-L477
However, since `_synchronize_quant` depends on reading the untracked quantities to decide
if it can compensate for negative values
https://github.com/odoo/odoo/blob/49d25c58db2329d097566dc222d97cd8988d640d/addons/stock/models/stock_move_line.py#L645
it sees different value of `untracked_qty` in the first call than that in the second call,
which makes things go out of sync.
Solution:
The newly created move line has the correct lot_id at the moment of the creation,
so we avoid the issue of updating it later, and risking the quantities to go out of sync.
Another solution might be to edit the `write` method of `StockMoveLine`, by committing
changes related to lot_id before undoing any move lines
```py
if updates['lot_id'] and ml.lot_id != updates['lot_id']:
super(StockMoveLine, ml).write({ 'lot_id': updates['lot_id'] })
# then here proceed to undoing
```
opw-4043539
Forward-Port-Of: odoo/odoo#187526Bank statement lines created from the form view won't have an `internal_index` value set yet. Running balance computation should set a value also on manually deleted lines from the form view as the balance is a computed non-stored field. @Tecnativa TT50906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188252 Forward-Port-Of: odoo/odoo#182497
Original PR description
Bank statement lines created from the form view won't have an `internal_index` value set yet. Running balance computation should set a value also on manually deleted lines from the form view as the balance is a computed non-stored field. @Tecnativa TT50906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188252 Forward-Port-Of: odoo/odoo#182497
This [fixed](https://github.com/odoo/odoo/pull/156423) proposed to avoid infinite loop but still issue is reproducable **steps to reproduce:-** account group is create with ``3 code_prefix`` another account group create with ``31 code_prefix`` and if change the ``3 code_prefix`` something like ``312`` code prefix is changed so it will cyclic parent child relation ``` test_rr=# select id,parent_id,code_prefix_end,code_prefix_start,parent_path from account_group; id | parent_id | cod
Original PR description
This [fixed](https://github.com/odoo/odoo/pull/156423) proposed to avoid infinite loop but still issue is reproducable **steps to reproduce:-** account group is create with ``3 code_prefix`` another…
This [fixed](https://github.com/odoo/odoo/pull/156423) proposed to avoid infinite loop but still issue is reproducable **steps to reproduce:-** account group is create with ``3 code_prefix`` another account group create with ``31 code_prefix`` and if change the ``3 code_prefix`` something like ``312`` code prefix is changed so it will cyclic parent child relation ``` test_rr=# select id,parent_id,code_prefix_end,code_prefix_start,parent_path from account_group; id | parent_id | code_prefix_end | code_prefix_start | parent_path ----+-----------+-----------------+-------------------+------------- 12 | 11 | 31 | 31 | 11 | 12 | 312 | 312 | ``` because this constraint that is introduced in above mentioned pr will not apply on because this is sql update and it will not go check due to python [constraint](https://github.com/odoo/odoo/blob/e20263c4bba3e3cff5b8c7d68f07ce6c7e0bd9aa/addons/account/models/account_account.py#L870). For resolving this checking and reverting the wrong changes done in ``parent_id`` because of the update [query](https://github.com/odoo/odoo/blob/d1be9e4a4ec2cf6eaafe982b5b0036afa5421207/addons/account/models/account_account.py#L911-L927) and preventing from infinite [loop](https://github.com/odoo/enterprise/blob/077d5a0f2bb8d4b1602e993b3e84c5ca9fd877d1/account_reports/models/account_report.py#L1006C15-L1009C44). opw-4342094 upg-2144655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188027
Before this commit, the invalid `many2many_tags_avatar` input has two layers of transparent background-color so the two colors stack one uppon the other one and so we had a inconsitancy color with others invalid field. This commit adds the `.o_field_many2many_tags_avatar` so the following CSS rules are also apply like on the `.o_field_many2many_tags`. And so the child input has `background-color: transparent` when the input is invalid. ```css .o_input { --o-input-background-color: transp
Original PR description
Before this commit, the invalid `many2many_tags_avatar` input has two layers of transparent background-color so the two colors stack one uppon the other one and so we had a inconsitancy color with others invalid field.
This commit adds the `.o_field_many2many_tags_avatar` so the following CSS rules are also apply like on the `.o_field_many2many_tags`. And so the child input has `background-color: transparent` when the input is invalid.
```css
.o_input {
--o-input-background-color: transparent;
}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#188318
Forward-Port-Of: odoo/odoo#188256when cloud_storage is enabled for some uploader, the file size check should be removed to allow larger files to be uploaded to the cloud storage there are 4 places shouldn't check the file sizes 1. discuss <img width="1495" alt="image" src="https://github.com/user-attachments/assets/4d7e3b86-4de7-440f-bc97-4084609e9efd"> 2. form view attachemnt (when the attachment list was empty) <img width="1450" alt="Screenshot 2024-11-15 at 14 50 13" src="https://github.com/user-attachments/assets/2
Original PR description
when cloud_storage is enabled for some uploader, the file size check should be removed to allow larger files to be uploaded to the cloud storage there are 4 places shouldn't check the file sizes 1.…
when cloud_storage is enabled for some uploader, the file size check should be removed to allow larger files to be uploaded to the cloud storage there are 4 places shouldn't check the file sizes 1. discuss <img width="1495" alt="image" src="https://github.com/user-attachments/assets/4d7e3b86-4de7-440f-bc97-4084609e9efd"> 2. form view attachemnt (when the attachment list was empty) <img width="1450" alt="Screenshot 2024-11-15 at 14 50 13" src="https://github.com/user-attachments/assets/20e69645-31f3-44ed-9021-ac524a1cf90c"> 3. form view attach files button (when the attachment list is not empty) <img width="1475" alt="Screenshot 2024-11-15 at 14 51 45" src="https://github.com/user-attachments/assets/8370ff5c-71c2-414f-a89b-fa44b3732398"> 4. log note/send messages <img width="383" alt="image" src="https://github.com/user-attachments/assets/274027b7-ad6e-436b-9c6a-3f12515a6f7d"> 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#187402
Some clients were confused about not knowing why their shifts were not copied after setting a project to them (using the copy previous week feature). The reason was that the project linked to their shifts had allocated hours equal to 0. After this commit, if 0 hours are allocated to the project, we allow to copy the shift anyway to avoid confusion (as some clients are clearly not using this field). task-4074736 version-17.0 Forward-Port-Of: odoo/enterprise#73365
Original PR description
Some clients were confused about not knowing why their shifts were not copied after setting a project to them (using the copy previous week feature). The reason was that the project linked to their shifts had allocated hours equal to 0. After this commit, if 0 hours are allocated to the project, we allow to copy the shift anyway to avoid confusion (as some clients are clearly not using this field). task-4074736 version-17.0 Forward-Port-Of: odoo/enterprise#73365