Paul Rhein wrote: > Hi Bob, hi Martin, > > True in OTRS you can use the groups to achieve this. > However we had to face a little challange here. > Let my try to explain with an short, quite simplified example. Based on > Bobs posting. > > Queues: Q_EU, Q_USA,, Q_AUST > > Groups : G_EU, G_USA, Q_AUST > > Agent A_USA1, A_USA2, A_EU1, A_EU2 > > Tickets: T_EU (means ticket for / from EU customer) > T_USA (means ticket for / from USA customer) > > Facts: > > In OTRS a queue belongs to one and only one group (defined in the Admin > Queue view). > Example: > Q_USA has rw, mv and ro rights G_USA > G_EU has rw, mv and ro rights Q_EU > > Scenario 1 or "completely seperated continents": > > All the agents of G_USA get assigned the same set of rights on queue Q_USA. > Same for all the others. Nobody form G_EU ever has to do anything on > tickets form the others groups i.e Q_USA where he is not a member. > You need to set up an new agent for USA ? Just add it to the G_USA. Fine. > All happy lobsters. > > Now, in the above set up imagine the following situation.... > > Scenario 2 or "misplaced tickets" > > For *some* reason a ticket from EU "T_EU" gets assigned to "Q_USA" (via > postmaster or phone view). > Oh no good. Because we don't want the agents A_USAx in G_USA know about our > problems in EU! > But what can you do ? O.K. so for this T_EU we just want A_USA folks to > move the ticket to Q_EU. Hmmm. So we need to grant them the "mv"- rights to > Q_EU. > But hey, this means we need to assign A_USA to the G_EU as the Q_EU > belongs to G_EU. > But then they will have rw and ro rights on all EU tickets too. No we don't > want that ! > > So IMO we need to change the setup. We can do the following: > > For each and every Queue we define a Group. > For Queue Q_USA we define a Group GQ_USA and so on (change Admin Queue set > up) > To represent the above (Scenario 1) setup we need to grant > all the A_USA to GQ_USA with mv ro and rw permissions > all the A_EU to GQ_EU with mv ro and rw permissions > plus we need to grant A_USA mv rights on GQ_EU to move the misplaced > tickets to the right (EU) Queue. > (Note that G_USA and G_EU do not have any queues assigend in Admin Queue !) > > So this is cool again we could do it.....but wait we lost the "group > concept" on agents. > Now if you want to add an agent to the bunch of people taking care of the > USA customers formerly the group G_USA (not GQ_USA!) you need to check each > and every single permission manually for the new agent A_USA2. > This is an errorprone and cumbersome task if you have a lot of queues and > agents but please note that we could do it. > > According to the german bonmot "Faulheit ist der Vater allen Fortschrits" > we write a little SQL "grant same permissions to agent A_USA2 as the A_USA1 > has" (I already did this but it is quick and dirty so I did not post it). > So this is cool if you add a new agent but it is very uncool if you want to > add a new queue or new rights to all the members of a group (ie you want to > split Q_USA into North and South for stats reasons but you don't want to > split the USA Agents). Then you will have to manually change the > permissions of one agent and run the SQL for all the other "Group" members. > > IMO "default group(s)" on agent level could help. Whenever you add a > permissions to the default group but I am not sure whether this is such a > great idea... > > My questions are: > does the above description make sense to you ? > do you know if there is another (easier) way to implement situations > as in Scenario 2 ? > anybody worked in this area ? > any ideas on the subject ? > > kr > > Paul
Paul , Martin Your idea is interesting paul, but it sounds overly complicated. Maybe we shoudl go another way. On the other hand I have nothing to counter with so lets debate about it. A case scenario came to my mind this morning when I woke up. Imagine this scenario: Company X has problems and needs help from the otrs system. They mail in and Country A agent handles the requests. Now country A agent works from 9-17 hours. It turns out that X's problems are not solved during agent A working hours, they need help around the clock. So agent A handles over the requests to agent B in country B ( different time zone ). Agent B serves company X from 17-23 customer time. Now the problems are still not solved so country C agent C takes over serving the customer from 23-09 customer time. Agent A comes to work and continues serve the customer the following day, and the problems are solved. Is this scenario possible to handle in the current otrs? If not, any thoughts? /Greger > > > Martin Edenhofer <[EMAIL PROTECTED]>@otrs.org on 15-01-2004 07:32:43 > > Please respond to Development community of OTRS <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > To: Development community of OTRS <[EMAIL PROTECTED]> > cc: > > Subject: Re: [dev] work groups > > Hi Bob, > > On Wed, Jan 14, 2004 at 11:25:56AM +0200, Bob Smith wrote: > > > > just a quick question > > > > is ther eany support for work groups in the current otrs? > > > > > > What do you mean with "work groups"? > > > > I was thinking in the lines of grouping agents. > > Imagine a support department with 100 employees. The employees might be > > divided up into 10 person groups with responsibility areas, like > > one for europe, one for north america, one for latin america > > etc......you know. ... > > each group ( work group ) would have its dedicated support area to take > > care of. and have its own area of responsibility. > > I was working once in a really large enterprise and there we were > > divided up into areas like this, so it is possible that this type of > > division of > > employees is pretty common in large enterprises. > > ( just an idea again ) > > /Greger > > Of course, that can be done by otrs groups. > > Martin > > -- > ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg > http://www.otrs.de/ :: Manage your communication! > > _______________________________________________ > OTRS mailing list: dev - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/dev > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev > > _______________________________________________ > OTRS mailing list: dev - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/dev > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
