-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change version filter to allow substrings #11258
Conversation
This makes it a bit nicer to see more versions in an easy way.
What was the use case for this change? I'm curious where you are hitting this, as the version filters do already support substring lookup and always use the full slug for filtering. I'm not opposed to allowing optional substring lookup for filtering, but we shouldn't use This particular filter does need to be updated and have the API interaction removed, but the UX will still be similar, and should already support substrings from the front end: Screencast.from.2024-04-04.08-37-01.webm |
I want to be able to send someone a link that filters the versions by a substring, or some other way of easily showing a set of versions to someone. Something like: https://beta.readthedocs.org/projects/test-builds/?version=build-tools- |
Gotcha, yeah that would be handy. We can add a new filter for the separate lookup expression instead, ie: https://beta.readthedocs.org/projects/test-builds/?version__icontains=build-tools- I think either the project or build filters have multiple lookup expressions for a single field, but if not, it looks like the examples here: https://django-filter.readthedocs.io/en/stable/guide/usage.html#declaring-filters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just marking this as request changes to not merge by mistake. It seems we want to add a new filter here version__icontains
It would be good to move forward with this PR. I also found myself wanting to write |
@agjohnson yes, you are right. The problem I'm having is that there is always a version selected while you are typing. So, there is no way to select "all the versions starting with |
Yes, this UI is not meant to support multiple selection. I think the way to tie what you are looking for into the UI would be an explicit menu item for "Show all versions matching test", which triggers a different filter lookup. We'd still not be changing the existing lookup method and would use a different filter field/lookup like described above instead. |
I don't want to select multiple versions from the choice field. I just want to write |
I'm not describing selecting multiple versions in the version dropdown list, it's not the right element to use. Above I described a dedicated menu item, it would link to the listing view with an GitHub has a dedicated menu item in their search dropdown, which is what I think we should do:
I'm also describing this already, but with an explicit menu item like the GitHub example above -- "Show all versions matching {query}...". I'm not opposed to making this item the default selected. This would load the view with the filter when you hit enter after typing. But this option should be an explicit menu item for clear UX.
I'm not describing another view either, just adding the We can't do this dynamically, as that requires handling this whole view in Knockout and with in-memory version data. This pattern is avoided on purpose as it requires working in JS/Knockout more. These views are paginated so we can't simply filter the listing table. I disagree that this should not be an explicit menu item though. It's not clear that hitting enter is going to do anything, and an explicit menu item is a really small affordance to add in. |
Sounds good to me 🤝 . I've opened readthedocs/ext-theme#471 |
This makes it a bit nicer to see more versions in an easy way.