Jesse Vincent wrote:
Does anyone feel that this change should _not_ be reversed? Should the
change only trigger if two txns are recorded? Should that second
transaction simply be run as the RT_System user?
On Thu, May 11, 2006 at 11:30:51AM -0400, Stephen Turner wrote:
At Thursday 5/11/2006 10:27 AM, Jesse Vincent wrote:
On Thu, May 11, 2006 at 03:58:11PM +0200, Sven Sternberger wrote:
Hello!
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handling
That's correct. There were complaints about the old behaviour. I can't
remember if simply changing the default about how many scrips are run on
link transactions will change the behaviour.
I'd love to see this one reversed - to me, linking to a ticket
doesn't equal updating the ticket.
For us, this feature has unintended consequences - our Help Desk
staff need the ability to 'lock' a ticket so that multiple people
aren't trying to answer a question at the same time. To do this we do
not grant ModifyTicket directly to the Help Desk staff - we grant
them 'OwnTicket', and we grant ModifyTicket to the Owner role. So
they have to take or steal a ticket before they can update it.
However, the permissions for creating links now mean that help desk
staff can't group similar tickets by using parent/child links unless
they own all of the tickets. This is inconvenient of course, and we
got around it by bypassing the ACL check .
Thanks,
Steve
Jesse,
As much as I love what is being done in 3.6, I have to agree that
the linking of tickets should be seperate from an owner modifying one
ie. the person doing the linkng does NOT have to be the owner. OR you
could make that kind of ownership an option when linking. Perhaps in
configuration, there is an option that requires ownership to do links or
not. Just a thought. Also, I would REALLY like 3.6 to resolve the QUICK
TICKET function to put in a requestor automatically, PLEASE! Thanks.
Kenn/LBNL
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
We're hiring! Come hack Perl for Best Practical:
http://bestpractical.com/about/jobs.html
