Mailing List Archive: RT 4.4.1 - Change owner on corrospond Scrip

RT 4.4.1 - Change owner on corrospond Scrip - Strange issue

Feb 23, 2017, 5:13 AM

Post #1 of 9 (5308 views)

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;

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

ahall at autodist

Feb 23, 2017, 5:51 AM

Post #2 of 9 (5308 views)

Permalink

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;
>
>
>
>
>
>
>
>
>
>

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

ktm at rice

Feb 23, 2017, 6:19 AM

Post #3 of 9 (5308 views)

Permalink

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. :)
> > 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

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

ahall at autodist

Feb 23, 2017, 6:23 AM

Post #4 of 9 (5307 views)

Permalink

> On Feb 23, 2017, at 09:19, 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'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. :)
>>> 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

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

rblayzor.bulk at inoc

Feb 23, 2017, 7:12 AM

Post #5 of 9 (5307 views)

Permalink

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.

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

ktm at rice

Feb 23, 2017, 7:38 AM

Post #6 of 9 (5307 views)

Permalink

On Thu, Feb 23, 2017 at 10:12:19AM -0500, Robert Blayzor wrote:
> 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

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

shawn at bestpractical

Feb 23, 2017, 9:06 AM

Post #7 of 9 (5301 views)

Permalink

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

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

ahall at autodist

Feb 23, 2017, 10:10 AM

Post #8 of 9 (5301 views)

Permalink

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

Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue [ In reply to ]

rblayzor.bulk at inoc

Feb 23, 2017, 11:16 AM

Post #9 of 9 (5301 views)

Permalink

On Feb 23, 2017, at 12:06 PM, Shawn M Moore <shawn@bestpractical.com> wrote:
>
>> # 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