I just observed something odd. While closing a ticket (but not at any
other time I have found) if you change the Owner of the ticket you
will see this in the results:
You can only take tickets which are unowned.
…and the owner is not changed. Now this is odd because every
Privileged user has both StealTicket and TakeTicket globally.
Even funnier, because I can replicate this same behavior as the
SuperUser.
Methinks something is being checked wrong 
Version 2.8.2
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Reading the code in Ticket_Overlay around line 2730-2750 it would
appear that this is deliberate. For someone to reassign a ticket to
someone else on their reply, they must be the current owner. For me
to take it back and close it, I need to separately Steal it, then
Resolve it.
Would you accept a patch that allows implicit Steal like this?On Mar 4, 2009, at 11:21 AM, Jo Rhett wrote:
I just observed something odd. While closing a ticket (but not at any
other time I have found) if you change the Owner of the ticket you
will see this in the results:
You can only take tickets which are unowned.
…and the owner is not changed. Now this is odd because every
Privileged user has both StealTicket and TakeTicket globally.
Even funnier, because I can replicate this same behavior as the
SuperUser.
Methinks something is being checked wrong 
Version 2.8.2
–
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
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
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Reading the code in Ticket_Overlay around line 2730-2750 it would
appear that this is deliberate. For someone to reassign a ticket to
someone else on their reply, they must be the current owner. For me
to take it back and close it, I need to separately Steal it, then
Resolve it.
Would you accept a patch that allows implicit Steal like this?
Nope. That would entirely defeat ownership-as-locking.
Reading the code in Ticket_Overlay around line 2730-2750 it would
appear that this is deliberate. For someone to reassign a ticket to
someone else on their reply, they must be the current owner. For me
to take it back and close it, I need to separately Steal it, then
Resolve it.
Would you accept a patch that allows implicit Steal like this?
Nope. That would entirely defeat ownership-as-locking.
Ownership doesn’t lock. Anyone can update any ticket.
And more to the point, that’s exactly how we want it. Anyone can
reply to any ticket, anyone can update any ticket. That’s how its
working today.
We’d actually like to see locking in the “someone is currently
responding to this ticket” but I’m going to have to dig into the code
and figure out how to make this happen.
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Jo Rhett,
I agree with Jesse. Although it is a pain in the rump to have to go
thru 2 steps to re-assign a ticket, I am of the mind that when you
lossen the the reins of ownership (and for that matter let too many
users have the “ModifyTicket” right.) you run the risk of “owners”
undoing each others work. We allow only 2 users to have the
“ModifyTicket” right, Owners and the AdminCc (which for us is the Queue
Manager). We only allow the Queue manager to have the “StealTicket”
right. The reason is that for us, tight control of tickets and the work
on them is critical. We just can’t allow users the ability to point at
one another and say “he did it”.
Obviously, there are MANY RT installations that are smaller and need
WAY less control. However, I would prefer that we have a choice of
“degree” for control, like in the RT_SiteConfig, rather than just
opening it all up OR removing such features as “Bulk Update”, which I
use a lot when setting up new queues or when a queue needs to do a mass
change to a CF or something.
just a thought.
Kenn
LBNLOn 3/4/2009 11:33 AM, Jesse Vincent wrote:
On Wed 4.Mar’09 at 11:29:38 -0800, Jo Rhett wrote:
Reading the code in Ticket_Overlay around line 2730-2750 it would
appear that this is deliberate. For someone to reassign a ticket to
someone else on their reply, they must be the current owner. For me
to take it back and close it, I need to separately Steal it, then
Resolve it.
Would you accept a patch that allows implicit Steal like this?
Nope. That would entirely defeat ownership-as-locking.
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
I think you’re missing the point though. If you don’t allow
Stealticket then this wouldn’t matter. The only question is “if they
can Steal the ticket, why force them to take duplicate steps” ?
I don’t understand why you don’t want more control for Bulk Update.
So any of your users can cause every one of your ticket requestors to
get a blank message … and this is good how?
The point here is to allow each organization to work how they like
best. Don’t take away StealTicket just because you don’t allow it.
Just don’t assign the right.On Mar 4, 2009, at 12:43 PM, Kenneth Crocker wrote:
I agree with Jesse. Although it is a pain in the rump to have to go
thru 2 steps to re-assign a ticket, I am of the mind that when you
lossen the the reins of ownership (and for that matter let too many
users have the “ModifyTicket” right.) you run the risk of “owners”
undoing each others work. We allow only 2 users to have the
“ModifyTicket” right, Owners and the AdminCc (which for us is the
Queue Manager). We only allow the Queue manager to have the
“StealTicket” right. The reason is that for us, tight control of
tickets and the work on them is critical. We just can’t allow users
the ability to point at one another and say “he did it”.
Obviously, there are MANY RT installations that are smaller and
need WAY less control. However, I would prefer that we have a choice
of “degree” for control, like in the RT_SiteConfig, rather than just
opening it all up OR removing such features as “Bulk Update”, which
I use a lot when setting up new queues or when a queue needs to do a
mass change to a CF or something.
just a thought.
Kenn
LBNL
On 3/4/2009 11:33 AM, Jesse Vincent wrote:
On Wed 4.Mar’09 at 11:29:38 -0800, Jo Rhett wrote:
Reading the code in Ticket_Overlay around line 2730-2750 it would
appear that this is deliberate. For someone to reassign a ticket
to someone else on their reply, they must be the current owner.
For me to take it back and close it, I need to separately Steal
it, then Resolve it.
Would you accept a patch that allows implicit Steal like this?
Nope. That would entirely defeat ownership-as-locking.
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
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
I think you’re missing the point though. If you don’t allow Stealticket
then this wouldn’t matter. The only question is “if they can Steal the
ticket, why force them to take duplicate steps” ?
Because Steal isn’t the same thing as Take. Steal is an explicit “break
the ownership lock” command. Making every “take” an implicit “steal”
destroys any utility ownership locking has.
Jo Rhett,
I only grant ticket owners the "ModifyTicket" right, so noone CAN
bulkudate a ticket that isn’t theirs.
Kenn
LBNLOn 3/5/2009 2:11 AM, Jo Rhett wrote:
I think you’re missing the point though. If you don’t allow Stealticket
then this wouldn’t matter. The only question is “if they can Steal the
ticket, why force them to take duplicate steps” ?
I don’t understand why you don’t want more control for Bulk Update. So
any of your users can cause every one of your ticket requestors to get a
blank message … and this is good how?
The point here is to allow each organization to work how they like
best. Don’t take away StealTicket just because you don’t allow it.
Just don’t assign the right.
On Mar 4, 2009, at 12:43 PM, Kenneth Crocker wrote:
I agree with Jesse. Although it is a pain in the rump to have to
go thru 2 steps to re-assign a ticket, I am of the mind that when you
lossen the the reins of ownership (and for that matter let too many
users have the “ModifyTicket” right.) you run the risk of “owners”
undoing each others work. We allow only 2 users to have the
“ModifyTicket” right, Owners and the AdminCc (which for us is the
Queue Manager). We only allow the Queue manager to have the
“StealTicket” right. The reason is that for us, tight control of
tickets and the work on them is critical. We just can’t allow users
the ability to point at one another and say “he did it”.
Obviously, there are MANY RT installations that are smaller and
need WAY less control. However, I would prefer that we have a choice
of “degree” for control, like in the RT_SiteConfig, rather than just
opening it all up OR removing such features as “Bulk Update”, which I
use a lot when setting up new queues or when a queue needs to do a
mass change to a CF or something.
just a thought.
Kenn
LBNL
On 3/4/2009 11:33 AM, Jesse Vincent wrote:
On Wed 4.Mar’09 at 11:29:38 -0800, Jo Rhett wrote:
Reading the code in Ticket_Overlay around line 2730-2750 it would
appear that this is deliberate. For someone to reassign a ticket
to someone else on their reply, they must be the current owner.
For me to take it back and close it, I need to separately Steal it,
then Resolve it.
Would you accept a patch that allows implicit Steal like this?
Nope. That would entirely defeat ownership-as-locking.
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
I think you’re missing the point though. If you don’t allow
Stealticket
then this wouldn’t matter. The only question is “if they can Steal
the
ticket, why force them to take duplicate steps” ?
Because Steal isn’t the same thing as Take. Steal is an explicit
“break
the ownership lock” command. Making every “take” an implicit “steal”
destroys any utility ownership locking has.
I think what we’re bumping into here is a total lack of documentation
on how this locking has been theorized and is supposed to work.
I don’t witness this locking behavior at all. Based on the rights
here, anyone can answer any ticket, any time. That is pretty much how
we want it. So having part of the system trying to enforce a stricter
policy that we’ve defined the rights for doesn’t make sense to me.
(not that stricter shouldn’t be possible – it should be, just not if
we want to turn it off)
If there was some documentation on how Take and Steal are supposed to
interact, with some guidelines on how to properly implement some
common scenarios, I wouldn’t be so confused. If someone has this on
the top of their brain or already written down somewhere and can punt
it into the wiki (as the only apparent source of updated
documentation) that would be great.
Notes:
-
Yes someday I’ll have time to read the code and then I will
document it so I won’t forget it. That day isn’t today, and won’t be
anytime in the next week either.
-
I’m not arguing that any else should have as loose of a policy as
we do. Different needs for different environments. I’m just
suggesting that someone else wanting it tighter shouldn’t mean that we
must run our organization the same way. For anyone who wants a “one
true way” point of view there is always OTRS
-
What does seem to be lacking is real locking – preventing race
conditions on “who types the fastest”. When I have some free time, I
was going to see how hard it would be to implement “someone is typing
on this ticket RIGHT NOW” kind of locks.
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
I only grant ticket owners the “ModifyTicket” right, so noone CAN
bulkudate a ticket that isn’t theirs.
For your environment that may make sense, but not here. OTRS enforces
that kind of approach – you can’t turn it off without hacking the
source code. And our general overhead to respond to a ticket was 8-
times-higher than the actual time spent answering the tickets.
When you have a fairly equal support team and anybody can answer
almost everything, the last thing in the world you want to do is force
people to keep unassigning and reassigning tickets to themselves. In
our environment 98% of tickets never take an owner. We only do that
to indicate that “only I can do this, ya’all leave it be”
Using RT with everyone having OwnTicket, TakeTicket, StealTicket,
ModifyTicket, etc has reduced our overheard to about 1.2:1 which is
totally acceptable in our mind. Now people have stopped avoiding
using the ticket system because it’s no longer a PITA to use.
Anyway, long post for a short idea: different uses for different
users This particular piece of code seems to implement a stricter
policy that clashes with the rights assignments.
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness