Opened 15 years ago

Last modified 7 years ago

#4712 new defect

Duplicating records for hours worked on a user in ticket_change table — at Version 6

Reported by: anebi Owned by: Colin Guthrie
Priority: highest Component: WorkLogPlugin
Severity: critical Keywords:
Cc: petros@… Trac Release: 0.11

Description (last modified by Ryan J Ollos)

Hi,

We have installed these modules:

trac-0.11.2.1
timingandestimationplugin_branches_trac0.11-r5257.zip
worklogplugin-r5257.zip.

We noticed that there is a problem with duplicating records for work hours per user in table ticket_change in postgresql database. The problem is reproducing this way:

Go to a ticket and press: Start work.

Then without stopping the work, we just change resolution to something (for example Fixed) and apply changes. Then work is stopping and ticket is closing. After then in database i see 2 records for hours.

Like these:

13  1235734626  anebi	hours	0.0	2.81 
13  1235734625  anebi	comment	4	anebi worked on this ticket for 2 hours, 48 minut...
13  1235734625  anebi	hours	0	2.81
13  1235734626	anebi	comment	3	 - Made some tests with PHPFileNavigator.

You see the hours field and value. They are the same. Only different is timestamp. This happens because worklog is recrded this 1 second before the other record.

Maybe this is problem with timingandestimationplugin plugin. I'm nut sure.

Change History (6)

comment:1 Changed 15 years ago by anonymous

Severity: normalmajor

I made some more tests and try to fix it, but without success. The problem is in autostop functionality. When the ticket is closed directly, without stopping work log, then autostop functionality is started and then we get 2 duplicate records for hours field in custom_change table. Any suggestions how to fix it? Or how to remove one of the records, this one that is one second earlier recorded?

comment:2 in reply to:  1 Changed 15 years ago by anonymous

Summary: Duplicating records for hours worked on a user in ticket_change table in postgresqlDuplicating records for hours worked on a user in ticket_change table

Important thing to note - this does not only occur with PostgreSQL, I'm using sqlite and have exactly the same issue. Therefor I'm changing the ticket subject to remove postgresql.

Also it seems the entries in the work_log table in the DB are correct, it is only the entries in the ticket_changes table which are duplicate. Unfortunately that's the one used by the Billing reports, and it messes them up _displaying more time than was actually worked_.

Now if you actually do bill based on those reports this is pretty much a showstopper - I would recommend increasing the severity of this to critical.

Regards Georgi

comment:3 Changed 15 years ago by anebi

Severity: majorcritical
  • Increased severity to critical.

comment:4 Changed 15 years ago by Colin Guthrie

Status: newassigned

Hi,

Sorry for the radio silence here (<insert appropriate excuse here>).

The whole looping of hours worked and the listeners etc is a bit of a black art. The fact that the timestamps prevent two comments being left at the same time is also annoying but such is life (this is why I do -1 or -2 seconds on the comment times occasionally - it's ugly but it (mostly) works.

I'm not sure how to solve this stuff but I'm having a day of sorting out this stuff so hopefully I'll have something soon.

comment:5 Changed 14 years ago by anonymous

Cc: petros@… added; anonymous removed
Priority: highhighest

Same issue here, even after upgrading to 0.11.6.

Trac: 0.11.6
Python: 2.5.2 (r252:60911, Jan 4 2009, 17:40:26) [GCC 4.3.2]
setuptools: 0.6c12
SQLite: 3.5.9
pysqlite: 2.4.1
Genshi: 0.5.1
Subversion: 1.5.1 (r32289)
jQuery: 1.2.6

So If I close a ticket without stopping work on it, it counts that as two ticket changes, but a totalhours incements just once.

Also I think, "this is why I do -1 or -2 seconds on the comment times occasionally" is not the way it should be solved, it just deepens the dark magic hole. :)

On the other hand I'd like to thank you all for all the work you put in it. Thanks.

I set priority to highest, because this bug undermines the whole purpose of worklog and timingandestimation. :(

comment:6 Changed 11 years ago by Ryan J Ollos

Description: modified (diff)
Note: See TracTickets for help on using tickets.