[AIRFLOW-2799] Fix filtering UI objects by datetime#4061
Conversation
|
@jgao54 @mistercrunch If either of you have time to check on the FAB changes I made here that would be good - it works, but I'm not 100% sure its the best way. Also somewhat annoyingly there seems to be no easy way in a filter to validate the input, so right now if you give an invalid DateTime (one that cannot be parsed) it will throw a 500 instead of a nice message. There doesn't seem to be a |
2a58318 to
06f72d2
Compare
Codecov Report
@@ Coverage Diff @@
## master #4061 +/- ##
==========================================
+ Coverage 75.91% 76.05% +0.14%
==========================================
Files 199 199
Lines 15961 15999 +38
==========================================
+ Hits 12116 12168 +52
+ Misses 3845 3831 -14
Continue to review full report at Codecov.
|
f2694b0 to
4e5bee9
Compare
|
@ebrard Tests are green now (helps if I actually hit enter on the terminal where I wrote |
|
@bolkedebruin PTAL |
|
Hi, @jgao54 can you review this one too please? |
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
4e5bee9 to
b31db26
Compare
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Our conversion to Timezone-aware date times in 1.10 missed this case - any filter on a date time would blow up with `naive datetime is disallowed` - this makes our datetime filters timezone aware now (they respect the default_timezone, and they accept timezones in input even though the UI won't let you craft those.) I manually tested this by changing query parameters - a value of `2018-10-30+01%3A05%3A00%2B01:00` matched against an execution date of 00:05:00+00:00
Make sure you have checked all steps below.
Jira
Description
any filter on a date time would blow up with
naive datetime is disallowed- this makes our datetime filters timezone aware now (theyrespect the default_timezone, and they accept timezones in input even
though the UI won't let you craft those.)
Tests
Commits
Documentation
Code Quality
flake8