RT 4.4.1 - Change owner on corrospond Scrip - Strange issue

Running RT 4.4.1 - running fine for years and probably never noticed this before. We have a Scrip that runs that probably carried over from the pre-RT4 days.

Pretty common function is to change the Owner of the ticket from “Nobody” to the first person to correspond if they are a privileged user in RT. The Scrip is below and it does work. (kind of).

What works: When user is first to correspond, Scrip executes and in Ticket view the Owner is set as expected.

What doesn’t work: If we go into the queue and list all the open tickets, the owner will be listed as “nobody” in this view, but if you open the ticket, there is an owner. If you change the owner to someone else and change it back, then it seems to fix this issue.

Is this just a display bug or are we not using the proper method to change the owner of the Ticket?

Here is the Scrip we’ve been using:

Condition: On correspond

Action: User Defined

Template: blank

my $Actor = $self->TransactionObj->Creator;
my $Queue = $self->TicketObj->QueueObj;

if actor is RT_SystemUser then get out of here

return 1 if $Actor == $RT::SystemUser->id;

get out unless ticket owner is nobody

return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;

get out unless $Actor is not part of AdminCc watchers

return 1 unless $Queue->IsWatcher(Type => ‘AdminCc’, PrincipalId => $Actor);

do the actual ‘status update’

my ($status, $msg) = $self->TicketObj->_Set(Field => ‘Owner’, Value => $Actor, RecordTransaction => 0);
unless( $status ) {
$RT::Logger->warning( “Can’t set ticket owner to $Actor: $msg” );
return undef;
}
return 1;

I’m going to send the email I normally hate to receive. If you ever figure this out, please share it with the list!

I have a script to assign the ticket creator as the owner on creation, which works perfectly. Like you, though, the owner fails to display properly in ticket lists but works if you open a ticket. This has annoyed all our staff for months, but when I asked about on this list, we couldn’t work out what the problem was.

Sorry you’re running into this, but at the same time, I’m glad to know it’s not just me. :)> On Feb 23, 2017, at 08:13, Robert Blayzor rblayzor.bulk@inoc.net wrote:

Running RT 4.4.1 - running fine for years and probably never noticed this before. We have a Scrip that runs that probably carried over from the pre-RT4 days.

Pretty common function is to change the Owner of the ticket from “Nobody” to the first person to correspond if they are a privileged user in RT. The Scrip is below and it does work. (kind of).

What works: When user is first to correspond, Scrip executes and in Ticket view the Owner is set as expected.

What doesn’t work: If we go into the queue and list all the open tickets, the owner will be listed as “nobody” in this view, but if you open the ticket, there is an owner. If you change the owner to someone else and change it back, then it seems to fix this issue.

Is this just a display bug or are we not using the proper method to change the owner of the Ticket?

Here is the Scrip we’ve been using:

Condition: On correspond

Action: User Defined

Template: blank

my $Actor = $self->TransactionObj->Creator;
my $Queue = $self->TicketObj->QueueObj;

if actor is RT_SystemUser then get out of here

return 1 if $Actor == $RT::SystemUser->id;

get out unless ticket owner is nobody

return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;

get out unless $Actor is not part of AdminCc watchers

return 1 unless $Queue->IsWatcher(Type => ‘AdminCc’, PrincipalId => $Actor);

do the actual ‘status update’

my ($status, $msg) = $self->TicketObj->_Set(Field => ‘Owner’, Value => $Actor, RecordTransaction => 0);
unless( $status ) {
$RT::Logger->warning( “Can’t set ticket owner to $Actor: $msg” );
return undef;
}
return 1;

I’m going to send the email I normally hate to receive. If you ever figure this out, please share it with the list!

I have a script to assign the ticket creator as the owner on creation, which works perfectly. Like you, though, the owner fails to display properly in ticket lists but works if you open a ticket. This has annoyed all our staff for months, but when I asked about on this list, we couldn’t work out what the problem was.

Sorry you’re running into this, but at the same time, I’m glad to know it’s not just me. :slight_smile:

Running RT 4.4.1 - running fine for years and probably never noticed this before. We have a Scrip that runs that probably carried over from the pre-RT4 days.

Pretty common function is to change the Owner of the ticket from “Nobody” to the first person to correspond if they are a privileged user in RT. The Scrip is below and it does work. (kind of).

What works: When user is first to correspond, Scrip executes and in Ticket view the Owner is set as expected.

What doesn’t work: If we go into the queue and list all the open tickets, the owner will be listed as “nobody” in this view, but if you open the ticket, there is an owner. If you change the owner to someone else and change it back, then it seems to fix this issue.

Is this just a display bug or are we not using the proper method to change the owner of the Ticket?

Here is the Scrip we’ve been using:

Condition: On correspond

Action: User Defined

Template: blank

my $Actor = $self->TransactionObj->Creator;
my $Queue = $self->TicketObj->QueueObj;

if actor is RT_SystemUser then get out of here

return 1 if $Actor == $RT::SystemUser->id;

