Navigate
Branch
Saturday, November 23, 2024
12 changes
4 changes
Miscellaneous changes
Before this PR, If the deliveryslip report had many fields, say more than 5, they will be all placed on the same line, and it will be very hard to read them since they will be squashed. This is problem is more relevant when the language used for the report is a language where the words are usually long, like the german language. Now, we force at most 4 fields per line, which makes the report layout cleaner in most cases. Before <img width="613" alt="image" src="https://github.com/user-
Original PR description
Before this PR, If the deliveryslip report had many fields, say more than 5, they will be all placed on the same line, and it will be very hard to read them since they will be squashed. This is problem is more relevant when the language used for the report is a language where the words are usually long, like the german language. Now, we force at most 4 fields per line, which makes the report layout cleaner in most cases. Before <img width="613" alt="image" src="https://github.com/user-attachments/assets/49d88491-96d1-4ce3-9e06-73be713956cf"> After <img width="615" alt="image" src="https://github.com/user-attachments/assets/d20337d6-dcc1-46f0-8386-18f67091538c"> opw-4227666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184769
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
Computing the field in su = False was not working as assigned the variable on the sudo environment. The test in 0baa908385 was working as the read computes the display_name in sudo. Forward-Port-Of: odoo/odoo#188347 Forward-Port-Of: odoo/odoo#188310
Original PR description
Computing the field in su = False was not working as assigned the variable on the sudo environment. The test in 0baa908385 was working as the read computes the display_name in sudo. Forward-Port-Of: odoo/odoo#188347 Forward-Port-Of: odoo/odoo#188310
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#1875262 changes
Miscellaneous changes
Currently, An error occurs while opening a 'Production Analysis' report, and the module name `mrp_workorder` is not installed. Steps To Reproduced: - Install ```mrp_account_enterprise```. - Uninstall ```mrp_workorder```. - Open Manufacturing / Reporting / Production Analysis and an error is generated. ``` UndefinedColumn: column wc.employee_costs_hour does not exist LINE 248: * wc.employee_costs_hour * op.employee_ratio ``` An error occurs when the system tries to access fields
Original PR description
Currently, An error occurs while opening a 'Production Analysis' report, and the module name `mrp_workorder` is not installed. Steps To Reproduced: - Install ```mrp_account_enterprise```. - Uninstall…
Currently, An error occurs while opening a 'Production Analysis' report, and the module name `mrp_workorder` is not installed. Steps To Reproduced: - Install ```mrp_account_enterprise```. - Uninstall ```mrp_workorder```. - Open Manufacturing / Reporting / Production Analysis and an error is generated. ``` UndefinedColumn: column wc.employee_costs_hour does not exist LINE 248: * wc.employee_costs_hour * op.employee_ratio ``` An error occurs when the system tries to access fields like `employee_cost`, and `employee_costs_hour` at [1]. but it is unavailable as the module `mrp_workorder` has not been installed. These fields are defined in it. Link [1]: https://github.com/odoo/enterprise/blob/baba978bca701c589eb0d45527275b6275eec5c5/mrp_account_enterprise/reports/mrp_report.py#L206 To resolve this issue, Move the `_join_expected_component_cost_unit` method into bridge module `mrp_workorder_hr_account`, Additionally, Create dummy methods to provide a default value for fields([2]) that are not working and override these methods in the bridge module to return the correct values. Link [2]: https://github.com/odoo/enterprise/blob/baba978bca701c589eb0d45527275b6275eec5c5/mrp_account_enterprise/reports/mrp_report.py#L64-L78 Sentry-5794503324 Forward-Port-Of: odoo/enterprise#73695 Forward-Port-Of: odoo/enterprise#69559
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
6 changes
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