Project

General

Profile

Spent time report shows incorrect days for filters of This month or Is date if data migrated from a previous version of Redmine

Added by Ed Howland over 2 years ago

Hi,

I am having a problem updating an existing Redmine installation to the latest version: 4.2.1.
The existing version is something in the 0.x.x era around 2008, 2009 timeframe.
The only concrete data point I have is that it was current upto migration 092.
We managed to get the remaining migrations to run on the existing data after
some small change to the order of the migration scripts, but now we are experiencing a strange date/time problem with the Spent time report.

First, let me explain the baseline installation which works correctly, AFAIK.
Both the baseline and the production environments are using the Docker redmine:4.2.1 images
from DockerHub. The entire stack is spun up using a slightly modified docker-compose.yml
file from the DockerHub info page for Redmine. It consists of 2 containers:
mysql:5.7 and redmine:4.2.1

With that background, I 'docker-compose up -d' and let all the db/migrate scripts
run. After the logs state that WebRICK is listening on internal port 300 (mapped to external port 8080).
I log into the web interface and go thru the initialization steps.
Once that is done, I create a test project, a test issue and then log time on it.
The problem I am trying to replicate here in the baseline instance is the followin:g:
Enter a log time entry with the date of the first of the month (June 1 or July 1).
Create another entry with any date later in the same month. (I use June 2nd and July 2nd)
Then go to the spent time report. Click on the filter group and check the box: Date and select either "Last month" or "This month"
Then click on Apply. You should get a table with 2 entries, one for each day in the chosen month.

This works correctly in the baseline instance. However, when I try the same with
the migrated data from the previous 0.x.x Redmine installation, I get the following
symptons:
The This month query results in
1 entry, the 2nd of the month entry. However, if you have entered all 4 of the test
entries "06/02,06/02,07/01 and 07/02 and select " "Last month",
you get two entries: 06/02 and 07/01. Note you should get 06/01 and 06/02. And the
"This month" choice nets you 1 entry: 07/02, where you should get 07/01 and 07/02.
Note: other filter choices have the similar behaviour. E.g. "Last week", if you use Sunday, Monday instead of the first and second of the month.
And if you choose the "Is" choice, all dates are always off by 1 day.
E.g.: 2021-06-01 should be 2021-06-01 but becomes 2021-06-02 and 2021-06-02
is empty. However, if you enter 2021-06-30,, you get 2021-07-01.
Other information: The structure of the database, i.e. its schema matches between
the baseline and the migrated database version, as evidenced by running diff
between the db/schema.rb files between both instances.
Also, the data in the MySQL time_entries looks correct to me. I can perform
a SELECT query using a between clause on the spent_on field and get correct results
between both instances. Further, launching Rails console
and performing a .where query achieves the same correct results on both the baseline and migrated instances.
As far as I can tell, the only difference between baseline and migrated instances
is the actual imported data. What that means, I cannot imagine.
Also note that I created another test project in the migrated data instance,
to eliminate any influence from data stored by existing projects.
What I haven't been able to do is to capture the actual db query that is being
constructed by the report form. Is there some way to simulate the report
in the Rails console given only those parameters I mentioned above?
Any suggestions would be helpful.

Thanks, Ed.


Replies (2)

RE: Spent time report shows incorrect days for filters of This month or Is date if data migrated from a previous version of Redmine - Added by Ed Howland over 2 years ago

Thanks for the version number. Is there a way to see that in the web interface? Or in the source code itself.

- Ed

    (1-2/2)