Change version filter to allow substrings

[ericholscher]

This makes it a bit nicer to see more versions in an easy way.

[agjohnson]

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 icontains by default for the filters because there are some UIs that link to the version/project listing view with a specific version in the filter. Using substring lookup would display unexpected versions in this case.

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

[ericholscher]

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-

[agjohnson]

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

[humitos]

Just marking this as request changes to not merge by mistake. It seems we want to add a new filter here version__icontains

[humitos]

It would be good to move forward with this PR. I also found myself wanting to write test and list all the versions that start with test instead of only the version that matches completely.

[agjohnson]

Just noting that the UI that triggers a filtered version list already does this:

The issue here seems solely about linking users to list of versions with icontains lookups instead of exact matches.

[humitos]

@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 text" and get a resulting listing page with those versions.

[agjohnson]

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.

[humitos]

I don't want to select multiple versions from the choice field. I just want to write test hit enter and get a filtered list of all the version that contains test on its name. I don't think we need another view, an explicit menu item or anything different for this -- it's pretty common functionality of a filter view.

[agjohnson]

I don't want to select multiple versions from the choice field

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 icontains={query} filter.

GitHub has a dedicated menu item in their search dropdown, which is what I think we should do:

I just want to write test hit enter and get a filtered list of all the version that contains test on its name.

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 don't think we need another view, an explicit menu item or anything different for this -- it's pretty common functionality of a filter view.

I'm not describing another view either, just adding the icontains filter field like I described above. It's the same view we're already using.

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.

[humitos]

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

Sounds good to me 🤝 . I've opened readthedocs/ext-theme#471