Status of Steal Ticket feature?

Hello,

I’ve set my users with global superuser permissions, but for some
reason this wasn’t enough to own a ticket. I set them with own
permissions, and now they can be assigned tickets.

Thinking this bug also applied to stealing a ticket, I set these
users with take + steal ticket abilities globally, yet they still
cannot steal. Any theories why this is?

I did search the archive, but came up short in finding an answer…

Joe Auty
UITS Messaging
Indiana University
jauty@indiana.edu

PGP.sig (186 Bytes)

Hello,

I’ve set my users with global superuser permissions, but for some
reason this wasn’t enough to own a ticket. I set them with own
permissions, and now they can be assigned tickets.

Thinking this bug also applied to stealing a ticket, I set these
users with take + steal ticket abilities globally, yet they still
cannot steal. Any theories why this is?

I did search the archive, but came up short in finding an answer…

Here is a patch against 3.6.0pre1 to enable users who have the SuperUser
right to take ownership of a ticket.

Copy html/Elements/SelectOwner to local/html/Elements/SelectOwner and
then patch the local copy with the attached patch.

Joshua Colson jcolson@voidgate.org

SelectOwner.patch (690 Bytes)

Hello,

I’ve set my users with global superuser permissions, but for some
reason this wasn’t enough to own a ticket. I set them with own
permissions, and now they can be assigned tickets.

I can confirm this also. I have a SuperUser (using RT 3.6) who is unable
to take ownership of a ticket. If I assign the OwnTicket right to the
user then it works. I just hadn’t gotten around to digging deeper for
(what I’m assuming is) a bug.

Joshua Colson jcolson@voidgate.org

