Interesting, but is not this information already implicit in the ticket history table. This records both the datestamp of ticket receipt and when the ticket state becomes closed. More importantly, I have noticed a trend towards modifying the default tables when modifying the default schema in recent mails. I do not know whether there are any guidelines to modifying the OTRS schema, but I would have thought this approach carried a risk of creating a conflict with future updates of the OTRS schema. I would suggest that creating a new table with the additional fields linked to the index of the default table would reduce such a risk. Defining a convention for naming such schema extension tables could eliminate such a risk entirely. Queries would be a bit more complex of course. Simone Girlanda said:
I did it in the following way, I hope this can help other people.
I need to know the duration of a closed ticket because the quality policies of my company evaluate it, but also my customers want to know it.
From the customer point of view is not correct to have an endless time counter.
1 - add fields to ticket table
`close_time_unix` bigint(20) NOT NULL default '0', `close_time` datetime NOT NULL default '0000-00-00 00:00:00',
[ Stuff deleted ]