get out unless ticket owner is nobody

return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;

get out unless $Actor is not part of AdminCc watchers

return 1 unless $Queue->IsWatcher(Type => ‘AdminCc’, PrincipalId => $Actor);

do the actual ‘status update’

my ($status, $msg) = $self->TicketObj->_Set(Field => ‘Owner’, Value => $Actor, RecordTransaction => 0);
unless( $status ) {
$RT::Logger->warning( “Can’t set ticket owner to $Actor: $msg” );
return undef;
}
return 1;

Hi Alex and Robert,

What happens if you set RecordTransaction to 1/true? I have not checked the code,
but I would imagine that if you do not record the transaction, the cache infrastructure
would not invalidate the old entry and would continue to serve stale data. Something
to try perhaps.

Regards,
Ken

Hi Alex and Robert,

What happens if you set RecordTransaction to 1/true? I have not checked the code,
but I would imagine that if you do not record the transaction, the cache infrastructure
would not invalidate the old entry and would continue to serve stale data. Something
to try perhaps.
I’ve tried both, and neither made a difference as far as I remember.> On Feb 23, 2017, at 09:19, Kenneth Marshall ktm@rice.edu wrote:

On Thu, Feb 23, 2017 at 08:51:29AM -0500, Alex Hall wrote:

I’m going to send the email I normally hate to receive. If you ever figure this out, please share it with the list!

I have a script to assign the ticket creator as the owner on creation, which works perfectly. Like you, though, the owner fails to display properly in ticket lists but works if you open a ticket. This has annoyed all our staff for months, but when I asked about on this list, we couldn’t work out what the problem was.

Sorry you’re running into this, but at the same time, I’m glad to know it’s not just me. :slight_smile:

On Feb 23, 2017, at 08:13, Robert Blayzor rblayzor.bulk@inoc.net wrote:

Running RT 4.4.1 - running fine for years and probably never noticed this before. We have a Scrip that runs that probably carried over from the pre-RT4 days.

Pretty common function is to change the Owner of the ticket from “Nobody” to the first person to correspond if they are a privileged user in RT. The Scrip is below and it does work. (kind of).

What works: When user is first to correspond, Scrip executes and in Ticket view the Owner is set as expected.

What doesn’t work: If we go into the queue and list all the open tickets, the owner will be listed as “nobody” in this view, but if you open the ticket, there is an owner. If you change the owner to someone else and change it back, then it seems to fix this issue.

Is this just a display bug or are we not using the proper method to change the owner of the Ticket?

Here is the Scrip we’ve been using:

Condition: On correspond

Action: User Defined

Template: blank

my $Actor = $self->TransactionObj->Creator;
my $Queue = $self->TicketObj->QueueObj;

if actor is RT_SystemUser then get out of here

return 1 if $Actor == $RT::SystemUser->id;

get out unless ticket owner is nobody

return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;

get out unless $Actor is not part of AdminCc watchers

return 1 unless $Queue->IsWatcher(Type => ‘AdminCc’, PrincipalId => $Actor);

do the actual ‘status update’

my ($status, $msg) = $self->TicketObj->_Set(Field => ‘Owner’, Value => $Actor, RecordTransaction => 0);
unless( $status ) {
$RT::Logger->warning( “Can’t set ticket owner to $Actor: $msg” );
return undef;
}
return 1;

Hi Alex and Robert,

What happens if you set RecordTransaction to 1/true? I have not checked the code,
but I would imagine that if you do not record the transaction, the cache infrastructure
would not invalidate the old entry and would continue to serve stale data. Something
to try perhaps.

Regards,
Ken

I did try that, and it literally did nothing. (other than recorded the change in the ticket and created empty emails to requestors)

This has been very easy to re-produce and there must be some different way the Owner is pulled in the Queue view vs. actual ticket view. It is annoying as we have people pulling the queue list of tickets looking for unowned tickets which do not appear on the dashboard, but they do in queue view.

Even if I do a custom query for unowned tickets, they do not show up; yet in queue view it still shows them unowned.

inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu> On Feb 23, 2017, at 9:19 AM, Kenneth Marshall ktm@rice.edu wrote:

Hi Alex and Robert,

What happens if you set RecordTransaction to 1/true? I have not checked the code,
but I would imagine that if you do not record the transaction, the cache infrastructure
would not invalidate the old entry and would continue to serve stale data. Something
to try perhaps.

I did try that, and it literally did nothing. (other than recorded the change in the ticket and created empty emails to requestors)

This has been very easy to re-produce and there must be some different way the Owner is pulled in the Queue view vs. actual ticket view. It is annoying as we have people pulling the queue list of tickets looking for unowned tickets which do not appear on the dashboard, but they do in queue view.

Even if I do a custom query for unowned tickets, they do not show up; yet in queue view it still shows them unowned.

Hi,

We are still working on our 4.4.1 upgrade so I do not yet have a place to
reproduce your problem. Enabling SQL and RT debugging would be the next
option.

