Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue

> On Feb 23, 2017, at 09:19, Kenneth Marshall <[email protected]> wrote:
> Hi Alex and Robert,
>=20
> 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 <[email protected]> wrote:
>=20
> 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!
>>=20
>> 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.
>>=20
>> Sorry you're running into this, but at the same time, I'm glad to =
know it's not just me. :)=20
>>> On Feb 23, 2017, at 08:13, Robert Blayzor <[email protected]> =
wrote:
>>>=20
>>> 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.
>>>=20
>>>=20
>>> Pretty common function is to change the Owner of the ticket from =
=E2=80=9CNobody=E2=80=9D to the first person to correspond if they are a =
privileged user in RT. The Scrip is below and it does work. (kind of).
>>>=20
>>>=20
>>> What works: When user is first to correspond, Scrip executes and in =
Ticket view the Owner is set as expected.
>>>=20
>>>=20
>>> What doesn=E2=80=99t work: If we go into the queue and list all the =
open tickets, the owner will be listed as =E2=80=9Cnobody=E2=80=9D 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.
>>>=20
>>>=20
>>> Is this just a display bug or are we not using the proper method to =
change the owner of the Ticket?
>>>=20
>>>=20
>>>=20
>>> Here is the Scrip we=E2=80=99ve been using:
>>>=20
>>> # Condition: On correspond
>>> # Action: User Defined
>>> # Template: blank
>>>=20
>>> my $Actor =3D $self->TransactionObj->Creator;
>>> my $Queue =3D $self->TicketObj->QueueObj;
>>>=20
>>> # if actor is RT_SystemUser then get out of here
>>> return 1 if $Actor =3D=3D $RT::SystemUser->id;
>>>=20
>>> # get out unless ticket owner is nobody
>>> return 1 unless $self->TicketObj->Owner =3D=3D $RT::Nobody->id;
>>>=20
>>> # get out unless $Actor is not part of AdminCc watchers
>>> return 1 unless $Queue->IsWatcher(Type =3D> 'AdminCc', PrincipalId =
=3D> $Actor);
>>>=20
>>> # do the actual 'status update'
>>> my ($status, $msg) =3D $self->TicketObj->_Set(Field =3D> 'Owner', =
Value =3D> $Actor, RecordTransaction =3D> 0);
>>> unless( $status ) {
>>> $RT::Logger->warning( "Can't set ticket owner to $Actor: $msg" );
>>> return undef;
>>> }
>>> return 1;
>>>=20
>=20
>=20
> Hi Alex and Robert,
>=20
> 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.
>=20
> Regards,
> Ken