In general, sounds like a good idea. I was needing this today. So, I just added "Est. time (hrs.)" and "Actual time (hrs.)" custom float fields for starters.

There was code posted to the mailing list in December (Daily Reports) that added time tracking http://sourceforge.net/mailarchive/forum.php?thread_id=6210477&forum_id=3264

It would be very nice to get this added to the cvs HEAD as this would really fit into a lot of peoples work methods. We need to replace a commercial issue/help tracking package and this is the last piece that new need, time tracking, to replace it with mantis.

Any news on this? If I could get the code from the mail archive, I'd be happy to get it working on CVS HEAD and resubmit a patch.

Thanks,

John

I attached a patch that was provided by David Newcomb through the mantisbt-dev mailing list. The patch is against Mantis 0.19.2.

I haven't tested this patch in any way (yet!).

I've attached a patch to the current cvs head (1.0.0a3-CVS) that gets the tgz file up to date. Note that there are some files needed from the mantis-0.19.2-time_taken.tgz file attached to this issue.

This works ok for our purposes. Some notes about some of it's odditys:

• If you enter '30' into the time field, it is interpreted as 30 seconds
• If you enter '1:30' it is one hour and 30 minutes
• If you enter '0:30' it is 30 seconds

The safest way to enter time is hh:mm:ss

Is there any likelyhood that this functionality will be incorporated into the main source?
In the mean time, I will have a look at correcting the time_taken input issue.
How about:

• "30" = 30 minutes
• "1:30" = 1 hour 30 minutes
• "0:30" = 0 hours 30 minutes
• "1:30:45" = 1 hr 30 mi 45s
  [although I doubt anyone does per second billing, yet!]

I'd even say 5 -> 5hrs
the rest could (for me) remain as davidnewcomb suggested

Something that would increase the odds of this getting put into the main cvs tree would be an option to hide/show the time fields and reports. At least it could then be considered experimental and defaulted to off (like lots of other features).

Other configs could include:

• default single integer value (hours or minutes, so if you entered 5 you could configure it to determine if it is hours or minutes)
• option to hide the rate stuff (if your only tracking time and not billing)
• pie in the sky stuff - a javascript stopwatch so a CSR could push a button and time a call :-)

I am voting for this one too.

Hi all,

Finally got around to upgrading to the latest version - mantis-1.0.0a2. While upgrading I took the opportunity to add all the suggestions that were made above.
This bugnote would not let be upload a 1.4MB file, so I have placed the files on my server with some change notes.

http://www.bigsoft.co.uk/projects/mantis/mantis-1.0.0a2-time_taken.html

I have also created a demo that you can play on:

http://www.bigsoft.co.uk/projects/mantis/mantis-1.0.0a2-time_taken/login_page.php

There are 2 users to play with:

joebloggs (for the uk people)
johndoe (for the us people)

The passwords are the same as the usernames.

ps. can any of you tell me the magic incantation that creates and applies patch files (like the one that johnwebbcole created previously)

Enjoy.

I would still like to get this time_taken extension into the main source. What do I have to do next? If no one wants to do it I am prepared to do the changes myself.

If you've checked out the Mantis code from CVS, then to get a diff, you run this command in the root of the working copy:

cvs diff -u > /path/to/your/patch/file.patch

...where /path/to/your/patch/file.patch is the patch file that will be created.

It sounds like you've just downloaded 1.0.0a2 though and made your changes to it. In that case, make another copy of 1.0.0a2 from the original tarball and get a difference between it and your modified copy. You probably want to copy your config file to the pristine copy too. If you have directories "mantis-1.0.0a2-pristine" and "mantis-1.0.0a2-davidnewcomb" in the same directory, then do this:

diff -ru mantis-1.0.0a2-pristine mantis-1.0.0a2-davidnewcomb > /path/to/your/patch/file.patch

These commands are for Unix-like systems (Linux, BSD, Mac OS X, etc.); I can't help you if you use Windows.

Thanks ryandesign. I just download a 1.0.0a2 from the site. The released versions are stable and tagged, as most of the people who would be interested in this extension would not be interested in an unstable CVS version, so I have only patched 'proper' versions.

If I ever do get CVS access to put my changes into the source tree, how do I apply the diff patch (created previously) to what is in CVS?

Read the manual page for the "patch" command:

man patch

