Stefano, are you sure that your tickets have type, service and sla set at
all?? New tickets can be (and usually are) created with empty service, sla
etc.
Maybe it's wiser to skip any selections on such fields? Can you extend the
same approach to other fields? Open one of your tickets to be processed and
try to catch this particular ticket by checking all the fields.
Anton.
2008/11/5 Stefano Milziadi
Ok, thanks for the reply.
I've do a configuration of GA but at the end of the config, when i save, there's a message that says "0 Tickets affected! Do you really want to use this job?"
But there are a lot of ticket "assigned" to root@localhost.
Now, i've hosted 3 images of my configuration, i know that they are in italian, but can you take a look if is all correct (for example the multiple selections)?
The link are: http://img99.imageshack.us/my.php?image=immagine1xl9.jpg http://img89.imageshack.us/my.php?image=immagine2oi8.jpg http://img223.imageshack.us/my.php?image=immagine3fe6.jpg
Thanks.
2008/11/5 Anton Gubar'kov
Ok, So you need to create as many jobs as you have agents. The idea behind GenericAgent is very simple: search for tickets using the values in sections shaded grey and set new values in tickets in sections shaded black. You should have all your ticket types, queues, agents, customers defined before you start making a GenericAgent job.
For example, we are building a job to assign Hardware problems to Mark Twain.
In Admin, go to Generic Agent. Type in the job name Hardware_to_Twain and click Add. A new job form appears. Study it a little. There are sections with title shaded gray. The values you put into these sections' fields are used to select the tickets for processing by the job. You select Agent/Owner = root@localhost. You select ticket state = new. You select Ticket lock = unlock, you select ticket type = Hardware problem. How do you plan to deal with email tickets btw? They will not get tycket type set correctly.
Now we move to sections with titles shaded black. That's where we program new values for ticket fields: You select new Agent = Mark Twain. You select the new Queue = Hardware, New ticket lock = lock. You may add a note to leave trace of what has been done for your customer. (It's reflected in the history for the agents anyway). Check Send no notifications flag .
Go back to the beginning and think of the schedule for the job. How often it should run?
AS soon as you save the job - you're done. If there are problems with the job - look in the System Log.
Regards, Anton.
2008/11/5 Stefano Milziadi
Hi, thanks for the reply.
For my idea is better that tickets just opened are assigned and locked directly to an Agent different from root@localhost, if is it possible in an automatic mode.
I've alredy set 2 type of queue (that are corrisponding to the 2 agent) and 4 or 5 Type of ticket. I've already created 2 agent and each of them watch his own queue...(ex.: Agent called Mark Twain watch only the "Mark Twain's queue").
So I really think that is needed a GenericAgent configuration, but i don't know how can set this. I don't know where i must to start in GA config.
Can you help me in a generic configuration?
Thanks in advance...
2008/11/5 Anton Gubar'kov
Stefano, If your Software problems, hardware problem etc. are supposed to be handled by different agents, it's best achieved by putting a ticket to a specific queue. I usually think of queues as collections of tickets that require certain expertise to be resolved. In your particular case it's better to create queues Hardware, Software etc. If you plan to create tickets from email, create separate email addresses for your queues as well.
You assign agents (your staff) to queues then. In Preferences for the agent you select the agents' queues to watch (for automatic new ticket notification). Don't forget about setting the right permissions on queues for both agents and customers.
I see having owner set to root@localhost an advantage in your situation as this is an indication to your customer that nobody is looking at the ticket now. It adds transparency and credibility. As soon as the agent locks the ticket by replying with email or posting a note, the owner is updated and the customer will see the agent's name. However when the ticket is unlocked, the owner and responsible stay as they were.
If you want to set the queue according to the ticket type, you need several GenericAgent jobs to move the ticket to a particular queue based on the ticket type.
I may still miss your business idea. Please comment on my suggestion clarifying your business idea and purpose. I'll try to help more.
Regards, Anton.
2008/11/5 Stefano Milziadi
Hi!
I want that new tickets are owned directly to a specified agent because in this method a customer can see in his ticket list that his ticket is immediately assigned to a specified agent and his ticket don't "pass" through root@localhost. For example...i've created 5 kinds of "Type" like "Software problems", "Hardware problems" etc... when a customer open a ticket in "Software problems" i want that this type of ticket is assigned to the agent Mark Twain and directly in his Locked Tickets...
If you want more information, let me know..
Thanks, Stefano.
2008/11/5 Anton Gubar'kov
Hi, Stefano.
Could you give us more information why you need your new tickets owned by other agent? It might well be that your purpose is achieved by other OTRS features easier.
Regards, Anton Gubarkov.
2008/11/5 Stefano Milziadi
> Hi! > > When a customer open a new ticket, this is assigned to the agent: > root@localhost > I want that new tickets are assigned to other agent (for example: > Mark Twain), but i don't know if i have to modify the Generic Agent settings > or i have to modify other settings. > > I've 2 queue that, in theory, should be used by 2 agent. But, both > are assigned to root@localhost. > > Thanks > > -- > Stefano Milziadi > pepozzo@gmail.com > > _______________________________________________ > 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 >
_______________________________________________ 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
-- Stefano Milziadi pepozzo@gmail.com
_______________________________________________ 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
_______________________________________________ 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
-- Stefano Milziadi pepozzo@gmail.com
_______________________________________________ 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
_______________________________________________ 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
-- Stefano Milziadi pepozzo@gmail.com
_______________________________________________ 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