View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015320 | mantisbt | filters | public | 2012-12-26 11:21 | 2014-09-23 18:05 |
Reporter | atrol | Assigned To | rombert | ||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.12 | ||||
Target Version | 1.2.13 | Fixed in Version | 1.2.13 | ||
Summary | 0015320: Date filters broken since 1.2.12 | ||||
Description | Date filters are not working since version 1.2.12 | ||||
Steps To Reproduce | 1) Goto "View Issues" page --> No issues are listed | ||||
Additional Information | Values for status and date are mixed | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Reminder sent to: rombert Could you please check your commit to fix 0014737 ? |
|
That's a nasty regression and a good catch. The attached patch seems to fix it for me, can you confirm that it does the right thing? filterapi-apply-all-projectwhereclauses-first.patch (2,965 bytes)
From 09382b007a62ae6a945dfdcf0d33f00b896a3c3a Fri, 4 Jan 2013 23:58:38 +0200 From: Robert Munteanu <robert@lmn.ro> Date: Fri, 4 Jan 2013 23:57:59 +0200 Subject: [PATCH] filter_api: apply all project_where_clauses first where_clauses and project_where_clauses must not be mixed, since the where_params are expected to be held in order - first for the project_where_clauses and then for the where_clauses. Fixes #15320: Date filters broken since 1.2.12 diff --git a/core/filter_api.php b/core/filter_api.php index 71254ac..2286ff0 100644 --- a/core/filter_api.php +++ b/core/filter_api.php @@ -1239,6 +1239,17 @@ log_event( LOG_FILTERING, 'project query = ' . $t_project_query ); array_push( $t_project_where_clauses, $t_project_query ); } + + # date filter + if(( 'on' == $t_filter[FILTER_PROPERTY_FILTER_BY_DATE] ) && is_numeric( $t_filter[FILTER_PROPERTY_START_MONTH] ) && is_numeric( $t_filter[FILTER_PROPERTY_START_DAY] ) && is_numeric( $t_filter[FILTER_PROPERTY_START_YEAR] ) && is_numeric( $t_filter[FILTER_PROPERTY_END_MONTH] ) && is_numeric( $t_filter[FILTER_PROPERTY_END_DAY] ) && is_numeric( $t_filter[FILTER_PROPERTY_END_YEAR] ) ) { + + $t_start_string = $t_filter[FILTER_PROPERTY_START_YEAR] . "-" . $t_filter[FILTER_PROPERTY_START_MONTH] . "-" . $t_filter[FILTER_PROPERTY_START_DAY] . " 00:00:00"; + $t_end_string = $t_filter[FILTER_PROPERTY_END_YEAR] . "-" . $t_filter[FILTER_PROPERTY_END_MONTH] . "-" . $t_filter[FILTER_PROPERTY_END_DAY] . " 23:59:59"; + + $t_where_params[] = strtotime( $t_start_string ); + $t_where_params[] = strtotime( $t_end_string ); + array_push( $t_project_where_clauses, "($t_bug_table.date_submitted BETWEEN " . db_param() . " AND " . db_param() . " )" ); + } # view state $t_view_state = db_prepare_int( $t_filter[FILTER_PROPERTY_VIEW_STATE_ID] ); @@ -1616,17 +1627,6 @@ $t_where_params[] = $t_clauses[0]; array_push( $t_where_clauses, "( $t_bug_table.os_build = " . db_param() . " )" ); } - } - - # date filter - if(( 'on' == $t_filter[FILTER_PROPERTY_FILTER_BY_DATE] ) && is_numeric( $t_filter[FILTER_PROPERTY_START_MONTH] ) && is_numeric( $t_filter[FILTER_PROPERTY_START_DAY] ) && is_numeric( $t_filter[FILTER_PROPERTY_START_YEAR] ) && is_numeric( $t_filter[FILTER_PROPERTY_END_MONTH] ) && is_numeric( $t_filter[FILTER_PROPERTY_END_DAY] ) && is_numeric( $t_filter[FILTER_PROPERTY_END_YEAR] ) ) { - - $t_start_string = $t_filter[FILTER_PROPERTY_START_YEAR] . "-" . $t_filter[FILTER_PROPERTY_START_MONTH] . "-" . $t_filter[FILTER_PROPERTY_START_DAY] . " 00:00:00"; - $t_end_string = $t_filter[FILTER_PROPERTY_END_YEAR] . "-" . $t_filter[FILTER_PROPERTY_END_MONTH] . "-" . $t_filter[FILTER_PROPERTY_END_DAY] . " 23:59:59"; - - $t_where_params[] = strtotime( $t_start_string ); - $t_where_params[] = strtotime( $t_end_string ); - array_push( $t_project_where_clauses, "($t_bug_table.date_submitted BETWEEN " . db_param() . " AND " . db_param() . " )" ); } # fixed in version |
|
The patch seems to fix it. IMO the new match type "Any Conditions" is sometimes a bit confusing because a user does not know which field is considered mandatory (AND) and which one is not (OR) The most confusing field with "Any Conditions" match type when using simple filters is "Hide Status". |
|
That's a good point, I'll add the ui comments to issue 0014736 |
|
Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch |
|
MantisBT: master f39ff7be 2013-01-04 16:57 Details Diff |
filter_api: apply all project_where_clauses first where_clauses and project_where_clauses must not be mixed, since the where_params are expected to be held in order - first for the project_where_clauses and then for the where_clauses. Fixes 0015320: Date filters broken since 1.2.12 |
Affected Issues 0015320 |
|
mod - core/filter_api.php | Diff File | ||
MantisBT: master-1.2.x 1338525b 2013-01-04 16:57 Details Diff |
filter_api: apply all project_where_clauses first where_clauses and project_where_clauses must not be mixed, since the where_params are expected to be held in order - first for the project_where_clauses and then for the where_clauses. Fixes 0015320: Date filters broken since 1.2.12 |
Affected Issues 0015320 |
|
mod - core/filter_api.php | Diff File |