Friday, September 22, 2023
4 changes · master
Resolved issues and error corrections
The activity view now paginates records correctly when many items have multiple activities, so users see the expected number of records on each page. This prevents missing or confusing activity results when navigating large activity lists.
Original PR description
This solves the following problem: - Add 150 records with 2 activities each (ex. A call and a to do) - Go to the activity view (ex.: event through the systray) and clear filter - Only 50 of the 150 records are displayed (instead of 100) - Going to the next page, only 2 are displayed (instead of ~50) (will depends on the data already present) Technical notes: Not all activities were displayed because the search limit was applied on the activity search instead of searching all activity related to the records. The method fetchActivityData was doing half of the job because it was not assigning the activity data fetch on the server to the instance variable activityData, which was causing strange behavior when clicking on next page. To simplify and correct the code, that logic has been moved to that method instead of relying on the caller to do that assignation. Task-3508744
This fix ensures several field widgets refresh correctly when records are updated, preventing stale or incorrect information from being shown. It improves reliability in accounting, inventory, manufacturing, email marketing, and general web interface screens affected by recent model changes.
Original PR description
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
The web editor now avoids a crash that could happen when users switch between records containing editable HTML content. This makes navigation between items such as tasks or Knowledge articles more reliable and prevents interruptions while editing or reviewing content.
Original PR description
How to reproduce: - open a record with an html_field (i.e. todo or a Knowledge article) - switch back and forth with the pager or the knowledge sidebar between 2 records Current behavior: - traceback…
How to reproduce: - open a record with an html_field (i.e. todo or a Knowledge article) - switch back and forth with the pager or the knowledge sidebar between 2 records Current behavior: - traceback `this._elementHookMap.get(element)` is undefined Expected behavior: - no traceback Technical explanation: When changing the editable content (i.e. `resetContent` when changing record), there is no guarantee that `_intersectionObserverCallback` (intersectionObserver) won't be called before `_updateHooks` (mouseMove/resize after a mutation occured). This is an issue because `this._elementHookMap` may not yet have a hook element related to the editable element which stops intersecting the document. If such a case occurs, the next `_updateHooks` should be called when the mutationObserver flags `_resetHooksNextMouseMove` to `true` and then after the next `mouseMove` (or after the next resize). Ignore the hook style update if there is currently no hook for an element which stops intersecting. Remove a redundant check in `_getMovableElements` task-3506666
Point of Sale orders shared between registers now include products even when the receiving register had not loaded them yet. This prevents incomplete orders and helps staff process cross-register sales accurately.
Original PR description
Prior to this commit if an order was sent to another pos with the cross order, if the product was missing in the target pos, the product will be missing in the order. This commit loads the products that are missing for the cross orders. Task-3504316