7 years have passed, but there is still no filter (next month).
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Redmine 4.0.0 has "yesterday", "last week", and "last month" filter but does not "tomorrow", "next week", and "next month" filter.

I think those filters should be useful for many users.
--------------------------------------------------------------------------------
Go MAEDA wrote:
> Redmine 4.0.0 has "yesterday", "last week", and "last month" filter but does not "tomorrow", "next week", and "next month" filter.
>
> I think those filters should be useful for many users.

I wrote a patch to add "tomorrow", "next week", and "next month" filter.
It is useful to have this filter when checking the tasks to be executed next month, next week, tomorrow.
--------------------------------------------------------------------------------
I fixed patch because unnecessary tests were included.
--------------------------------------------------------------------------------
LGTM
--------------------------------------------------------------------------------
Setting the target version to 4.1.0.

I propose reordering the operators as follows. While the current patch shows operators in "present -> past -> future" order, my change shows operators in "future -> present -> past" order. For example, operators will be ordered like "tomorrow, today, yesterday" and "next week, this week, last week, last 2 weeks" instead of "today, yesterday, tomorrow" and "this week, last week, last 2 weeks, next week". The proposing order is a tidy reverse-chronological order and should be intuitive.

<pre><code class="ruby">
:date => [ "=", ">=", "<=", "><", "<t+", ">t+", "><t+", "t+", "nd", "t", "ld", "nw", "w", "lw", "l2w", "nm", "m", "lm", "y", ">t-", "<t-", "><t-", "t-", "!*", "*" ],
</code></pre>

!{width: 160px;}.operators@2x.png!
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Committed the patch. Thank you for improving Redmine.

I changed the order or operators and added Japanese translation.
--------------------------------------------------------------------------------
QueryTest#test_operator_tomorrow fails depending on timezone.

I could reproduce the problem at 22:21 HST (Hawaii Standard Time -1000, 08:21 UTC). Maybe the problem occurs if the local date is different from the UTC date.

<pre>
$ date
Fri Jan 18 22:21:34 HST 2019
$ ruby test/unit/query_test.rb
Run options: --seed 35057

# Running:

.................................................................................................................F

Failure:
QueryTest#test_operator_tomorrow [test/unit/query_test.rb:645]:
Expected false to be truthy.

bin/rails test test/unit/query_test.rb:641

...............................................................................................

Finished in 22.371776s, 9.3421 runs/s, 26.4619 assertions/s.
209 runs, 592 assertions, 1 failures, 0 errors, 0 skips
</pre>
--------------------------------------------------------------------------------
The current date of my PC is 2019-01-18 HST (2019-01-19 UTC).

QueryTest#test_operator_tomorrow expects that there are some issues whose due date is tomorrow (2019-01-19). However, there are issues whose due date is the day after the tomorrow (2019-01-20).

<pre>
sqlite> select id, due_date from issues;
id due_date
---------- ----------
1 2019-01-29
2
3 2019-01-14
4
5
6 2019-01-20
7 2019-01-18
8
9 2019-01-20
10 2019-01-20
11
12
13
14
</pre>

Probably the reason is that the timezone of fixtures is UTC. @1.days.from_now.to_date.to_s(:db)@ returns a date in UTC (2019-01-20), while the test code expects 2019-01-19 that is the date of tomorrow in the local time (the current date of the local time is still 2019-01-18 HST).

<pre>
issues_006:
created_on: <%= 1.minute.ago.to_s(:db) %>
project_id: 5
updated_on: <%= 1.minute.ago.to_s(:db) %>
priority_id: 4
subject: Issue of a private subproject
id: 6
fixed_version_id:
category_id:
description: This is an issue of a private subproject of cookbook
tracker_id: 1
assigned_to_id:
author_id: 2
status_id: 1
start_date: <%= Date.today.to_s(:db) %>
due_date: <%= 1.days.from_now.to_date.to_s(:db) %>
root_id: 6
lft: 1
rgt: 2
</pre>

The date of fixtures are UTC, I think we have to run the test in UTC. The following workaround resolves the failing test.

<pre><code class="diff">
Index: test/unit/query_test.rb
===================================================================
--- test/unit/query_test.rb (revision 17811)
+++ test/unit/query_test.rb (working copy)
@@ -639,11 +639,13 @@
end

def test_operator_tomorrow
+ User.current = User.find_by_login('admin')
+ User.current.pref.update_attribute :time_zone, 'UTC'
query = IssueQuery.new(:project => Project.find(1), :name => '_')
query.add_filter('due_date', 'nd', [''])
issues = find_issues_with_query(query)
assert !issues.empty?
- issues.each {|issue| assert_equal Date.today.tomorrow, issue.due_date}
+ issues.each {|issue| assert_equal User.current.today.tomorrow, issue.due_date}
end

def test_operator_date_periods
</code></pre>
--------------------------------------------------------------------------------
Go MAEDA wrote:
> QueryTest#test_operator_tomorrow fails depending on timezone.
>
>
> I could reproduce the problem at 22:21 HST (Hawaii Standard Time -1000, 08:21 UTC). Maybe the problem occurs if the local date is different from the UTC date.

Thank you for pointing that out.

The attached patch updates the #4502#note-13 test to fix the random failure.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Closed,4729,Add Date-Based Filters for Issues List
relates,Closed,6954,Filter from date to date
relates,Closed,18868,Add support for queries with 'next week' filter