Friday, August 16, 2024
3 changes · 17.0
Enhancements to existing features
The print dialog now automatically closes after users confirm their print job, eliminating the extra step of manually closing it. This improvement makes the printing process faster and more intuitive, reducing unnecessary clicks and improving overall user experience.
Original PR description
Automatically close the print dialog after the user confirms the print job. This enhancement improves user experience by eliminating the need for users to manually close the dialog, streamlining the printing process. Initially, we considered keeping the modal open until all print operations completed successfully. If any printer encountered an error, the modal would remain open. However, this approach doesn't assist users in resolving the issue, as they would still need to close the modal to correct the problem. Therefore, it is more user-friendly to automatically close the modal after user confirmation. https://github.com/user-attachments/assets/659d971e-25c8-487f-8c02-cf0f5461a920 Forward-Port-Of: odoo/enterprise#68195
Resolved issues and error corrections
This fix resolves a system error that occurred when marking items as failed during quality checks on manufacturing orders with backorders. The issue happened because the system was trying to assign multiple inventory lines to a single quality check record. By properly ordering failed items first during the backorder split process, the system now correctly identifies which specific inventory line corresponds to each quality check, preventing the error and allowing quality failures to be properly recorded.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: C1
- Create a quality point:
- Product: P1
- Operation: Manufacturing
- Control per: Quantity
- Control Frequency: All
- Create a manufacturing order:
- Product: P1
- Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check:
- Button Fail
- Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check:
- Button Fail
- Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656This fix corrects how financial reports handle the display of columns with zero values and text-based data. Previously, a change caused text columns (like customer names) to disappear when they should have been visible. The fix refines the logic so that text values are properly treated when deciding whether to hide or show report lines, while ensuring numeric columns like percentages are correctly evaluated.
Original PR description
Partial revert of https://github.com/odoo/enterprise/commit/318ae33da2e36036e1a74028a36d02ad4fa5964e (we keep the test and revert the fix). The reverted commit intended to soluve issues with hide_if_zero, and had it consider the string values as 0. However, in 17.2+, this caused issues with the blank_if_zero columns, which then never showed such string values. We revert the original fix and take a new approach in this commit ; we do that in 17.0 instead of 17.2 just for homogeneity of the code base, and ease of maintenance on longer term. The new strategy is bacisally to consider non-number values as 0 only when handling the hide_if_zero option, without touching to the computation of the is_zero key of column dicts. Also, this commit explicitly adds the 'percentage' figure_type to the ones checked by the 'is_zero' key in column dicts: percentages are numeric values; ignoring them there was wrong.