I've updated my cvs head sandbox with Davids new version and attached a zip file (mantisbt-time_taken.zip) with a patch and the extra files to this issue.

Here are some of my quick observations...

With $g_time_taken_hours = OFF; it doesn't seem to let you put in hours. For example:

enter 30 goes to 0:30 (h:mm) great
enter 1:30 goes to 0:01 wrong (I assume it's going to 1 minute 30 seconds
enter 1:30:00 and it still is 0:01

set to on, you can enter hours and minutes

enter 30 goes to 30:00 (hh:mm) great
enter 0:30 goes to 0:30 great

And I have to agree with Victor's recommendations at http://tinyurl.com/89ubu but I would still like to see the code put into CVS while its worked on, just to make things easier on keeping the code up to date.

BTW, here are the procedures I used to get David's changes into my CVS HEAD sandbox...

CVS check out the 1.0.0a2 tag into its own sandbox
Download Davids tarball
Use WinMerge to move changes to the 1.0.0a2 sandbox (I could have copied the entire sandbox, but I like seeing what changed)
Merge the changes from HEAD to the 1.0.0a2 sandbox
CVS check out the CVS HEAD to its own sandbox
Use WinMerge to move changed and new files from the merged 1.0.0a2 sandbox to the CVS HEAD sandbox

I'm sure there are better ways of doing this, but this works for me.

John,
Already the bug reports are coming in ;)
The time insertion is clearly a bug, which I'll take a look.
Thanks.

Just another suggestion:

• a total sum if partial times per bug could be made
• a total sum of selected bugs could be made (filter, ID enumeration per select box, ...)

anyway, I love this patch, will it make into 1.0.0 ?

Thanks for the extra suggestions, I'm gathering them for my next release.
I'm trying to get it in the main source. I'm in discussion with the project leader. Our leader has set up a blog for "should mantis support time tracking".
Please add any (support) comments to it:

http://www.futureware.biz/blog/index.php?title=should_mantis_support_time_tracking&more=1&c=1&tb=1&pb=1

The more people that want it in, the better.

We should be able to enter time in few formats....

3min
1,5h
1.5h
1h22
1day
1week
1month
1day 4h and 23min

In the bugnote statitics From should be by default the bug creation and To the current date

"anyway, I love this patch, will it make into 1.0.0 ? "

1.0 is pretty much 'feature complete' as far as the core developers are concerned. The current plan is to release either 1.0a3 or 1.0RC this weekend. Therefore, any time tracking functionality will not make it into the final 1.0 release.

Whether time tracking support is included or in what way can be considered for the 1.1 release.

@ 0004428:0010247:
I believe the simple time input is better.

@ 0004428:0010256: Not in 1.0.
This is bad luck, since johnwebbcole has been asking for feedback for months now. I would als like to see it in the next version, even if it´s "off by default". Of course I see the problem that it still can cause trouble. And getting 1.0 ready is also an important goal.

0004428:0010247
I think you are dreaming! That is a parsing project in itself, besides, what if you are not english!

0004428:0010248
This is what is by default. Although for the purposes of billing maybe it would be better to have it from the start of the month. We could have a couple of options, selected by a global. start_of_bug, start_of_month, start_of_week, anything else?

I added a time-tracking utility which could help you register the time spend per bug. Just add the user_time.php to your mantis directory and create an extra table (create-table and other info is in the php file).

See single_file_time_tracker.zip.

I haven't looked into the patches provided so far, but I'd like to mention a good guide of what to measure:
http://www.joelonsoftware.com/articles/fog0000000245.html
(I got the link from the discussion on 0004968 )

To save you from reading that (though the JoelOnSoftware-doc is clearly woth having a look):

Fields should be:

• OrigEst (Original estimated time needed to implement)
• CurrEst (Current estimation)
• Elapsed

When a bug is closed CurrEst and Elapsed should be equal.

Just read all of Joe's document and 0004968 plus relating. While it would be useful, to some, it is beyond the scope of this Time Tracking extension. You are getting into the realms of project management.

This time tracker is to calculate the 'actual' time spent on writing the bugnote and the work that 'actually' took place in order to write the bugnote. It is not concerned with estimates as they are not billable.

0004968 sounds like all the developers will add a bugnote with an estimated time and then update their bugnotes' as they do their work. Eventually all the developers will finish their tasks and actual can be compared to estimated. You are trying to shoehorn mantis to be a project manager/planner which it is not.