Sorry, I meant to say that I also added OwnTicket ability and it
still didn’t work… Steal + Own + Take - still doesn’t work =(On May 17, 2006, at 5:54 PM, Joby Walker wrote:

Having StealTicket does not imply OwnTicket – just like TakeTicket
doesn’t imply OwnTicket. All steal grants is the ability to revoke
another’s ownership of a ticket. You need to add OwnTicket.

The SuperUser issue is completely seperate. The SelectOwner widget
only
includes those with OwnTicket. It can be easily set to include
SuperUsers. Most implementations don’t want the SuperUsers to be
listed
in all of the SetOwner lists – I certainly don’t want my userid
unnecessarily increasing the size of of the select list.

Joby Walker
C&C SSG, University of Washington

Joe Auty wrote:

Hello,

I’ve set my users with global superuser permissions, but for some
reason this wasn’t enough to own a ticket. I set them with own
permissions, and now they can be assigned tickets.

Thinking this bug also applied to stealing a ticket, I set these
users
with take + steal ticket abilities globally, yet they still cannot
steal. Any theories why this is?

I did search the archive, but came up short in finding an answer…


Joe Auty
UITS Messaging
Indiana University
jauty@indiana.edu




http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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

We’re hiring! Come hack Perl for Best Practical: http://
bestpractical.com/about/jobs.html

From the UPGRADING file in the distribution:

UPGRADING FROM 3.5.7 and earlier - Changes:

Scrips are now prepared and committed in order alphanumerically by
description.
This means that you can prepend a number (00, 07, 15, 24) to the
beginning of
each scrip’s description, and they will run in that order. Depending
on your
database, the old ordering may have been by scrip id number – if
that is the
case, simply prepend the scrip id number to the beginning of its
description.

UPGRADING FROM 3.5.1 and earlier - Changes:

The default for $RedistributeAutoGeneratedMessages has changed to
’privileged’, to make out-of-the-box installations more resistant
to mail loops. If you rely on the old default of redistributing to
all watchers, you’ll need to set it explicitly now.

UPGRADING FROM 3.3.14 and earlier - Changes:

The “ModifyObjectCustomFieldValues” right name was too long. It’s
been changed to
"ModifyCustomField"

UPGRADING FROM 3.3.11 and earlier - Changes:

= Rights Changes =

Custom Fields now have an additional right “ModifyCustomField”.
This right governs whether a user can modify an object’s custom field
values
for a particular custom field. This includes adding, deleting and
changing values.

UPGRADING FROM 3.2 and earlier - Changes:

= Rights changes =

Now, if you want any user to be able to access the Admin tools (a.k.a.
the Configuration tab), you must grant that user the "ShowConfigTab"
right. Making the user a privileged user is no longer sufficient.

“SuperUser” users are no longer automatically added to the list of
users who can own tickets in a queue. You now need to explicitly give
them t
he “own tickets” right.On May 17, 2006, at 5:23 PM, Joshua Colson wrote:

On Wed, 2006-05-17 at 17:16 -0400, Joe Auty wrote:

Hello,

I’ve set my users with global superuser permissions, but for some
reason this wasn’t enough to own a ticket. I set them with own
permissions, and now they can be assigned tickets.

I can confirm this also. I have a SuperUser (using RT 3.6) who is
unable
to take ownership of a ticket. If I assign the OwnTicket right to the
user then it works. I just hadn’t gotten around to digging deeper for
(what I’m assuming is) a bug.


Joshua Colson jcolson@voidgate.org


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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

We’re hiring! Come hack Perl for Best Practical: http://
bestpractical.com/about/jobs.html

Thanks for this!

Unfortunately, I’ve given my users own, steal, and take abilities and
while I can claim ownership on a ticket, I cannot steal one…

Any ideas?On May 17, 2006, at 7:34 PM, Jesse Vincent wrote:

From the UPGRADING file in the distribution:


UPGRADING FROM 3.5.7 and earlier - Changes:

Scrips are now prepared and committed in order alphanumerically by
description.
This means that you can prepend a number (00, 07, 15, 24) to the
beginning of
each scrip’s description, and they will run in that order.
Depending on your
database, the old ordering may have been by scrip id number – if
that is the
case, simply prepend the scrip id number to the beginning of its
description.

UPGRADING FROM 3.5.1 and earlier - Changes:

The default for $RedistributeAutoGeneratedMessages has changed to
’privileged’, to make out-of-the-box installations more resistant
to mail loops. If you rely on the old default of redistributing to
all watchers, you’ll need to set it explicitly now.

UPGRADING FROM 3.3.14 and earlier - Changes:

The “ModifyObjectCustomFieldValues” right name was too long. It’s
been changed to
"ModifyCustomField"

UPGRADING FROM 3.3.11 and earlier - Changes:

= Rights Changes =

Custom Fields now have an additional right “ModifyCustomField”.
This right governs whether a user can modify an object’s custom
field values
for a particular custom field. This includes adding, deleting and
changing values.

UPGRADING FROM 3.2 and earlier - Changes:

= Rights changes =

Now, if you want any user to be able to access the Admin tools (a.k.a.
the Configuration tab), you must grant that user the "ShowConfigTab"
right. Making the user a privileged user is no longer sufficient.

“SuperUser” users are no longer automatically added to the list of
users who can own tickets in a queue. You now need to explicitly
give them t
he “own tickets” right.

On May 17, 2006, at 5:23 PM, Joshua Colson wrote:

On Wed, 2006-05-17 at 17:16 -0400, Joe Auty wrote:

Hello,

I’ve set my users with global superuser permissions, but for some
reason this wasn’t enough to own a ticket. I set them with own
permissions, and now they can be assigned tickets.

I can confirm this also. I have a SuperUser (using RT 3.6) who is
unable
to take ownership of a ticket. If I assign the OwnTicket right to the
user then it works. I just hadn’t gotten around to digging deeper for
(what I’m assuming is) a bug.


Joshua Colson jcolson@voidgate.org


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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

We’re hiring! Come hack Perl for Best Practical: http://
bestpractical.com/about/jobs.html

Having StealTicket does not imply OwnTicket – just like TakeTicket
doesn’t imply OwnTicket. All steal grants is the ability to revoke
another’s ownership of a ticket. You need to add OwnTicket.

The SuperUser issue is completely seperate. The SelectOwner widget only
includes those with OwnTicket. It can be easily set to include
SuperUsers. Most implementations don’t want the SuperUsers to be listed
in all of the SetOwner lists – I certainly don’t want my userid
unnecessarily increasing the size of of the select list.

Joby Walker
C&C SSG, University of Washington

Joe Auty wrote:

Am 17.05.2006 23:23 Uhr schrieb “Joshua Colson” unter
jcolson@voidgate.org:

I can confirm this also. I have a SuperUser (using RT 3.6) who is unable
to take ownership of a ticket. If I assign the OwnTicket right to the
user then it works. I just hadn’t gotten around to digging deeper for
(what I’m assuming is) a bug.

It’s a feature. The SuperUser has all rights regarding management of the
system, but not regarding working on tickets. This is a documented
functional change.

Regards,
Harald

Harald Wagener
Technischer Leiter

Foote Cone & Belding
FCB Wilkens
An der Alster 42
20099 Hamburg
Germany

T: +49 (0)40 2881 1252
F: +49 (0)40 2881 1217
hwagener@hamburg.fcb.com

http://www.footeconebelding.de

Solved this problem…

I suck. I was trying to steal the ticket by reassigning it within the
"owner" pull-down. It doesn’t work here, but that big old "steal"
link at the top of the screen works just fine… =)

