Re: [dev] work groups

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
Martin Edenhofer
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

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
@otrs.org on 15-01-2004 07:32:43 Please respond to Development community of OTRS
Sent by: dev-bounces@otrs.org
To: Development community of OTRS
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
participants (2)
-
Bob Smith
-
Paul Rhein