I agree with 0004968:0008593; most of what you want can be achived using custom fields. I think that estimates forcasting should remain on 0004968 or remain in the project manager software.

I agree with David, simpler is better, especially since this feature isn't in CVS yet. Most of the project management stuff can be done with custom fields and the suggestion in 0005055 would make that very easy to accomplish. It can feature creep after its in the source tree.

The only feature I'd like to add is a javascript stopwatch to fill the form out for use by CSRs to time phone calls and such, but that isn't as important as getting it in mantis (you can google on 'javascript stopwatch' and see several examples).

I'm for getting as many of Victor's suggestions in as possible and get it in CVS. I'm running this in production right now and can't give it up, so until it's in CVS, I have to maintain a couple of versions to keep things up to date. Getting this in CVS, even default off and marked experimental would simplify my Mantis life.

I'll take a look at the stopwatch but the trouble is that there are lots of places where the 'Add Bugnote' forms appear. It would be really nice if there was just one add_bugnote function (with lots of parameters), which handled printing the form. If it was centralised it would save loads of time, but unfortunately the Add bugnote form has been re-written in about 5 different places.

I am not sure which direction this bug is going.
Reading about the stopwatch I get the impression, some would like to record, how much time was spent writing a bugnote?!? (isn't this a total useless info?)

However, I implemented a really small adaption to 1.0.0a2, so time-tracking abilities as described in the JoelOnSoftware-guide are added to Mantis.

Anyone interested?

My intension is to track billable time. If some one phones and ties you up for 20 minutes then that is billable time. I guess John Cole is using it for that.

I however, use it to track how much time I spend on a particular update. For example my bugnote would be "I updated the images page" and my time taken would be 3 hours. I add all the related emails (theirs and mine) on those occasions I make the time taken equal to thinking time, research time and email writting time. Now I can keep track of all the time costs spent on a particular enhancement and easily split it up into monthly chunks.

Don't get me wrong, I liked JoelOnSoftware-guide approach, but my point is that almost all of that can be implemented using custom fields. Where as bugnote updates can not.

"almost all of that can be implemented using custom fields. Where as bugnote updates can not."

As you mention this, one of the things i've been looking at seeing if it's feasible is to extend custom field support to other objects, e.g. bugnotes/users. Locally, I've pretty much got working code to do this in all but the admin interface (and a cleanup).

ralfii: do you also have a patch to go with those screenshots somewhere? ( to an extent, that looks 'a bit like' the progress bar in other bugtrackers, for example: http://flyspray.rocks.cc/bts/ ).

I've been keeping an eye on this issue, when thinking about custom fields for bug notes for a couple of reasons:
a) someone (i.e. victor/myself) could potentially get the job of merging these two patches.
b) it could be interesting to consider if we could use the data entry as a 'special' custom field.
c) there's a number of views about timetracking functionality, that i'm not quite sure where this bug is heading atm.

time-tracking isn't something I could see my regularly using, however, I can see how it could be useful. One of the big things for me that is missing from mantis is a concept of a 'due date'. ETA/Projection don't really cut it for me. A concept of a due date would allow a couple of new reports/summary views, e.g. 'late/slipping issues'.

</endofftopicrant>

Our developers are using the time tracking feature just like David does, keeping track of how long a feature or bug takes to implement. While we don't bill off of it, it works nicely for this and has already surprised a lot of people to actually put a cost in hours for a simple feature.

Our customer service department uses http://www.helpstar.com/ to manage issues. Since mantis has begun the slow process of expanding beyond bug tracking to issue tracking, it would be great to move our CS department over to Mantis and integrate the two systems. Mantis does everything we use helpstar for, except time tracking, where they do bill customers based on time spent on an issue.

The javascript stopwatch would be a nice feature for us, thinking about it, it really doesn't merit inclusion except as a nifty gizmo. But it would be perfect for our CS people.

Grangeway, I attached the patch agains 100a2.

Unfortunately php is new to me, otherwise I would have made the effort-fields a float. But in gpc_api there were no routines handling floats, only gpc_get_int, so I sticked with int for the moment.

Here is a screenshot of how time estimates are (quite nicely) solved in FogBugz: http://www.fogcreek.com/FogBugz/40tour/11.html I havent used FogBugz myself and I don't know if those values are used in any statistics.

