We are using RT 3.8.2 in this configuration: we have 3 queues, one for each workgroup, and an “incoming” queue where tickets always land (through email only).
People from the three workgroups are privileged, and we have a scrip in place that moves tickets from the “incoming” queue to one of the other queues depending on who takes the ticket.
Nobody can act on the “incoming” queue aside for taking tickets or commenting.
Today I took a ticket, and tried to link it with another ticket (with a “depends on” link) that was still in the incoming queue. I got an “access denied” message. I suspect this is because I did not own the other ticket, but I could not take it because tho other ticket had to be taken by a member of another workgroup.
Yesterday I had another issue which I feel is directly related to this one: we got a ticket that asked things logically belonging to two different workgroups, so I took it and then split it in two different tickets (using the “create” link next to “Children”). Since the child ticket belonged to another workgroup I changed its properties to go in the incoming queue and changed the owner to “nobody”. The ticket got created, but the link action failed with an “access denied” message.
I think the missing right here is “modify ticket”, but I may be wrong.
In general, I feel that the “modify ticket” right is too broad, and I think it would be nice to have it split in more “granular” rights.
Could somebody help with the problem, or suggest another configuration?
Thank you in advance!
Bye
Cris
Guadaagnino,
I had that same problem myself. I wanted people in one queue to be
able to link to tickets in another queue, but at the same time, I DIDN’T
want them to have the “ModifyTicket” right to the other queue because
they couldn’t own it and work on it (I hate when 10 different people can
mess with tickets in another queue. No control at all.). The answer was
the configuration “StrictACL”. If it is turned on ($StrictACL, 1) then
you HAVE to grant “ModifyTicket” to people who are not normally working
on tickets in the queue you want to link to. Turning OFF that config
($StrictACL, 0), allows users to link their tickets from 1 queue to
another WITHOUT the “ModifyTicket” privilege in the linked queue. So
this might do it for you. Hope this helps.
Kenn
LBNLOn 3/18/2009 6:07 AM, Guadagnino Cristiano wrote:
We are using RT 3.8.2 in this configuration: we have 3 queues, one for
each workgroup, and an “incoming” queue where tickets always land
(through email only).
People from the three workgroups are privileged, and we have a scrip
in place that moves tickets from the “incoming” queue to one of the
other queues depending on who takes the ticket.
Nobody can act on the “incoming” queue aside for taking tickets or
commenting.
Today I took a ticket, and tried to link it with another ticket (with
a “depends on” link) that was still in the incoming queue. I got an
“access denied” message. I suspect this is because I did not own the
other ticket, but I could not take it because tho other ticket had to
be taken by a member of another workgroup.
Yesterday I had another issue which I feel is directly related to this
one: we got a ticket that asked things logically belonging to two
different workgroups, so I took it and then split it in two different
tickets (using the “create” link next to “Children”). Since the child
ticket belonged to another workgroup I changed its properties to go in
the incoming queue and changed the owner to “nobody”. The ticket got
created, but the link action failed with an “access denied” message.
I think the missing right here is “modify ticket”, but I may be wrong.
In general, I feel that the “modify ticket” right is too broad, and I
think it would be nice to have it split in more “granular” rights.
Could somebody help with the problem, or suggest another configuration?
Thank you in advance!
Bye
Cris
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com