[Patch] Some suggested changes to worklogplugin

[Michael Kruger]

Awesome plugin - this one should definitely be added to the main trac once it's mature.

I've made some changes to the worklog plugin that you might find useful:

• Added a comment field to work logs
• Changed the "Start Work" & "Stop Work" button actions to return to the originating ticket.
• Changed the main worklog page to list all the worklog entries, instead of just showing your most recent log. This is handy for importing into Excel (for example), where all sorts of interesting reporting with pretty graphs can be done. This cold be put somewhere else, but I'm not yet sure where...
• Corrected a few (incorrect) references to "Timing and Estimation Plugin."
• Changed some of the css styling to better fit worklog entries on the page.

It's all pretty simple stuff but I'm just a beginner in python so my apologies for any errors. It all works for me. :)

Please find a diff attached.

[Michael Kruger]

A diff of my modified worklogplugin against head.

[Colin Guthrie]

Replying to mike@kkl.com.au:

Awesome plugin - this one should definitely be added to the main trac once it's mature.

I've made some changes to the worklog plugin that you might find useful:

Great thanks :) It's really nice to see people taking an interest in it :D

• Added a comment field to work logs

I didn't do this initially as I figured the comments in a ticket itself was enough and I didn't want to separate out relevant details into different places for someone coming to review the "work done" later. Can you comment on why you thought this was necessary as perhaps I have missed a use case? :)

• Changed the "Start Work" & "Stop Work" button actions to return to the originating ticket.

Yes a few people requested this so this is a nice addition I think. I was going to convert it to Ajax once I get the XMLRPC stuff in there but this is simpler :D

• Changed the main worklog page to list all the worklog entries, instead of just showing your most recent log. This is handy for importing into Excel (for example), where all sorts of interesting reporting with pretty graphs can be done. This cold be put somewhere else, but I'm not yet sure where...

I don't particularly like this one to be honest. I like to know (at a glance) what people are working on at the given time - it's useful for managers etc. If some people are doing more work (or changing work more often than others) then this table gets pretty hard to glean that information from.

I had originally intended for people to use the Timeline view to see a full history visually but I accept your point about exporting a history to Excel. Perhaps a "CSV" link could be added to the page output which changes the logic to do a full dump of all history but keeps the HTML table to show only the latest tasks per person?

• Corrected a few (incorrect) references to "Timing and Estimation Plugin."
• Changed some of the css styling to better fit worklog entries on the page.

Nice thanks. :)

It's all pretty simple stuff but I'm just a beginner in python so my apologies for any errors. It all works for me. :)

I'm a Python n000b too so no worries there :p

Thanks for you changes. I'd appreciate your further feed back (and feel free to do more coding if I've raised valid (IYO) points :p But regardless of further coding, your feedback would still be appreciated :D

Thanks again - some or all (if perhaps slightly modded) of these changes will defo be committed.

Col

[Colin Guthrie]

More reply after reading the diff in a little more detail :)

Replying to coling:

Replying to mike@kkl.com.au:

• Added a comment field to work logs

I didn't do this initially as I figured the comments in a ticket itself was enough and I didn't want to separate out relevant details into different places for someone coming to review the "work done" later. Can you comment on why you thought this was necessary as perhaps I have missed a use case? :)

FWIW, I was going to change the "Stop Work" action to display a Javascript "popin" window (don't know if that's the right term - I mean DOM manipulation rather than a real popup window) to display a Calendar and Time selection field to allow you to stop work "in the past" (for those occasions where you forget to tell Trac you've stopped and go home!!). Perhaps if a comment field is added here and it just passes it to the ticket rather than store it in work log, then this would be enough?

But then again perhaps it is handy to have the comments in your Excel dump too? Ach it does no harm. I'll probably change the logic just a little tho' so that the comment always gets added to the ticket regardless of whether the preference is set to leave the automated comment, that seems more sensible to me.

• Changed the main worklog page to list all the worklog entries, instead of just showing your most recent log. This is handy for importing into Excel (for example), where all sorts of interesting reporting with pretty graphs can be done. This cold be put somewhere else, but I'm not yet sure where...

I don't particularly like this one to be honest. I like to know (at a glance) what people are working on at the given time - it's useful for managers etc. If some people are doing more work (or changing work more often than others) then this table gets pretty hard to glean that information from.

I had originally intended for people to use the Timeline view to see a full history visually but I accept your point about exporting a history to Excel. Perhaps a "CSV" link could be added to the page output which changes the logic to do a full dump of all history but keeps the HTML table to show only the latest tasks per person?

OK, considering I like your other changes then I'll play about a bit here and do the CSV export.

FYI, there was another user who contacted me recently who wanted to do some pretty graphs inside this plugin - e.g. integral to it. So perhaps the need for Excel export will diminish in time anyway :)

