Daily updates from Odoo
Friday, August 16, 2024
10 changes
4 changes
Resolved issues and error corrections
This fix prevents an error dialog from appearing when a logged-in user edits a website page and then uses the browser back button. It makes the website editor cleanup more reliable, reducing disruption for users managing website content.
Original PR description
Since [1] when routing was changed to path-based, the website service's `pageDocument` can be reset before the wysiwyg adapter is destroyed. Because of this, the `destroy` might fail - leading to further errors. Steps to reproduce: - Be logged in. - Access the visitor view of the Home page. - Click on the "Editor" link to reach the back-end view. - Click on "Edit". - Click on the back button of the browser. => An error dialog appears. [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f opw-4074988
This fix ensures Odoo saves valid default values for gevent worker memory settings when configuration files are generated. It prevents later startup or configuration parsing errors caused by invalid empty values, improving reliability for deployments using saved configs.
Original PR description
Since [1], the memory limit for the gevent workers can be configured with the `limit_memory_*_gevent` options. However, defaults are missing. As a result, when the `--save` option is used, the config file contains `None` values for those options. Parsing this file later on will result in an error since `None` cannot be parsed as an integer value. This PR fixes this issue by providing `False` as a default value. This value was chosen over 0 because it clearly indicates the intent to ignore this option and aligns with other option defaults. [1]: https://github.com/odoo/odoo/pull/172604
This fixes a rare timing issue where Chrome could still send a screen recording frame after recording had been stopped. The change prevents unnecessary test crashes and helps keep automated validation results more reliable.
Original PR description
It's not common, but apparently it's possible for Chrome to send a screencast frame after it's been told to stop. I assume because screencasting is asynchronous so if a frame capture is triggered…
It's not common, but apparently it's possible for Chrome to send a screencast frame after it's been told to stop. I assume because screencasting is asynchronous so if a frame capture is triggered before the command to stop reaches the browser, that frame capture may complete and be dispatched.
Locally this seems to occur in about 3.5% of calls to `test_screencasts` (7 out of 200 runs). In those cases, the event sequence looks like this:
T + 0.0000s _save_screencast()
sends `Page.stopScreencast`
T + 0.0002s stop
send `Page.stopScreencast`, unsets `screencasts_dir`
T + 0.0100s _handle_screencast_frame
accesses screencasts_frames_dir
`screencasts_frames_dir` then proceed to access `screencasts_dir`, not handle it being `None`, and break.
To fix, just make `screencasts_frame_dir` return `None` if `screencasts_dir` is `None`. This makes `_handle_screencast_frame` properly no-op on the incoming frame. And remove the redundant check on `screencasts_dir` after having ack'd the frame.
Note that this issue has *not* been reported upstream for consideration, as it would require creating a bespoke test case and I can't be arsed. A search on both the tracker and the internet at large doesn't reveal anything relevant.
Example stagings failed due to this:
- https://runbot.odoo.com/runbot/build/66915127
- https://runbot.odoo.com/runbot/build/66915510
And because it's a "traceback found in the logs" it doesn't seem like the runbot is able to see / track it.This fixes a missing setting in the project customer portal so billable project information is handled correctly. It restores expected behavior that had been accidentally omitted in an earlier change, helping sales and project workflows remain consistent for portal users.
Original PR description
It was missed in 481bfa74a89595df7434a9523e0afc1813b8a774 but added back in master
4 changes
Resolved issues and error corrections
When an online food delivery order is edited and then accepted, its status now refreshes correctly instead of briefly showing outdated information. This helps staff see the current order state immediately and reduces confusion during order handling.
Original PR description
Steps to reproduce: ==== - Place an online food delivery order. - Edit the order. - Now accept the order - Order status will not get updated immediately. Issue: ==== - Order were synced again during accept order so old status was taken into consideration. Fix: ==== - Order is been fetched again with updated status.
This fixes an issue in the Philippine SLSP report where monthly lines displayed blank columns instead of the relevant report option information. Businesses using this report should now see more complete and accurate monthly report details.
Original PR description
Month lines were using empty columns when they should have been using columns with the options information.
Fixed a configuration issue in the accounting lock date wizard so a warning setting is treated as a simple yes/no value. This helps the wizard behave more reliably when showing draft entry warnings.
Original PR description
The field `show_draft_entries_warning` has type `Text` but it should be a `Boolean`. This is fixed in this commit.
Fixes an issue where users could receive an access error when requesting an OTP for Indian GST authentication from the configuration screen. The request now includes the GSTIN, allowing the authentication flow to proceed correctly for affected businesses.
Original PR description
- Before this commit: An Access error is raised while clicking on send OTP for Indian GST on Configuration. - After this commit: That error is fixed by providing GSTIN in the parameter while requesting OTP. issue produced in : https://github.com/odoo/enterprise/commit/61e5101081c87082de4b6d938fbe7ccdb329e7b6
2 changes
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.