action #113432
opencoordination #154768: [saga][epic][ux] State-of-art user experience for openQA
coordination #157345: [epic] Improved test reviewer user experience
[easy][beginner] Changing filters on /tests/overview queries having multiple flavors selected looses all flavors but one size:S
Description
Steps to reproduce¶
- Open
https://openqa.suse.de/tests/overview?build=20250424-1&groupid=420&version=5.1&flavor=DVD-Updates&flavor=MicroOS-Image-Updates
or just
https://openqa.opensuse.org/tests/overview?build=X&flavor=who_cares&flavor=no_one
- Observe that the filter menu shows multiple flavors selected
current: DVD-Updates, MicroOS-Image-Updates
- Click on "Filter"
- Observe that Flavor only lists one flavor (the one last specified in the list)
- Example:
flavor=who_cares&flavor=no_one&flavor=foo
only carriesfoo
- Example:
- Click "Apply"
- Observe that only one flavor is now evaluated
Expected result¶
The list of flavors should be preserved
Acceptance criteria¶
- AC1: Ensure all flavors are evaluated & carried over
- AC2: All other form values work like before
- AC3: Each flavor value only appears once and not multiple times in both URL and UI elements
Suggestions¶
- Look into the UI element for "Flavor" where only a single element is taken and compare to other fields where we allow comma-separated values as before
Updated by tinita 14 days ago
- Related to action #181397: Filtering for job result loses selected flavor added
Updated by okurz 11 days ago
- Subject changed from Changing filters on /tests/overview queries having multiple flavors selected looses all flavors but one to [easy][beginner] Changing filters on /tests/overview queries having multiple flavors selected looses all flavors but one size:S
- Description updated (diff)
- Status changed from New to Workable
Updated by okurz 11 days ago
- Has duplicate action #181397: Filtering for job result loses selected flavor added
Updated by emiler 3 days ago
The issue here is not the text input itself, but the way the flavors in the example are filtered.
Other filters, which support comma separation (such as module name) result in &modules=foo%2Cbar
, whereas the example uses &flavor=who_cares&flavor=no_one
while it should be &flavor=who_cares%2Cno_one
with comma separation.
We should instead modify the flavor filter to use comma separation. I am researching how the filtering itself is written and how that would be possible. This will break existing links though. Or is this a path we don't want to take?
Updated by livdywan 3 days ago
We should instead modify the flavor filter to use comma separation. I am researching how the filtering itself is written and how that would be possible. This will break existing links though. Or is this a path we don't want to take?
Purely from a user's point of view I would prefer if the GUI was changed to use the current filtering syntax.
Updated by emiler 3 days ago ยท Edited
livdywan wrote in #note-9:
Purely from a user's point of view I would prefer if the GUI was changed to use the current filtering syntax.
So having a comma separated input field syntax (foo,bar), but instead of "translating" it to &flavor=foo%2Cbar
, it would be &flavor=foo&flavor=bar
correct?
I am guessing that is possible, but it would be different from the other comma separated fields, which expand to &something=foo%2Cbar
.
Updated by emiler 2 days ago
tinita wrote in #note-11:
Both syntaxes have to be supported.
The initial link contains multipleflavor
keys, but when applying the filter, it will be only one key with comma separated values.
In the backend you can support both at the same time.
Sounds reasonable. I'll work with this.