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=fooonly 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 21 days ago
- Related to action #181397: Filtering for job result loses selected flavor added
Updated by okurz 18 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 18 days ago
- Has duplicate action #181397: Filtering for job result loses selected flavor added
Updated by emiler 10 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 10 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 10 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 9 days ago
tinita wrote in #note-11:
Both syntaxes have to be supported.
The initial link contains multipleflavorkeys, 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.
Updated by emiler about 15 hours ago
- Status changed from Workable to In Progress