What are the reasons of not getting into the realms of project management? In my opinion, since we have projects already, this would just improve

You are trying to shoehorn mantis to be a project manager/planner which it is not.

I have been managing projects with mantis for some time. There is Manage | Manage Projects section in Mantis, which allows you to do just that - manage projects. We are just improving on this.

ETA/Projection don't really cut it for me
Ditto. It would, if it was a calculated field (from current estimations)

There is Manage | Manage Projects section in Mantis, which allows you to do just that - manage projects. We are just improving on this.

With respect, the 'Managing Projects' does not manage projects. It is merely a better name for Add/Modify/Delete Projects. There is more to managing a project than assigning people to it! What about time managing, project dependancies (this waiting on that etc), assigning resources, writing documentation, interfaces, billing - where does it end?

Writing all this is a massive undertaking. I don't think Mantis could take this kind of evasive change so early in its development. Maybe a SquirrelMail pluggin archtecture is needed?

...but we are not talking about all these features, we are talking about this tiny little extension "time tracking".
It can be implemented easily (it's actually only a few lines of code), and it perfectly makes sense.

And if you don't like it at all, you could - also very easy - make it an option that could be disabled on installations where not needed.

I agree with Ralf. You don't need all that functionality. But time tracking makes sense because times are attached to a comment which explains how that amount of time was spent and possibly why exactly another x time units are needed to accomplish the task.

Ralfiii when you talk about 'this tiny little extension "time tracking"' are you talking about my time tracker or your time tracker?
If it is mime, then 0004428:0010217 mentions that there is a option to turn it off.
If it is yours, then I thought this bugnote was talking about my patch.

My comments (0004428:0010446) we meant to be rhetorical and were a response to 'What are the reasons of not getting into the realms of project management?' I was trying to explain than other non-related enhancements were starting to creep in and distract from my original idea.

I think all those people who want estimated time for projects should add their comments to 0005055, and all those who want bugnote basic time tracking stay here.

I am trying to present my solution for time tracking but it is being polluted with 'extras'. There is a lot of discussion about what people want from estimated time. This should be discussed in 0005055 as that bugnote is solely aimed at estimated time projections. Although they are kind of related, there is no reason why they can't be implemented independently and added at different stages.

My enhancement is already being used in 2 production environments (mine & johnwebbcole's). How many other companies are out there who have similar working practices?

i'm using your extension, david

I'm still interested in this issue, but yesterday I stopped monitoring it. However, today, I'm still getting emails as if I'm monitoring it. Is this a bug?

stevemagruder, you will get notifications in the following cases:

• If you are the reporter.
• If you are the handler.
• If you are monitoring the issue.
• If you are the author of issue notes (which you are).

So there is no way, to disable notifications on a per issue basis, if you have authored a note. If you want, you can report an enhancement request.

I'm about to put Mantis 1.0.0a3 into production. I very much want this patch in Mantis 1.0.0. I like it basically like it is. Add a note and be able to say how much time it took to do the work on the issue. David does your patch work with 1.0.0a3?

Loki: I was waiting for the final stable release of 1.0.0 before bringing my patch forward. I don't do it for every release - its too time consuming! You could take the diffs (provided my johnwebbcole) and try applying them.

Any one know when the final release of 1.0.0 is coming out?

Couldn't we go ahead and have this patched into CVS now so that those of us who are keeping up with CVS updates can test the feature as much as possible before 1.0.0 is final? (By the way, I'm now working with the CVS version and am no longer stuck on 0.19.2 :) )

@DavidNewcomb, 0004428:0010470 : I was talking about "my" time tracker (tracking Original, Current Estimation and Elapsed time).

Rather than 0005055 I'll move my comments back to 0004968.
However, I'll post a comment to 0005055

Btw: What exactly are you planning to track in "your" extension.

Basically, a how long did you spend on this bug action.
0004428:0010333: "This time tracker is to calculate the 'actual' time spent on writing the bugnote and the work that 'actually' took place in order to write the bugnote. It is not concerned with estimates as they are not billable."
0004428:0010374: "time I spent on a particular update"

to ralfiii:

is TimeTrackingPatch_100a2.zip supposed to work against 1.0.0a2 ? because I just unpacked mantis-1.0.0a2 and ran that patch agains it and got this:

$ patch < TimeTrack.patch
patching file bug_update.php
Hunk 0000001 FAILED at 60.
1 out of 1 hunk FAILED -- saving rejects to file bug_update.php.rej
patching file bug_update_page.php
Hunk 0000001 FAILED at 280.
1 out of 1 hunk FAILED -- saving rejects to file bug_update_page.php.rej
patching file bug_view_advanced_page.php
Hunk 0000001 FAILED at 373.
1 out of 1 hunk FAILED -- saving rejects to file bug_view_advanced_page.php.rej
patching file bug_view_page.php
Hunk 0000001 FAILED at 279.
1 out of 1 hunk FAILED -- saving rejects to file bug_view_page.php.rej
can't find file to patch at input line 130
Perhaps you should have used the -p or --strip option?
The text leading up to this was:

|Index: core/bug_api.php
|===================================================================
|RCS file: /cvsroot/mantisbt/mantisbt/core/bug_api.php,v
|retrieving revision 1.93
|diff -u -r1.93 bug_api.php
|--- core/bug_api.php 11 Apr 2005 17:05:47 -0000 1.93
|+++ core/bug_api.php 3 Jun 2005 13:27:40 -0000

File to patch:

Oerni: I am no expert regarding CVS but I suppose instead of using the "normal" installer you should get the mantis-folder via CVS, get the files tagged "RELEASE_1_0_0a2_20050425" and then patch it.

I've just uploaded the files that were changed in V1.0.0a2 to bug 0004968
It should be possible to simply copy those files into your existing Mantis installation.

Let me know if you have further problems.

Unfortunately this bugnote ended somewhere in june, in the meantime the second release candidate has been released and I cannot found any update about time tracking. For us it would be very usefull, if it is possible to register the time every time we add a note, using a custom fields is not a very usefull solution, it is easily forgotten and mistakes can easily made.

Sorry, but this thread did not end it June - it just went quite!
1.0.0a1, 1.0.0a2, 1.0.0a3, 1.0.0rc1 1.0.0rc2, etc and all just patches for a pre-release of 1.0.0.
In bugnote @10480 I said I would wait until the final release of 1.0.0 before making another release.

David,
Have you made any improvements to the time tracker and reports? If so, I'll be happy to give them a try. I'm planning on putting my modifications into the next rc when it comes out (and it passes my tests :-) )

John

Thanks John. Jeroen has given me access to update the CVS myself. I will start work on adding Time Tracking to Mantis. I will be reviewing the comments that people have made. So watch this space!

Hi all,

Is very usefull this "time taken" patch, how can I integrate in mantis 1.0.3 or 1.0.1 ?...thank you ..very much ..how can help me..

Best regards
Ionutj

I have collated all the related information from this bugnote, related bugnotes and the blog, and will begin in ernst.

Does someone have the attachments for this issue? If so, please upload. The original attachments were lost.

I only have my full verion. Which I have uploaded.

I could produce the diff-files and screenshots again (against Mantis V1.0.5) but I think this bug is more about the "time taken" functionality and "my" implementation is actually covered by bug 0004968, so if requested I would upload it there...

Has this been put into the 1.1 version yet, or do I still need to diff it in?

Thanks,

John

This is not yet integrated into Mantis releases. Once it is integrated the issue will be resolved.

Would it be possible to include Ralfiii's expense tracking patch as well? It looks like it was available for 1.0.0 but the attachment is now gone. Time tracking and cost tracking are very complementary and should fulfill most project managment needs.

Does anyone have a version 1.1.0 based patch for this feature?

I have checked in my first set of code. I have added all my options to the bottom of config_defaults_inc.php.
I have implemented some of the features discussed here and in the blog.
johnwebbcole - I even added a nifty stop watch feature just for you ;)

All comments will be gratefully received.

I did a quick review of the checked in functionality and following are my comments:

