I've just implemented and started using this module.
I have found that for every auto-created timetracking entry (spawned by the Quick TimeTracker block), a second entry is also created, showing the same start time, title, etc.. The extra entry is always for 0.07 hours, regardless of the length of the accurate entry.
The log report then showed a PHP error complaining about a duplicate entry being inserted into url_alias, presumably from two entries being saved with the same calculated URL alias (from the pathauto module). I have confirmed this was an effect of the problem, rather than a cause, by setting pathauto to not create aliases for TimeTracker nodes.
Comments
Comment #1
Magnity commentedSounds like this is related to Storm QTT.
Comment #2
jurgenhaasThanks @ailgm for reporting this issue, although I'm not currently able to reproduce this here. So I need your help to find out exactly what's going wrong.
Can you please provide some more detail about your environment?
Drupal version
PathAuto version
Storm version
Storm QuickTT version
Storm Dashboard version
Other modules in use
Also, can you please describe in more detail, when this is happening? I mean what steps are you taking to get to the error message? I'm asking this because there are no messages when starting timetracking. Maybe I misinterpreted you description and hence it would be helpful if you could provide me with a step-by-step instruction. Thanks in advance.
Comment #3
ailgm commentedI'll gladly give you that information. If you need access to the site to get to the bottom of this, that too could be provided.
Drupal version 6.14
PathAuto version 6.x-2.x-dev
Storm version 6.x-1.27
Storm QuickTT version 6.x-1.x-dev
Storm Dashboard version 6.x-1.x-dev
Other modules in use - well lots:
(core) blog, color, comment, contact, database logging, forum, help, menu, path, poll, search, statistics, taxonomy, update status, upload
(contributed) AddThis, Admin Menu, AdSense, Advanced Forum, Ajax, Author Pane, 404 Blocks, Control Panel, Global Redirect, IMCE, IMCE Wysiwyg bridge, Invite, Javascript aggregator, jQuery plugins, Lightbox2, MetaTags, Mollom, Pathauto, Path redirect, Poormanscron, Print, Rotor, Restricted Search, Site map, Site verify, SMTP, Subpath alias, Token, Upload element, Url alter, Views, Wysiwyg, XML sitemap
It happens every time I use the Storm QuickTT block to start/stop timetracking. Details: well, (with the Auto-Start Tracking checkbox ticked) I click on a project in the QuickTT block. I do see a message when timetracking starts -- there's a pink area shown in the bottom left that switches from:
Currently not tracking any time.
to (for example):
Timetracking is active for Project Management.
Take a note: ________________
Started
7 December 2009 - 2:39pm
When finished with that work, I click onto another project or the first item in the list: "- No billable work -" and the two rows get created (one correct, and a second for 0.07hours). The message turns to:
Time spent on Project Management: 6 minutes (edit).
Currently not tracking any time.
It happens consistently, so can be reproduced (I just did it again, to grab the message text shown above).
Thanks for investigating. Let me know how I can help further.
Comment #4
jurgenhaasThanks for your detailed description and your offerto help further.
Before I ask to get access to your site, let's explore one more thing: When starting timetracking (either by selecting a project in the block or by clicking the clock somewhere in the dashboard), there is a timetracking record created in the database immediately. This very same record gets updated once a minute. (Unless you pause timetracking)
As soon as you stop the timetracking (either by starting a new timetracking or by just stopping the current one) the existing record gets finally updated with the ellapsed time.
What's important now is to find out when exactly the second record gets created (and if the described workflow as described really happens that way).
You can help me finding this out if you're using Firefox with FireBug. You can then open the console in FireBug and see POST commands that get send to the server for each of the described steps. (If you're not using Firefox there are similar tools available for other browsers as well).
Comment #5
ailgm commentedI am using Firefox with FireBug, so I can trace it as you request.
The postings listed are:
Initially: startstop (mode true, nid 144), followed immediately by two update posts (mode 0, nid 0)
Then (after a 1 minute interval), two update posts (mode 0, nid 0) - 404 page not found (an aberration, I believe)
Then (after a 1 minute interval), two update posts (mode 0, nid 0), response: Elapsed time: 4min
Then (after a 1 minute interval), one update post (mode 0, nid 0), response: Elapsed time: 5min
Then (after a 1 minute interval), one update post (mode 0, nid 0), response: Elapsed time: 6min
Finally (when stopping it), one startstop post (mode true, nid 0)
From a separate PC, I can see on the standard TimeTracking list page, both rows listed while this is occurring, with the same date/time stamp on each, one with 0.07h (always) and the other changing.
If you would like more info from FireBug, please let me know exactly what -- I haven't used it much.
Comment #6
jurgenhaasThanks for your great description of the reports. With all this, it's explainable why two records get created. However, the system behaves wrong in two ways: the first update post should not happen so soon and all update posts should never happen twice.
I checked the code and I can't figure out why it should be possible that this is happening.
If you could give me access to your site with a test user having sufficient permissions to reproduce this effect in a web browser, I'd be happy to further debug this. If that's OK with you, please send me a PM or contact me via Skype (username: jurgenhaas).
Comment #7
ailgm commentedThanks. I'll be in touch with you late next week -- I'm going away for a few days. The easiest way might be a Skype session, where I share my desktop. Bye for now.
Comment #8
jurgenhaasLooks like we've been able to resolve this by removing asynch mode from AJAX. We're now testing on @ailgm's server as this has been the only one showing this issue and once this is not causing the issue anymore, we'll commit that to HEAD.
Comment #9
jurgenhaasThe tests have been successful and we're marking this one as fixed.
Comment #10
jurgenhaasComment #12
zeip commentedI'm also having this exact same issue (same symptoms & same length on the "extra" timetracking entry.) Could I have a patch for the fix? Couldn't find it in project CVS...
Comment #13
jurgenhaasIt's been fixed in the dev release. So please download that release and test it with that one and if everything goes well, I'm happy to release a 1.1 release based on that.
Comment #14
zeip commentedI tried a version of storm_quicktt from CVS (per http://drupal.org/node/539962/cvs-instructions/HEAD) and with storm_quicktt 6.x-1.x-dev. Both show the same exact symptom: An extra entry for each entry is entered with a duration of either 0,07 or 0,08 hours. In one case I even got two extra entries instead of just one, plus the correct entry.
Comment #15
jurgenhaasThis sounds as if you may have the previous JS file in your browser cache because with asynchronous AJAX mode the error can not possible happen again. So please flush your cache, both on server and in your browser and then try again.
Comment #16
zeip commentedI ran ”Flush all caches” and started a Firefox private browsing session. Still doesn't work. Can you tell me a row with which I can identify that I have the correct version (ie. the row that was changed to fix this)?
Comment #17
jurgenhaasGuess what, for some reason that one file (storm_quicktt.js) didn't get comitted so the change wasn't available in the CVS yet. No idea how that could have happened. I do appologize. I've just submitted the file a minute ago and you should be testing it again please.
Comment #18
zeip commentedWorks for me, thanks!