1. I needed to create duplicate "preferred" queues for each of my existing queues since my queues are based on area (cities). (That a lot of queues.)
You needed one queue per "preferred area", and eventually a Generic Agent to automatically shove unlocked tickets out of the way, ie. in the correct queue for the agents to pick them up.
2. OTRS's queue security is based on groups so I would need groups for each of the existing queues as well.
You need groups for each existing queue only if the agents were not to move between the queues.
3. I don' t know how ticket for a specific area would be automatically moved in to the "general" queue for that region. (let say that each region had a queue and a sub queue for the preferred tech.) If the preferred tech did not respond, the ticket needs to move in the "root" area queue.
If i get you right, again the Generic Agent is yours, this time shoving escalated tickets from the 'preferred queue' somwhere else.
4. Once the preferred tech started working on the ticket, the ticket would stay in sub queue and not in the area queue where we want it. (i.e. all tickets for "Surrey" should be in "Surrey")
The preferred tech should move the ticket where anyone can see it.
5. We don't really have control over which techs sign up for which queues. (They are external to our company.) so security for queues needs to be controlled from our end.
Um. You're giving away master control to people you do not exactly know to be there and who are responsible for feeding your agents with tickets?
Then you should step back from the idea of preferred queues. See below.
Idea of a "master agent" was to avoid OTRS sending messages to all techs of a certain queue until the preferred tech has rejected the ticket. With a "master agent" every incoming ticket would be preprocess before distribution into the various queues. Anyway, it doesn't work as I said.
It's 'Lock', not 'Locks'.
[EMAIL PROTECTED] schrieb:
> @QUEUELIST = ("White Rock","Surrey","North Van");
> @QUEUETECHNAME = ("richard","rcg","Atul");
> @QUEUEEMAIL =
> ('[EMAIL PROTECTED]','[EMAIL PROTECTED]','[EMAIL PROTECTED]');
> 'assign owner 1' => {
> Queue => 'Raw',
> Locks => ['unlock'],
> States => ['new'],
> To => @QUEUEEMAIL[1],
> New => {
> Locks => ['lock'],
Lock => 'lock',
> Owner => @QUEUETECHNAME[1],
> Queue => @QUEUELIST[1],
> },
> },
The second thing we would like to be able to do is to assign and move tickets via email. This would allow a dispatcher to move and assign tickets from their Blackberry. The ability to change owner and lock tickets is part of that process.
This is not implemented as far as you want to, as it burds security based problems. How would you not only clearly identify but authenticate an agent closing or moving a ticket? You could rely on the way the email took or insist of the message being sent over an authenticated TLS session, and be sure then, but that would mean work on the SMTP server's side.
Once you got that clear, you need PostmasterFilter (PM) that perform the wanted action on ticket. The built-in admin interface for the PM doesn't suit your needs, you needed some new modules to extract commands from the email and actually perform them.
One can make a big thing out of it, building a huge module to perform everything you want. The other one thinks of a simple 'CLOSE' at the beginning of the subject, which dumbly closes the ticket. Or a 'MOVE abcd' to move it to queue 'abcd'. We're back to the general PM filter mechanism built-in.
Is there some reason that my code doesn't work. Or why the GUI interface can't seem to change a ticket's owner?
It can.
With kind regards,
Robert Kehl _______________________________________________ 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/
