improvement(ViewDashboard): Per-widget item filtering #574
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
UI demo:
|
soyacz
reviewed
Jan 22, 2025
frontend/Views/ViewDashboard.svelte
Outdated
| }; | ||
|
|
||
| const filterViewForWidget = async function (widget) { | ||
| if (!widget.settings.filter) { |
There was a problem hiding this comment.
isn't in js that anempty array (filter=[]) evaluates to true (not like in the python)?
| const test = tests[item.id] ?? {}; | ||
| return ["id", "release_id", "group_id"].some((key) => widget.settings.filter.includes(test[key])); | ||
| }); | ||
| return viewCopy; |
There was a problem hiding this comment.
this way we return view object in case of no filters and view copy in case of filters present.
Maybe we should align it to not cause future issues?
Or even to add new filteredTests attribute which would be used in widgets?
There was a problem hiding this comment.
Yes, I was deliberating whether or not always return a copy, so I think for safety we should always return a copy here. Fixed
This commit implements per-widget entitity filtering for views,
allowing users to select which tests/groups/releases they want shown on
the widget in a specific view. To facilitate this, stat fetching has
been modified to accept widget id (position) of a view and then filter
tests accordingly. On the frontend side to facilitate conflict-free stat
fetching (for example from two TestDashboards) a hashmap has been
introduced to handle multiple stat objects and to dispatch them
correctly to each widget.
Caveats:
* Release Planner views in general are not supported and contain
several unwanted interactions:
* If test dashboard is modified to filter anything, release
planner stat bar will be gray (since there's no more anchor
for it to get the stats from)
* Anything version related will conflict
* TestDashboard has a setting for a specific ScyllaVersion filter
preset - this is not compatible and will make that filter set only
output that version, which might be undesirable.
* Aside from TestDashboard, currently no other widgets implement
stat fetch, so filtering for them might not be interesting.
However the widget will now receive filtered set of tests, which
should make the performance summaries automatically support this
feature.
Fixes scylladb#393
k0machi
force-pushed
the
views-per-widget-filtering
branch
from
73d1b64 to
e51d93c
Compare
|
I tested it locally with summary widget - it does not filter tests there (but at least does not break anything) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit implements per-widget entitity filtering for views,
allowing users to select which tests/groups/releases they want shown on
the widget in a specific view. To facilitate this, stat fetching has
been modified to accept widget id (position) of a view and then filter
tests accordingly. On the frontend side to facilitate conflict-free stat
fetching (for example from two TestDashboards) a hashmap has been
introduced to handle multiple stat objects and to dispatch them
correctly to each widget.
Caveats:
several unwanted interactions:
planner stat bar will be gray (since there's no more anchor
for it to get the stats from)
preset - this is not compatible and will make that filter set only
output that version, which might be undesirable.
stat fetch, so filtering for them might not be interesting.
However the widget will now receive filtered set of tests, which
should make the performance summaries automatically support this
feature.
Fixes #393