Patch #1650

Start/end time tracking for timelogging

Added by Artem Vasiliev over 9 years ago. Updated almost 2 years ago.

Status:NewStart date:2008-07-15
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Time tracking
Target version:-

Description

This is an implementation of http://www.redmine.org/boards/1/topics/show/1027.
Patch is made against current HEAD (r1669).

Workflow is somewhat revised with me and Anna (we work together):
  • Time entry form now has 2 new datetime fields, Start Time and End Time (see attached screenshot). They have buttons Now which fills relevant field with current time if it's empty.
  • Hours field made not required but at least one of (Start Time, Hours) is required to be filled. If Start Time is filled and Hours is not entry is considered to be In Progress.
  • Log Time link loads current In Progress time entry (if any) for current user
  • Same goes for Issue Edit form as it also has Log Time fields group
  • If both Start Time and End Time are set and Hours is not Hours get calculated on Save
  • if entered manually Hours is not validated to be equal to (End Time - Start Time) - user may wish to specify that he worked time to time from 11:00 to 15:00, but that made only 1 hour of continuous time
  • After time entry saving flash notice contains links to other time entries by the same user that intersect with saved one

Relevant translations for English and Russian are included; for the rest languages there are English stubs.
Tests are included.

Also the patch contains test utility rake rules file (vendor/plugins/test_utils/tasks/test_utils.rake) that allows to run only one or several tests from a file, e.g.

rake u_time_entry-find

runs test_find* test cases from unit/time_entry_test.rb;

rake f_issues-show_in_progress

runs test_show_in_progress test case from functional/issues_controller_test.rb

It's developed as a plugin in my company, Texuna Technologies, and distributed under MIT license.
This is not directly related to the patch but seems to be exteremely useful so I couldn't stand including it. Feel free to remove it anyway.

timelogging.patch Magnifier - the patch (62.4 KB) Artem Vasiliev, 2008-07-15 18:35

timelogging.PNG - screnshot of updated Time Entry form (57 KB) Artem Vasiliev, 2008-07-15 18:36

timelogging.patch Magnifier (33.5 KB) Riccardo Delpopolo, 2009-03-19 13:36

timelogging-r2641.patch Magnifier - Patch rebased against trunk at r2641 (34 KB) Mischa The Evil, 2009-03-30 04:04


Related issues

Related to Redmine - Feature #440: Time tracking stopwatch New
Related to Redmine - Defect #5892: Changing status from contextual menu opens the ticket ins... Closed 2010-07-16

History

#1 Updated by Artem Vasiliev over 9 years ago

#2 Updated by Artem Vasiliev over 9 years ago

Notice that you might want to apply the patch at Windows machine via TortoiseSVN. It applies it just fine without any errors, while trying to apply the patch with 'patch -p0 file' on Linux gives me 3 errors like this:

patching file redmine/app/views/timelog/edit.rhtml
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file redmine/app/views/timelog/edit.rhtml.rej

I tried 'diff -Nur' patch approach with the same result. The most sane solution in my case was to apply the patch on Windows and then move zip of the whole patched dir to Linux machine.

#3 Updated by Artem Vasiliev over 9 years ago

#1705 is needed to be applied for this patch to work in geographically distributed environment (user in one time zone, Redmine in another)

#4 Updated by Mischa The Evil over 9 years ago

Patch #1650

Start/end time tracking for timelogging

Great patch I must say. I really like the approach this patch takes.

Now I've merged it with my personal branch (contains trunk @1745) doing some manual edits to resolve some minor conflicts I've got it running like described.
Though, I think I have just found one small error in the patch:

  • The intersection-links, which are rendered while I recieve a flashnotice of an intersection, are missing the project-component. The correct url should be like:
    http://xxx.xxx.xxx/projecta/timelog/edit/1
    
    though it is now generated as:
    http://xxx.xxx.xxx/timelog/edit/1

