Redmine

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

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

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... :-)

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:

• 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

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).

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:

• 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

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...

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.

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 sviridov: My earlier conclusion still holds though: "Great patch!". I even switch (lightweight) deployement architecture for it.. :)

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 sviridov: 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.

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

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?

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.

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...

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

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... :)

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!

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...

• 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...

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?

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.

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.

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..

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.

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

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

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.

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.

+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

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

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

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

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

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

I need that too for redmine 2.6.5.stable.

This looks fantastic! Please incorporate it.