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 ] _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/