I've already tracked it down to this snippet in the timelog_controller (../app/controllers/timelog_controller.rb):

    url_writer = lambda do |entry| 
      "<a href = \"#{url_path(:controller => :timelog, :action => :edit, :id => entry.id)}\">##{entry.issue_id}-#{entry.id}</a>" 
    end

At the moment I don't know precisely how to correct this code, to make the controller generate the correct URL's, due to my very-short time of basic experience with Ruby, RoR, Redmine.

I'll try to find my way around this... :-)

#5 Updated by Artem Vasiliev over 9 years ago

Mischa The Evil wrote:

Great patch I must say. I really like the approach this patch takes.

Thanks man!

Though, I think I have just found one small error in the patch:

though it is now generated as: http://xxx.xxx.xxx/timelog/edit/1

Well, why do you think time entry url without project component is an error? It works fine because entry IDs are cross-project (it's plain artificial PK as usual in RoR).

#6 Updated by Mischa The Evil over 9 years ago

At first thanks for the quick reply...

Artem Vasiliev wrote:

Mischa The Evil wrote:

Though, I think I have just found one small error in the patch:

though it is now generated as: http://xxx.xxx.xxx/timelog/edit/1

Well, why do you think time entry url without project component is an error? It works fine because entry IDs are cross-project (it's plain artificial PK as usual in RoR).

Ok, I have to revise my "error-report" to be correct after looking at the problem with a clear mind...

I am running Redmine (on Apache + REE + Passenger) in a sub-URI of a domain (so xxx.xxx.xxx is home and xxx.xxx.xxx/redmine is where my Redmine is located).
After looking at my error again I notice that it is not missing any project-part in the URL (since, like you have stated before it works using the entry-ID's and not with project-ID's) but it is missing the sub-URI in the URL's of the intersection-links.

That would mean that url_path is returning only the host.domain.tld-part of the URL without passing any sub-URI.

I'll do some more research on this myself either...

#7 Updated by Artem Vasiliev over 9 years ago

Mischa The Evil wrote:

That would mean that url_path is returning only the host.domain.tld-part of the URL without passing any sub-URI.

That's interesting, and strange, as url_path just asks ::ActionController::Routing::Routes to generate the URL. Please tell if you find the cause of (or the solution to :) this.

#8 Updated by Mischa The Evil over 9 years ago

Artem Vasiliev wrote:

Please tell if you find the cause of (or the solution to :) this.

After several hours (again) of bug-hunting, code observation and reinterpretation, and trial-and-error-ing I have given up this issue.
It is not possible for me (according to my current knowledge of Ruby on Rails) to fix this error myself in near future.

Also due to some earlier problems I had running apps on sub-uri's I am now going to switch to my backup deployment paper. I'll now move the RoR-apps into seperated and dedicated vhosts.
I already lost too much time on fixing errors with apps installed in a sub-uri of a vhost (incl. other RM-instances).

I'll see in future if such an setup will become possible without problems, for now I'll drop it.

@Artem: My earlier conclusion still holds though: "Great patch!". I even switch (lightweight) deployement architecture for it.. :)

#9 Updated by Artem Vasiliev over 9 years ago

Mischa The Evil wrote:

Also due to some earlier problems I had running apps on sub-uri's I am now going to switch to my backup deployment paper. I'll now move the RoR-apps into seperated and dedicated vhosts.
I already lost too much time on fixing errors with apps installed in a sub-uri of a vhost (incl. other RM-instances).

I guess that's much more popular environment, may be there are just some bugs in RoR when it's used in sub-uri environment.

@Artem: My earlier conclusion still holds though: "Great patch!". I even switch (lightweight) deployement architecture for it.. :)

Thanks again, very nice to hear! )
Be sure to check #1705 if you are working in timezone-distributed environment.

#10 Updated by Mischa The Evil over 9 years ago

After a while of using my vendor-branch including this patch I found another issue regarding this patch...

When using context-menu (right-click menu) in the issuelist, every change (even a more simpler priority-change) initiated through an action selected from the context-menu, brings me to the edit view for the issue showing me two errors saying:
  1. « Project » is invalid
  2. « Date » can't be blank

