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. >> _______________________________________________ >> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users >> Community help: http://wiki.bestpractical.com >> Commercial support: sa...@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 _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