As some general feedback there were two points that jumped out at me.

• You used HTML syntax (a span) in the RSS view of the worklog listing. It should have just been plain text.
• The comment itself should really be passed through a "wikiification" function to ensure that any WikiSyntax is converted properly.

Other than that tho' it seems cool. I'll review further and merge the changes shortly.

Thanks again.

Col

[anonymous]

Comments vs Ticket Log: I felt that I needed an extra field to record information about the work period, as opposed to information about the actual ticket.

eg: "Started work on feature X. Phoned Joe for clarification. Gave Steve a status update." in the worklog and "Feature X scaffolding done. SQL functions A,B,C implemented." in the ticket.

I suppose you _could_ combine the two to keep the interface simpler, but a slight conceptual kludge.

I'm also keeping in mind that I'd eventually like the ability to record time against a component / milestone and not against any specific ticket. (eg: meetings, doco, phone.) In which case having comments on the worklog itself would be useful, no?

Worklog main page: A separate CSV controller function would be nicer, I definitely agree.

On a related note, are you still wanting a desktop app for logging time? It seems to me that a better approach would be to have a webpage which just listed all your tickets (owned or assigned) with each ticket having an AJAXed start / stop work button. That way you could roll it out across a wide range of platforms.

[Michael Kruger]

Oh - and I think you'll find the worklog comment in ticket_change.newvalue too. :)

mike

[Colin Guthrie]

Replying to anonymous:

Comments vs Ticket Log: I felt that I needed an extra field to record information about the work period, as opposed to information about the actual ticket.

eg: "Started work on feature X. Phoned Joe for clarification. Gave Steve a status update." in the worklog and "Feature X scaffolding done. SQL functions A,B,C implemented." in the ticket.

I suppose you _could_ combine the two to keep the interface simpler, but a slight conceptual kludge.

There is a difference I agree, although I personally don't see the need to separate them, however perhaps the future will prove that this is not the case, so I think it's wise to plan for that now and just add it in! Even tho' it's in ticket_change.newvalue it could be hard to match a worklog entry to a ticket_change entry so storing it in work_log table I think is fine. It does no harm and I don't think we have to worry too much about disk space. Besides I can always nuke it later if it proves unnecessary!

I'm also keeping in mind that I'd eventually like the ability to record time against a component / milestone and not against any specific ticket. (eg: meetings, doco, phone.) In which case having comments on the worklog itself would be useful, no?

I guess but I think that could become untidy if you start recording time against anything other than a ticket. You can change ticket types to suit your needs so I've personally added things like "Meeting" and "Task" to it to represent things that are not just "Defect" and "Bug" making tickets generally more useful to my wider team. That way *everything* someone does at work from the start of the day until the end could, in theory, have a ticket associated with it. Sometimes I will reuse a ticket - for example a "Phone Conversation with client X". I can appreciate that this may get somewhat kludgy in some peoples' eyes but I think it keeps the model simpler.

If you work with different Clients, you may also be interested in my ClientsPlugin which adds an easy way to manage multiple clients. I will be extending it shortly to include billing/price/rate information too. It adds reports to TimingAndEstimationPlugin too :)

Worklog main page: A separate CSV controller function would be nicer, I definitely agree.

Cool I'll do that :)

On a related note, are you still wanting a desktop app for logging time? It seems to me that a better approach would be to have a webpage which just listed all your tickets (owned or assigned) with each ticket having an AJAXed start / stop work button. That way you could roll it out across a wide range of platforms.

Yeah I thought about the Ajax approach and was going to do that, but I still feel a desktop app would give a nicer UI in the long run. That's not to say it couldn't be complimented by a web version too. A FF plugin could work (e.g. the facebook popups are quite nice), but I'm not sure how well a straight Ajax app will work for the kind of visual feedback I want - to keep the user focused on the task they are working on and make sure they don't "wander" into working on something else!

I will probably include some sort of Ajax based passive popup within the Trac site once I get the XMLRPC going but we'll see how it all pans out :)

Cheers again

Col

[Colin Guthrie]

Oh one other small point about the patch, but don't worry about it.

The idea behind having a db version in the class is such that you can upgrade it nicely.

Your patch alters the "base" version and as such it wont upgrade nicely.

I'll adjust it so the extra column is added to the work_log table via an ALTER TABLE and bump the version. That way both new installs and upgrades will work.

Ahhh forward planning that actually works. Nice! :p

[Michael Kruger]

Ok - points taken re: <spans> and db versioning. Is there a howto around somewhere for this stuff? :)

