-
-
Notifications
You must be signed in to change notification settings - Fork 296
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
(api) Make duration fields available as filters in the /cases/search/ page #2558
base: master
Are you sure you want to change the base?
Conversation
40e85d2
to
6b557fe
Compare
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.
Added some comments and some changes requested.
{{ form.expected_duration }} | ||
</div> | ||
</div> | ||
</div> |
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.
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.
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.
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.
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.
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.
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.
OK, let's see how it will look like. Just remember - keep it simple as much as possible.
if query is None: | ||
query = {} | ||
|
||
if "setup_duration" in query: | ||
query["setup_duration"] = parse_duration(query["setup_duration"]) |
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.
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.
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.
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
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.
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.
Refs #1923
Without filtering on any duration field
Filtering on expected duration