Hello!
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handling
Situation:
Two Queues named qa and qb. The user has the right to modify tickets
in qa but not in qb. In 3.0 it is possible, to set a link
from a ticket in qa to to a ticket in qb. In 3.6 I get permission
denied, which looks like I have to give the user the right to
modify tickets in qb.
regards!
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.
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 handlingThat’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
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handlingThat’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.Situation:
Two Queues named qa and qb. The user has the right to modify tickets
in qa but not in qb. In 3.0 it is possible, to set a link
from a ticket in qa to to a ticket in qb. In 3.6 I get permission
denied, which looks like I have to give the user the right to
modify tickets in qb.
Okay, I can understand why this was changed but this shows in my opinion
a problem in the rights management. The “ModifyTicket” is not fine
grained enough. I think there is a big difference between the
modification of a subject line or link relation to other tickets
and the ability to close or delete a ticket.
Because the option to change the status, I only give people which
also have the right to take/own tickets in the queue the “ModifyTicket”
right. So it would be very helpful if the “ModifyTicket” could be split
up in “ModifyTicket” and “ModifyTicketStatus”
regards!
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 handlingThat’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
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?
I tend to agree with the OP. It seems to me that links don’t really
exist in tickets, but just as glue to pull multiple tickets together.
Maybe a new right should be added such as (Create|Modify|Delete)Link.
Joshua Colson jcolson@voidgate.org
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?
At Thursday 5/11/2006 10:27 AM, Jesse Vincent wrote:
Hello!
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handlingThat’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
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?
My first preference would be to record the transaction
as the proper user. This could be done by having
Record::_NewTransaction create the transaction but
then switch the current user to RT_System before
$self->_SetLastUpdated if the current user doesn’t have
ModifyTicket.
My second preference would be to record the transaction
as performed by RT_System.
-Todd
Hello!
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handling
3.6.0rc2 should revert this functionality. Want to give it a test?
JEsse
Hello!
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handling3.6.0rc2 should revert this functionality. Want to give it a test?
In rc2 it looked okay. But in 3.6.0 it is like described below. Have I
missed something??
Situation:
Two Queues named qa and qb. The user has the right to modify tickets
in qa but not in qb. In 3.0 it is possible, to set a link
from a ticket in qa to to a ticket in qb. In 3.6 I get permission
denied, which looks like I have to give the user the right to
modify tickets in qb.
best regards!
sven
There was pretty extensive discussion of this on the mailing list, along
with a new configuration file preference.On Thu, Jul 06, 2006 at 05:28:14PM +0200, Sven Sternberger wrote:
Hello!
On Mon, 2006-05-15 at 08:19 -0400, Jesse Vincent wrote:
On Thu, May 11, 2006 at 03:58:11PM +0200, Sven Sternberger wrote:
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handling3.6.0rc2 should revert this functionality. Want to give it a test?
In rc2 it looked okay. But in 3.6.0 it is like described below. Have I
missed something??Situation:
Two Queues named qa and qb. The user has the right to modify tickets
in qa but not in qb. In 3.0 it is possible, to set a link
from a ticket in qa to to a ticket in qb. In 3.6 I get permission
denied, which looks like I have to give the user the right to
modify tickets in qb.best regards!
sven
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.comWe’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions
Look into config for StrictLinkACL option.On 7/6/06, Sven Sternberger sven.sternberger@desy.de wrote:
Hello!
On Mon, 2006-05-15 at 08:19 -0400, Jesse Vincent wrote:
On Thu, May 11, 2006 at 03:58:11PM +0200, Sven Sternberger wrote:
I noticed that ther is a difference between 3.0 and 3.6rc1 in the
access rights handling3.6.0rc2 should revert this functionality. Want to give it a test?
In rc2 it looked okay. But in 3.6.0 it is like described below. Have I
missed something??Situation:
Two Queues named qa and qb. The user has the right to modify tickets
in qa but not in qb. In 3.0 it is possible, to set a link
from a ticket in qa to to a ticket in qb. In 3.6 I get permission
denied, which looks like I have to give the user the right to
modify tickets in qb.best regards!
sven
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.comWe’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions
Best regards, Ruslan.