In this view the requested changes are preselected. When I now click submit the change gets applied though without any problems.

It looks like, if using the context-menu, those two parameters aren't passed to the controller somehow...

What can be the cause or solution of this side-effect?

#11 Updated by Artem Vasiliev over 9 years ago

Mischa The Evil wrote:

After a while of using my vendor-branch including this patch I found another issue regarding this patch...

When using context-menu (right-click menu) in the issuelist, every change (even a more simpler priority-change) initiated through an action selected from the context-menu, brings me to the edit view for the issue showing me two errors saying:
  1. « Project » is invalid
  2. « Date » can't be blank

Hm, looks strange to me. In our version of Redmine having this patch applied this works fine without any error messages, I've just tried it. And I don't remember fixing this :) Sorry, no clue.

#12 Updated by Mischa The Evil over 9 years ago

Artem Vasiliev wrote:

In our version of Redmine having this patch applied this works fine without any error messages, I've just tried it.

What exact version of Redmine are you running? Then I'll search through following revisions for changes to the issue-controller to try to find the change of validation...

#13 Updated by Artem Vasiliev over 9 years ago

Mischa The Evil wrote:

Artem Vasiliev wrote:

In our version of Redmine having this patch applied this works fine without any error messages, I've just tried it.

What exact version of Redmine are you running? Then I'll search through following revisions for changes to the issue-controller to try to find the change of validation...

We run r1694 of http://redmine.rubyforge.org/svn/trunk

#14 Updated by Mischa The Evil over 9 years ago

Ok, after some thorough research and testing I think I have found the cause of the reported anomaly regarding the context-menu;

While updating my test-setup revision by revision (with and without the patch) I first noticed that the error started to show-up after applying r1689.

In r1689 timelog custom-fields are introduced.
It is that revision which adds a new line 163 to the edit-method in ../app/controllers/issues_controller.rb which looks like:

   @time_entry = TimeEntry.new

Now if I run a patched (this patch only) instance of r1689 while commented-out the above mentioned new line I don't get the earlier mentioned errors while using the context-menu to modify an issue's priority. This result confirms my suspicion that it is indeed that line which causes the 2 errors.

Artem Vasiliev wrote:

In our version of Redmine having this patch applied this works fine without any error messages, I've just tried it.

We run r1694 of http://redmine.rubyforge.org/svn/trunk

With the info I have posted above in the back of my mind, I am quite curious how the file ../app/controllers/issues_controller.rb looks in your deployment. If it is indeed the line I mentioned which is causing the errors than it looks most likely that you've modified the file after posting the patch here.

I also compared the changes from your patch against the mentioned line to see if I could apply the patch'es changes onto that single line but I couldn't get it right... Though I see that your patch changes/extends more than once lines containing a TimeEntry.new-part.

Would it be possible for you to maybe update the patch for (full) compatibility with > r1689 or post the related snippet of ../app/controllers/issues_controller.rb from your deployment of r1694?

Thanks in advance also for your great support upto now... :)

#15 Updated by Artem Vasiliev over 9 years ago

Wow! Hats off to your investigation effort, and it's surprising to find myself in the middle of detective story )

In r1689 timelog custom-fields are introduced.
It is that revision which adds a new line 163 to the edit-method in ../app/controllers/issues_controller.rb which looks like:
@time_entry = TimeEntry.new

Same in our code! Now I tried this for issue without spent time history, and it does complain, though only about Time field. With some spent time log like yesterday was the case, everything was fine.
So, after timelogging was introduced we have such problem. I'll look at it more closely later.

Thanks for commenting whith some source code - this is important for us hungry code-eaters!

#16 Updated by Mischa The Evil over 9 years ago

Re (offtopic)

Artem Vasiliev wrote:

Hats off to your investigation effort

Thanks :)

Artem Vasiliev wrote:

Thanks for commenting whith some source code - this is important for us hungry code-eaters!

