Thursday, July 14, 2022
3 changes · master
Resolved issues and error corrections
Sales orders with multiple linked payment attempts now confirm correctly when exactly one payment is authorized or completed. This prevents valid paid orders from being blocked just because earlier or extra payment transactions exist.
Original PR description
Before this commit, orders were not confirmed when there was more than one transaction linked to them, regardless of their state. As of now, we check if there is only one confirmed transaction (meaning that the state of the transaction is either 'authorized' or 'done'). Fix https://github.com/odoo/odoo/commit/4d2b04a843c27981e44d6f932d7cf7e6838b4b9d task-2906040
Dragging articles within nested Knowledge trees is now smoother and more predictable. This prevents flickering and reduces the need to drag far past the intended position, making article organization easier for users.
Original PR description
Prevent a flickering effect when dragging item down in a nested tree using the jquery.mjs.nestedSortable library. This is done by preventing the placeholder to go UP the DOM while moving the mouse DOWN. To go UP the tree in a situation where the mouse cursor is above the placeholder, the user should move the mouse UP or RIGHT. Force a position refresh of the following articles when starting an article move. Before this change, the library used obsolete coordinates to evaluate if the helper intersects with another article below, forcing the user to drag the nest far below the target position to move the placeholder. Task-2883290 PR SAAS-15.4:COMMUNITY: https://github.com/odoo/odoo/pull/93719 PR SAAS-15.4:ENTERPRISE: https://github.com/odoo/enterprise/pull/29307 PR MASTER:ENTERPRISE: https://github.com/odoo/enterprise/pull/29315
This fixes an issue where records grouped by the same date field at different levels, such as month and week, could lose the correct date range information. The change helps reports and grouped views calculate and navigate date-based groups more reliably.
Original PR description
There was an issue with the computed `read_group` `__range` when grouping on the same date/datetime field on multiple granularities (i.e. month, week). Since the range was stored with the field_name…
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519