Hi Tom, On Tue, Jun 18, 2002 at 09:10:31AM +0200, Tom Schröder wrote:
So here a real life scenario. I have a Queue for our web developers. They come out with a new snapshot of a site and our internal staff and the customer should have a look. A couple of people are submitting the same error (maybe a missing image) and in this case it would be nice to make the first ticket the "master ticket" and the other ones duplicates. I know this from Bugzilla but this system would be too complicated! ;-)
The same could happen with a network outage or some other ISP related problem.
I see what you want. Put a group of tickets to one and answer/handle just this one, right? If yes, it's not possible, at the moment. Because a ticket system want (normally!) to handle tickets in customer <-> agent (1:1) relation. -==> Your scenario would be a n:1 relation. My solution in this case would be: * Create a support web form for the customers (with special options like product, release, component, ...). This form generates emails for your OpenTRS system. * Dispatch the incoming emails with procmail e. g. [...] :0 fw : * ^Product: your-product | formail -I "X-OTRS-Queue: your-product-queue" [...] -==> All incoming emails with "Product: your-product" in the email will be dispatched to the "your-product-queue" queue. You can also sort with more arguments such product && release && ... See http://otrs.org/pages/index.pl?Action=Ext&Site=Docu/xheader_otrs_queue.html for more details. * Add standard responses to this queue with the default answers (most needed answers). --==> You can handle each customer fast and personally.
Sub-Queues would also be a nice addon but I think that is not your intention for OTRS.
We got feedback (about sub-queues) from many people, so maybe OpenTRS will have sub-queue support in the next major release (e. g. 1.0).
have fun,
You too. ,-)
bye!tom
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- socrate: 9:38am up 3 days, 9:38, 3 users, load average: 0.00, 0.03, 0.00