Your welcome. I'm willing to help as much as I can. Though it's sometimes difficult for me to catch-up the skills since I only have some more basic knowledge of structural PHP... :)
But, reading and trying to interpret other's code is a great way of leaning RoR to the skill I'd prefer myself to have...

It's also a hobby, curiosity... I want to know what happens at which time... And like I said earlier: I really like this patch.
It is the only feature I am really missing in the core. Imho the time-tracking functionalities are there to track my spent time not only to collect my individual calculations of how long I worked in total on an issue.
When I'm 'working' on an issue I don't want to keep track of exact (in minutes) time of starting and ending. When I start working on an issue it is much more natural to 'inform' the tracking-system: "I'm started working on issue xxx!" or "I'm done working on this issue for now/this activity/this ..." than to 'post-log' the amount of time I've worked on an issue.
Besides the fact that this patch provides the above described start-/endtime functionality, it also maintains the flexibility of still being able to log time "manually".
Plus it adds some small, but quite neat features like:
  • time in-progress status (which I'd love to see extended with filters for issuelist - I understand that such things shouldn't be done using generic patches -> severity is too high imho)
  • Log Time link loads current In Progress time entry (if any) for current user
  • Same goes for Issue Edit form as it also has Log Time fields group
  • Intersection links

This all makes this patch a kind of requirement for me to be able to do what I want using Redmine. It's a key feature to me.. :-)

Continuation and temporarily final of the detective story (ontopic)

Now, I'll finish my detective story with this post for the mean time :-)

Mischa The Evil wrote:

Now if I run a patched (this patch only) instance of r1689 while commented-out the above mentioned new line I don't get the earlier mentioned errors while using the context-menu to modify an issue's priority.

