Hi Martin, I had a look at your suggestions and, although I think it might be possible to do it this way, I am afraid that this would cause quite a lot of work and it may be rather error-prone. I would need to write code to find out the times that a ticket is moved between queues, when the state changes and then, using these timestamps, find out when time_accounting was updated with what value. As tickets may in certain cases be moved back and forward between queues I stand a chance that I might miss time_accounting values or, even worse, count them double. I had a look at Kernel::System::Ticket::History and IMHO it should not be to difficult to write the queue id to the table ticket_history whenever an entry is added, I can just find out the current queue ID using the ticket ID passed. The only problem is that when a ticket is moved to another queue the history record is written after the move and you do not know the previous queue anymore. I can easily live with that. My only question is: can you think of any reason for me not to do this? For instance, are you planning to drop this field in a future version or are you planning to do something different with it? Thanks in advance. Kind regards, Tom <> wrote on :
Hi Tom,
On Fri, Apr 02, 2004 at 05:42:09PM +0200, Tom Hesp wrote:
Does anyone know whether this is a configuration issue or that I am just missing something or, even worse, got myself completely on the wrong track?
Yes, system_queue_id is not used.
You need to use history_type StateUpdate, Move and name of table ticket_history.
So you can find you what you want (if I understood it correctly).
Kind regards, Tom Hesp
Martin Edenhofer