• We should create a Wiki page for this feature that explains the supported functionality. Please use the Wiki page associated with this issue.
• Store the time in the database as an integer with minutes as the unit.
• Add a step to the schema that adds the required field.
• Make sure the code uses ADODB rather than MySQL specific code.
• Avoid use the term "Bugnotes". Use Time Tracking Report, etc.
• Date format hard-coded to American format. Use same technique as in the filters.
• In the time tracking report, I would add a row per time entry which has the date, user name, duration, and a truncated part of the note. The number of characters to display can be controlled by a config variable (0-all, otherwise truncate after N chars, but default set to 0). Use valign=top so that text is aligned at the top for entries which have wrapping notes.
• We should support csv export of the above report, specially when it is triggered from the billing_page.php.
• Add an empty line between the Bugnote statistics date range box and the actual report result.
• The link to the billing page is not shown if the $g_time_tracking_with_billing is set to OFF. However, the page can be visited directly and works but hides the cost / hour. We should probably keep the link as long as $g_time_tracking_enabled is set to ON.
• I am not sure of the value from supporting the cost. For this to be useful, I think we need to support a default rate per user, then have the ability to override this per project. The same way we handle access levels.
• Issue Ids in the billing page should be hyper linked.
• Shouldn't the dates in the billing page be defaulted the same way the date range is defaulted in the view issue page.
• Add $g_time_tracking_edit_threshold to control the access level required for a user to be able to add/edit time. This should be defaulted to DEVELOPER.
• Add $g_time_tracking_reporting_threshold that sets the access level required to run a report on the time tracking information. If this is OFF, then the billing page should not be accessible (access denied) and the link shouldn't be in the menu.
• Add $g_time_tracking_view_threshold that sets the access level required to view bug notes that having time information associated with them. A user who has edit threshold must have view threshold.
• The way the time is displayed is not clear, we should think of a way to display it in bigger font and in a more obvious place.
• Do we want to support the case where a user enters a time but no note text? In this case we should probably format it differently.
• The currency symbol is hard coded.
• If there are no entries matching the project and date range, then nothing happens. We should output a message indicating that there are no matching entries.
• In billing_inc.php, would $PHP_SELF be defined in register globals is OFF?
• In billing_inc.php, if this is part of the view issue page, then we should get the project id from the issue, if it is the billing page, then we should get the project id from the current project. You can set this variable before including the billing_inc page.
• In the billing_page report, I would probably leave a blank line between issues and would probably have the issue number / summary with a white background.
• In the documentation for $g_time_tracking_stopwatch clarify the dependency on $g_use_javascript and that the javascript needs to be enabled in the browser.

All useful comments. I'll get to work on them. I don't appear to have the right permissions to set up a wiki entry so can someone do that for me so I can start on some documentation.

David, I granted you the developer access and assigned this issue to you. This should also allow you to create the wiki page associated with this issue. Just click the Wiki link at the top of this page and then click Create Page.

Just an update for the progress with this issue:

• David did the following:
  • Changed the type of the time to an integer.
  • Added a schema upgrade step to add the integer field.
  • Created a wiki page.
• I've implemented the following:
  1. Add TIME_TRACKING as a bug note type. Similar to REMINDER.
  2. If the note was empty, the time was ignored and no error message was prompted. For now, we add the note with an empty comment, no email is sent, but the note is added.
  3. One of the db_* APIs was still referring to a $t_sec variable.
  4. The stop watch was using hh:mm:ss format which was considered invalid by the API. Now the seconds are used to come up with an approximated minute.
  5. Removed the "bugnote" strings and used "time tracking" instead.
  6. Improved the formatting to make the duration more prominant.
  7. Optimized the API that converts a number of minutes to hh:mm format.
  8. Added "Total time for issue" at the end of the notes section.
  9. Removed the pound sign that was hard-coded on the billing page.

In bugnote_stats_inc.php 65L,73L), lang_get('from') and lang_get('to') are used for I18N.
But they($s_from, $s_to) are already used in bug_reminder_page.php and mean e-mail address not time.
Please change them to other strings.

Sorry for my poor English.

0004428:0013865: Done.
0004428:0013831: I have added and linked in g_time_tracking_edit_threshold and g_time_tracking_view_threshold.

Wiki updated with the new configuration options.

Thanks, davidnewcomb.
but please correct as follows too.

• billing_inc.php 69line and 77line.

0004428:0013897: I had left this one because I knew I would have to fix the date entry form stuff, but I have now changed it as an interim.

My company is migrating to Mantis. We would like to assign hours to a category of work such as analysis, development, testing, etc. It seems that the bugnote type could be extended to achieve this functionality by allowing the user to select the note type from a configurable list. This would enhance reporting by enabling us to easily track how much time is being spent in the various categories by user and across the organization.

Is this something others might find useful and in keeping with the bug tracking focus? I would be willing to help develop this in any way that I can. I have PHP experience but am new to Mantis.