This change does trigger also a side-effect which is doing more bad than good; it causes timelogs with zero hours (0.0) [issue #1147] to be created while updating an issue using the context-menu.

This behaviour made me thinking: everytime I manually update an issue the timelog hour field is default filled with 0.0 due to config of the DB. I have to manually remove it everytime I update the issue without adding a time-entry. Now it is written down as an empty timelog while updating using the context-menu.
That led me to the conclusion that the earlier mentioned line is there (logical since it is defined in the edit-method) to make sure that no timelog is created while an issue is updated via an action triggered from the context-menu.

Artem Vasiliev wrote:

Now I tried this for issue without spent time history, and it does complain, though only about Time field.

This distinction makes it even more difficult to find the exact cause of these errors :S

Artem Vasiliev wrote:

So, after timelogging was introduced we have such problem.

I now have isolated the cause of the error to revision r1689 indeed (plus the related revisions r1690 & r1691).
I've now reverted these revisions (and these revisions only) manually on a fresh checkout of the trunk at r1745 - in fact undoing all the changes made for the implementation of timelog custom fields - which solves the caused errors.
It works flawlessly after those changes (though I loose the support for this type of custom fields). It's actually quite easy to do...

Artem Vasiliev wrote:

I'll look at it more closely later.

That would be great! It would be superb if this patch could be kept/made "compatible" against more recent trunk untill comparable features are added to the Redmine core.
Though it's not a major issue for me now since it is still possible to revert the timelog custom field without creating hugh conflicts. Since I'm (currently) not using timelog custom fields I've chosen to stick with that solution for the time being. The provided functionality of this patch is more important to me than the ability to use custom fields for timelogs.

Again: thanks for all the help and support...

#17 Updated by Mischa The Evil over 9 years ago

Mischa The Evil wrote:

Mischa The Evil wrote:

Now if I run a patched (this patch only) instance of r1689 while commented-out the above mentioned new line I don't get the earlier mentioned errors while using the context-menu to modify an issue's priority.

This change does trigger also a side-effect which is doing more bad than good; it causes timelogs with zero hours (0.0) [issue #1147] to be created while updating an issue using the context-menu.

This has nothing to do with the change of commenting-out that line. See my note on issue #1147.

This behaviour is probably created by this patch with that line commented-out or not...

Artem, could you please test this (lookup for 0.00 timelogs) and report back here?

#18 Updated by Artem Vasiliev over 9 years ago

Mischa The Evil wrote:

I want to know what happens at which time... And like I said earlier: I really like this patch.
It is the only feature I am really missing in the core. Imho the time-tracking functionalities are there to track my spent time not only to collect my individual calculations of how long I worked in total on an issue.
When I'm 'working' on an issue I don't want to keep track of exact (in minutes) time of starting and ending. When I start working on an issue it is much more natural to 'inform' the tracking-system: "I'm started working on issue xxx!" or "I'm done working on this issue for now/this activity/this ..." than to 'post-log' the amount of time I've worked on an issue.
Besides the fact that this patch provides the above described start-/endtime functionality, it also maintains the flexibility of still being able to log time "manually".
Plus it adds some small, but quite neat features like:
  • time in-progress status (which I'd love to see extended with filters for issuelist - I understand that such things shouldn't be done using generic patches -> severity is too high imho)
  • Log Time link loads current In Progress time entry (if any) for current user
  • Same goes for Issue Edit form as it also has Log Time fields group
  • Intersection links

This all makes this patch a kind of requirement for me to be able to do what I want using Redmine. It's a key feature to me.. :-)

Thanks Mischa! That's also exactly why we did this patch :) Glad to see that someone understood this feature so well.

#19 Updated by Artem Vasiliev over 9 years ago

Mischa The Evil wrote:

This change does trigger also a side-effect which is doing more bad than good; it causes timelogs with zero hours (0.0) [issue #1147] to be created while updating an issue using the context-menu.

This has nothing to do with the change of commenting-out that line. See my note on issue #1147.

This behaviour is probably created by this patch with that line commented-out or not...

Artem, could you please test this (lookup for 0.00 timelogs) and report back here?

Thanks for the link! I'm glad you noticed the issue was gone with r1773. We're going to publish our Redmine fork at GitHub, and rebase it against latest trunk. This will hopefully make future rebasings against Redmine trunk easier.
Also you'll be welcome to try our other changes to Redmine, like diffs for issue descriptions (#1717) and remaining time calculation for version (#1671). Our future Redmine development is going to be in GitHub, duplicated by SVN patches.

#20 Updated by Artem Vasiliev over 9 years ago

Artem Vasiliev wrote:

We're going to publish our Redmine fork at GitHub, and rebase it against latest trunk. This will hopefully make future rebasings against Redmine trunk easier.

Allright, here it is: http://github.com/artemv/redmine_tt/tree/master. You can use 'download' link or use git client.

This is basically what we use, but upgraded to r1778. I tried changing issue priority by context menu in issue list - works like a charm, and no zero timelog entry created.

Our version appears to have some unit tests broken, I going to look at that. More development to come soon, first we're going to improve #1671 (resolved issues shouldn't add to 'remaining' time in our opinion).

Looks like we need to move this thread to forums..

#21 Updated by Mischa The Evil over 9 years ago

Artem Vasiliev wrote:

Allright, here it is: http://github.com/artemv/redmine_tt/tree/master.

Great!!! Thanks for the taken actions to further develop your (TT's) Redmine fork in a public git-repo...

Artem Vasiliev wrote:

Looks like we need to move this thread to forums..

I just created a new forum-thread as a continuation of the discussion here regarding the patch & as an extension to the discussion regarding other changes in the fork by TT.

#22 Updated by Riccardo Delpopolo about 9 years ago

Will this patch applied to the trunk???
Can i eventually add them to the trunk?

#23 Updated by Riccardo Delpopolo about 9 years ago

Wold be useful to have a list of started spent time.

#24 Updated by Jase Roberts almost 9 years ago

We've just started using Redmine in our web shop, and also would really like to see this feature be officially implemented in the trunk. Discussion on this is currently fragmented here, plus:
Patch: http://www.redmine.org/issues/show/1650
Patch/fork discussion: http://www.redmine.org/boards/1/topics/show/2352
Idea for feature: http://www.redmine.org/boards/1/topics/show/1027

Having only skimmed these latter three, I'm not completely clear on the status of the patch (but very much appreciate the effort that has gone into it). Would be great to see this in trunk. We're currently also using SlimTimer, but repetition of data entry is a pain and prone to error.

#25 Updated by Artem Vasiliev almost 9 years ago

Thanks Jase!

And you see, it also supports #1671 (Show a breakdown of estimated/spent/remaining time for a version) quite well: for #1671 it's crucial to have spent time carefully entered for tickets, and if you forgot to enter spent time at some point it's much easier to remember how much did you miss if you have start/end times and view on person's spent time during the day showing it in right order.

Best regards,
Artem

We've just started using Redmine in our web shop, and also would really like to see this feature be officially implemented in the trunk. Discussion on this is currently fragmented here, plus:
Patch: http://www.redmine.org/issues/show/1650
Patch/fork discussion: http://www.redmine.org/boards/1/topics/show/2352
Idea for feature: http://www.redmine.org/boards/1/topics/show/1027

Having only skimmed these latter three, I'm not completely clear on the status of the patch (but very much appreciate the effort that has gone into it). Would be great to see this in trunk. We're currently also using SlimTimer, but repetition of data entry is a pain and prone to error.

#26 Updated by Petr Cervenka almost 9 years ago

+1 for some support for 3rd party software (SlimTimer or Any other Desktop/Wep Application) which can update/modify spend time on various tickets.

That would be awesome,
Petr

#27 Updated by Riccardo Delpopolo almost 9 years ago

I've modified the patch to work with the r2594
Where can i upload it?

#28 Updated by Artem Vasiliev almost 9 years ago

Riccardo Delpopolo wrote:

I've modified the patch to work with the r2594
Where can i upload it?

Cool!
Uploading patch here is fine for me; also consider making a separate branch at GitHub (clone http://github.com/edavis10/redmine/tree/master) for this patch like Eric Davis suggested here - this will ease the integration of the patch to Redmine trunk. Please post the link here if you do.

Best regards,
Artem

#29 Updated by Riccardo Delpopolo over 8 years ago

Please, check it, because i've modified it by hand.
I've applied this patch to a fresh r2594 with an old database.
I had only a problem patching two files, so i did the modify by hand.

I've also modificed the references to the deprecated lws function to l_hours

It's my first patch and very new to rubyonrails :)
So if you can, help me if i was wrong, and give me some resources where to learn

#30 Updated by Riccardo Delpopolo over 8 years ago

It should be ok :)
Try it and make me know if it's ok

http://github.com/RDelpopolo/redmine/tree/tt

#31 Updated by Mischa The Evil over 8 years ago

Riccardo Delpopolo wrote:

Try it and make me know if it's ok

http://github.com/RDelpopolo/redmine/tree/tt

Riccardo, I've tested your patchfile (manually applied the changes) against Redmine trunk at r2641 but it seems it's becoming hopelessly broken by now:
  • Missing proper translations for Rails 2.2.2
  • Intersection links aren't caught any longer
  • Sorting on the start/end times is broken in the timelog report
  • Editing a timelog-entry leads to a 500-error
  • Still suffers the earlier noted bug when changing issue's status using the context-menu (though workaround still works), see http://www.redmine.org/boards/1/topics/show/2352#Proposed-workaroundfix

I'd like to raise a bounty for building a plugin which provides the exact same solutions of the initial iteration of this patch by Artem Vasiliev. That would be a great thing to have provided by a plugin instead of a core-hack...

Also interesting to follow in this context is the proposed solution by Eggplant Digital (see http://www.redmine.org/issues/440#note-15)...

Note: I'll attach the patch-file I've created (and used) against r2641.

#32 Updated by [ Desperados ] over 2 years ago

this is what I need, does it work with redmine 2.6.x ?

#33 Updated by Jens Bures almost 2 years ago

I need that too for redmine 2.6.5.stable.

Also available in: Atom PDF