(api) Make duration fields available as filters in the /cases/search/ page

[mfonism]

Refs #1923

Without filtering on any duration field

Filtering on expected duration

[atodorov]

Added some comments and some changes requested.

[atodorov]

Hmmm. This should allow for an interval inclusion, e.g. search for test cases where setup_duration is between 5 and 10 minutes. See the created field on this page. With the current duration widgets the UI will become rather clunky IMO. I don't have good suggestions though.

[atodorov]

See https://ux.stackexchange.com/questions/45656/time-duration-entry-in-webapp-pros-cons-of-various-designs for some hints & inspiration.

The widget itself needs to be as compact as possible because of the limited real estate on the screen, however it needs to allow for selecting either an exact duration (e.g. ==) or a range (from-to). One idea that comes to mind is a more complex JS widget with popups that include the individual bootstrap duration fields. However that could also be a next step b/c it sounds like a lot of work.

[mfonism]

I've looked at the SE page you linked in your comment. I have an idea for the more complex widget you suggested. I'll flesh out the idea on paper and share the sketch with you on Slack.

[atodorov]

OK, let's see how it will look like. Just remember - keep it simple as much as possible.

[atodorov]

Question: do comparisons (lookups __gt, __lt, etc) against values in seconds work for these fields ?

Also see for hints the __range field lookup, which is however only defined for DateTime fields:
https://docs.djangoproject.com/en/3.2/ref/models/querysets/#range

IDK if it will be any good but we may need to resort to creating our own field lookup around duration fields. I'm not seeing anything out of the box. Still, let's not get ahead of ourselves, maybe this functionality can be implemented in a more straight-forward way.

[mfonism]

No, those sorts of lookups don't work for these fields in this implementation.

One way to make them work would be to transform query in this manner:

for key, val in query.items():
    if not key.startswith(
        ("setup_duration", "testing_duration", "expected_duration")
    ):
        continue

    try:
        duration = parse_duration(val)
    except TypeError:
        # val isn't a string or byte-like object
        # item is probably something like 'setup_duration__isnull=True'
        continue

    if duration is None:
        # parsing duration didn't work, leave the item (key, val) as is
        continue

    query[key] = duration

[atodorov]

ATM I'm not sure I like this approach. Let's agree on how the widget portion will work/look like and then we can go back to the API portion and decide what to do.