Apologies for the tardy reply. What you are suggesting can be achieved using the current model in the same way that they use it at mantis to do a whole release (0005410). Basically, create a bug report "Add feature x", then add a children bug reports called "analysis new feature x", "develop feature x" and "test feature x".

I would just have to make the top level parent sum the total times of all the child bugnotes to produce an overall time.

davidnewcomb, I would like to resolve this bug to represent that the initial version of this feature is complete. Can you please add a note identifying the work done from the list in 0004428:0013831 and also the status of the issues raised in the notes after it.

What I think we should do is:

• Update the bug with the status of all the issues remaining.
• The must have ones should ideally be done before we resolve the bug.
• Others should be reported as separate bugs and tracked separately.
• Verify that the Wiki documentation is up to date with the current implementation.

davidnewcomb,

Thanks for your reply. Sorry this response is so late. I've been away from the office.

I see that your suggestion would technically work. I disagree however that it would be a useful solution. Using a heirarchical model for a big project with subcomponents is great, but to break down each little piece into sub issues based on the category of work would quickly become a project manager's nightmare.

For instance, let's say I have a product that I have released to a client for testing. They find 100 bugs. Some of them small typos, some of them larger system issues...it doesn't matter what the bug. Under your suggestion I would have to open an additional x number of bugs for each one just to be able to categorize the hours. In our case, x could be 1-10 categories. Let's average and say that we have five categories for each bug. I suddenly have 600 bugs to deal with rather than 100. The original 100 parent bugs plus the 5 for each category of each bug. There is no way my project managers are going to be ok with this solution and I can't imagine that others would be either.

My company requires that we be able to break down the time spent on a project by the hours spent in each category. The basic structure for my suggested solution is already in place.

We would need to:

1. add the note type as a drop down list, defaulting to a regular bugnote if nothing is selected, validate selection.
   2. Allow the note type drop down to be turned on and off via configuration
2. Make the values for the list configurable
3. The most complicated part, create or expand the reporting to account for the categories in individual issues or groups (parent/child) of issues. And be able to calculate times by user as well.

It makes sense to keep all the time tracking for one issue in that issue, regardless of the type of work. Whether it's analysis, development, testing or whatever, it's still the same issue and would be much more easily managed as one issue.

I would like to see this make it into Mantis because I believe it is a better solution and provides a nice balance of adding a more complete time tracking/reporting function without stepping too far into project management.

As I said before, I am willing to code this and contribute it but I need to know whether you accept the concept before I start working on it. I look forward to your response.

Kind Regards,

Daryn

There is a thread on the board about adding time tracking:
http://www.mantisbt.org/forums//viewtopic.php?t=589&postdays=0&postorder=asc&start=36

A lot of people seem interested.

Is time tracking support already in CVS, or does is it have a planned for a later version? (I couldn't find it on the road map)

The implementation of this feature is now in CVS and will be included in 1.1.0a3. I have updated the target release so that this issue appears on the roadmap.

Great! Thanks :) The release looks almost ready. Any rough ETA? (a week, a month?)

I noticed when doing my reports that time spent doesn't show up. I'm currently using the CVS code. Since I'm going to use this for ticketing for my customers it would be nice to generate a report to know how many hours my employee's worked on said project so I can then bill them for it. I would also like it to be specific per project. so if I spent 2 hours on a ticket in Project A and 2 hours on a ticket in Project B it doesn't lump them together and say I worked 4 hours. If thats possible.

Is this supposedly complete? I'm using CVS; If I turn it on, I get fun SQL syntax errors like:
"APPLICATION ERROR 0000401

Database query failed. Error received from database was 0008120: Column 'u.username' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. for the query: SELECT username, SUM(time_tracking) sum_time_tracking
FROM mantis_user_table u, mantis_bugnote_table bn
WHERE u.id = bn.reporter_id AND
bn.bug_id = '14503'
AND bn.date_submitted > '2007-0322' AND bn.date_submitted < '2007-0322'
GROUP BY u.id"

I've just committed fixes to a lot of issues relating to this issue. This is including the bug mentioned by "rzg". This bug was due to a bug in db_prepare_date(). There were also a lot of bugs when notices are turned ON.

I will resolve this issue now. If there are any issues that are not yet covered which are mentioned here or not yet found, please report a separate bug for it.