I’d fine this as a bug, but not earth shattering in severity.On May 17, 2006, at 7:38 PM, Joe Auty wrote:

Thanks for this!

Unfortunately, I’ve given my users own, steal, and take abilities
and while I can claim ownership on a ticket, I cannot steal one…

Any ideas?

On May 17, 2006, at 7:34 PM, Jesse Vincent wrote:

From the UPGRADING file in the distribution:


UPGRADING FROM 3.5.7 and earlier - Changes:

Scrips are now prepared and committed in order alphanumerically by
description.
This means that you can prepend a number (00, 07, 15, 24) to the
beginning of
each scrip’s description, and they will run in that order.
Depending on your
database, the old ordering may have been by scrip id number – if
that is the
case, simply prepend the scrip id number to the beginning of its
description.

UPGRADING FROM 3.5.1 and earlier - Changes:

The default for $RedistributeAutoGeneratedMessages has changed to
’privileged’, to make out-of-the-box installations more resistant
to mail loops. If you rely on the old default of redistributing to
all watchers, you’ll need to set it explicitly now.

UPGRADING FROM 3.3.14 and earlier - Changes:

The “ModifyObjectCustomFieldValues” right name was too long. It’s
been changed to
"ModifyCustomField"

UPGRADING FROM 3.3.11 and earlier - Changes:

= Rights Changes =

Custom Fields now have an additional right “ModifyCustomField”.
This right governs whether a user can modify an object’s custom
field values
for a particular custom field. This includes adding, deleting and
changing values.

UPGRADING FROM 3.2 and earlier - Changes:

= Rights changes =

Now, if you want any user to be able to access the Admin tools
(a.k.a.
the Configuration tab), you must grant that user the "ShowConfigTab"
right. Making the user a privileged user is no longer sufficient.

“SuperUser” users are no longer automatically added to the list of
users who can own tickets in a queue. You now need to explicitly
give them t
he “own tickets” right.

On May 17, 2006, at 5:23 PM, Joshua Colson wrote:

On Wed, 2006-05-17 at 17:16 -0400, Joe Auty wrote:

Hello,

I’ve set my users with global superuser permissions, but for some
reason this wasn’t enough to own a ticket. I set them with own
permissions, and now they can be assigned tickets.

I can confirm this also. I have a SuperUser (using RT 3.6) who is
unable
to take ownership of a ticket. If I assign the OwnTicket right to
the
user then it works. I just hadn’t gotten around to digging deeper
for
(what I’m assuming is) a bug.


Joshua Colson jcolson@voidgate.org


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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

We’re hiring! Come hack Perl for Best Practical: http://
bestpractical.com/about/jobs.html


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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

We’re hiring! Come hack Perl for Best Practical: http://
bestpractical.com/about/jobs.html

Joe Auty
UITS Messaging
Indiana University
jauty@indiana.edu