Two further changes I'm going to try to find time for this week:

• Add a list of the ticket's worklog entries to the ticket view. Each entry will have an edit button which will enable calendar / clock editing to change the entry details. (And update the ticket's total time.)

• Add a "Manually add a Work Log" section, which will allow the user to create a new worklog entry with a specified start / finish / comment. (A la your "pop in window" suggestion.)

Any suggestions or comments?

[Colin Guthrie]

Replying to krugerm:

Ok - points taken re: <spans> and db versioning. Is there a howto around somewhere for this stuff? :)

Nah not really. I just adopt a "Monkey see, monkey try to do" approach personally ;)

Re: the versioning of the db schema, that is a 100% custom approach, but one I've implemented independently in reportmanager.py which is a utility class which is copied around in different plugins (erm, hmmm, I realise it's not actually in THIS plugin, but it does exist in ClientsPlugin and TimingAndEstimationPlugin).

Two further changes I'm going to try to find time for this week:

• Add a list of the ticket's worklog entries to the ticket view. Each entry will have an edit button which will enable calendar / clock editing to change the entry details. (And update the ticket's total time.)

I would be careful about this approach. I was intending on allowing something similar, but lots of checks will be needed to ensure no overlap of times etc. And retrospectively changing the ticket hours may be a little tricky (I intend to fix TimingAndEstimationPlugin to accept negative numbers to reduce the number of hours on a ticket which may help your corrective action.

You could of course adjust the original entry where the hours were added and tweak the total, but this is perhaps little dodgy as it removes the audit trail of what's happened.

Also at present I do not actually touch any of the TimingAndEstimationPlugin's data, I just used the exposed methods via the API to record time and I'd like to keep it that way.

I'd perhaps be tempted to limit this feature to allow only the reduction of the worklog end time only and not actually touch ticket hours. If you are manually reducing the hours on a worklog entry then it would be trivial to "add the (negative) hours" to the ticket manually too. After all this should be a rare task anyway. WDYT? If you want to extend the hours you could just add a new work log entry as you state below. It just needs to start where the last one left off.

• Add a "Manually add a Work Log" section, which will allow the user to create a new worklog entry with a specified start / finish / comment. (A la your "pop in window" suggestion.)

Any suggestions or comments?

If you use a popup type thing then please consider using the ​YUI calendar widget for the display of the calendar.

I only say this as I've got an as yet unpublished patch for the TimingAndEstimationPlugin that uses this on the Billing page. I've not quite had the time to iron out the bugs but if a calendar widget is used in these semi-related plugins it would be nice if it was the same one ;)

Other than that, Great!!! (and thanks!)

Col

[Colin Guthrie]

Oh FWIW, I did not find a nice UI widget to display the Time part of the date/time combo.... I figured just using a text entry for this was simplest tho' if you've got other suggestions....

[Colin Guthrie]

I completely apologise about the database schema thing!! I've not implemented it at all in this plugin. I thought I had... Really sorry. I'll implement it in my commit and you can see it then :p

[Colin Guthrie]

(In [2552]) Refs #1898 by applying modified patch.

Bits of the patch not submitted:

• Does not modify the display of the worklog page and keeps it as a single user overview.
• Does not allow the storage of a comment when starting work (only stopping)

Bits changed:

• The display of the comment on the timeline was moved to the detail area which is more appropriate
• Comments on the worklog should now support WikiFormatting

Bits added:

• Added a db schema version wrapper as per reportmanager.py and my other plugins.
• Added a CVS output to the worklog page (VERY VERY rudimentary - mime time is just text for debugging and there is no attempt at quoting and delimiting the data properly)

Bits to do in the future:

• Make the CSV output better and properly quote/delimit things (a comma in a comment will totally break things right now).
• Remove the comment field from Stop Work button area as it looks UGLY ;)
  • On this note, when clicking Stop Work it should display a popup type window, that:
    • Allows a selection of a date/time in the past to Stop Work (incase you forgot and overran)
    • Display the comment field.

I've probably forgotten some detail in this commit message and I've not tested this as much as I would usually so there may be some bugs.

Thanks loads to krugerm for the initial patch. Keep up the good work. Hope you agree with my changes here :)

[Colin Guthrie]

(In [2553]) Refs #1898 and improves CSV export

[Colin Guthrie]

This is just a "ping" comment to say I've made a couple of commits relating to this. See the above two comments. It seems that Trac Hacks doesn't email for comments left via the commit hook :(

[Colin Guthrie]

(In [2556]) Refs #1898. Adds a file name for the CSV export. Probably helps on some platforms.

[Ryan J Ollos]

Just fixing formatting of ticket description so it is more readable.