Regards,
Ken

Hey Robert, Alex,

Is this just a display bug or are we not using the proper method to change the owner of the Ticket?

You’re not using the proper method.

do the actual ‘status update’

my ($status, $msg) = $self->TicketObj->_Set(Field => ‘Owner’, Value => $Actor, RecordTransaction => 0);

Should instead be:

my ($status, $msg) = $self->TicketObj->SetOwner($Actor);

What works: When user is first to correspond, Scrip executes and in Ticket view the Owner is set as expected.

What doesn’t work: If we go into the queue and list all the open tickets, the owner will be listed as “nobody” in this view, but if you open the ticket, there is an owner. If you change the owner to someone else and change it back, then it seems to fix this issue.

The reason you need to use SetOwner is that the owner of a ticket is represented in two different database tables. The first is in the GroupMembers table, alongside Requestors, Ccs, and AdminCcs, and custom roles. This is what provides features like permissions. It’s also what’s used when you display the “Owner” column in search results. Tickets also store their owner denormalized in the tickets table. This is used in, among other places, displaying the owner on ticket display, and in email notifications.

->Set(Field => ‘Owner’) only updates the latter. ->SetOwner updates both.

This explains the inconsistencies you’re seeing. Please try switching your scrip to ->SetOwner and seeing if it helps for tickets going forward. For existing tickets with this problem, you’ll need to address the consistency issue.

It turns out that, for different reasons entirely ( https://issues.bestpractical.com/Ticket/Display.html?id=32381 https://issues.bestpractical.com/Ticket/Display.html?id=32381 ), RT 4.4.2 adds an upgrade step and an rt-validator rule that detects and fixes such inconsistencies. You can find them here:

https://github.com/bestpractical/rt/commit/58bacce6ada754657c7f56fd91f20c573108c1ab https://github.com/bestpractical/rt/commit/58bacce6ada754657c7f56fd91f20c573108c1ab
https://github.com/bestpractical/rt/commit/20d8daf6855e3c53ee8a79d68271941d4cdca159 https://github.com/bestpractical/rt/commit/20d8daf6855e3c53ee8a79d68271941d4cdca159

Best,
Shawn

Thank you! This seems to be doing the right thing, while still not
notifying the user of the change. It’s exactly what I was hoping for. It
felt great to close the ticket my boss made on this issue back in November!On Thu, Feb 23, 2017 at 12:06 PM, Shawn M Moore shawn@bestpractical.com wrote:

Hey Robert, Alex,

Is this just a display bug or are we not using the proper method to change
the owner of the Ticket?

You’re not using the proper method.

do the actual ‘status update’

my ($status, $msg) = $self->TicketObj->_Set(Field => ‘Owner’, Value =>
$Actor, RecordTransaction => 0);

Should instead be:

my ($status, $msg) = $self->TicketObj->SetOwner($Actor);

What works: When user is first to correspond, Scrip executes and in Ticket
view the Owner is set as expected.

What doesn’t work: If we go into the queue and list all the open tickets,
the owner will be listed as “nobody” in this view, but if you open the
ticket, there is an owner. If you change the owner to someone else and
change it back, then it seems to fix this issue.

The reason you need to use SetOwner is that the owner of a ticket is
represented in two different database tables. The first is in the
GroupMembers table, alongside Requestors, Ccs, and AdminCcs, and custom
roles. This is what provides features like permissions. It’s also what’s
used when you display the “Owner” column in search results. Tickets also
store their owner denormalized in the tickets table. This is used in, among
other places, displaying the owner on ticket display, and in email
notifications.

->Set(Field => ‘Owner’) only updates the latter. ->SetOwner updates both.

This explains the inconsistencies you’re seeing. Please try switching your
scrip to ->SetOwner and seeing if it helps for tickets going forward. For
existing tickets with this problem, you’ll need to address the consistency
issue.

It turns out that, for different reasons entirely (
https://issues.bestpractical.com/Ticket/Display.html?id=32381 ), RT 4.4.2
adds an upgrade step and an rt-validator rule that detects and fixes such
inconsistencies. You can find them here:

https://github.com/bestpractical/rt/commit/58bacce6ada754657c7f56fd91f20c
573108c1ab
https://github.com/bestpractical/rt/commit/20d8daf6855e3c53ee8a79d6827194
1d4cdca159

Best,
Shawn

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

do the actual ‘status update’

my ($status, $msg) = $self->TicketObj->_Set(Field => ‘Owner’, Value => $Actor, RecordTransaction => 0);

Should instead be:

my ($status, $msg) = $self->TicketObj->SetOwner($Actor);

That most certainly works and fixes the problem, but with one side affect was hoping to a avoid. When the owner is changed it sends out a notification email to the new owner. Obviously by design and handy in most cases. In this case however, the person corresponding first pretty much knows they will be set owner by replying first. I think the notification email back is just generating noise at this point. If there is an easy option in the method to address this, fine, if not we’ll deal with it.

inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu