Status changed from Resolved to Open during reply?

Via the web interface for RT 3.2.1 clicking on Reply to a ticket that
is already closed and leaving the Status box at 'resolved (unchanged)'
the ticket will reopen itself after the update.

Any way to stop this behaviour?
I want the ticket to re-open itself if a requester sends in an email
but not if one of our staff is replying to an already resolved ticket.
Am I missing something obvious here?

System is RT 3.2.1
Solaris 9
Apache 1.3.31 w/FastCGI

Thanks.

Any way to stop this behaviour?
I want the ticket to re-open itself if a requester sends in an email
but not if one of our staff is replying to an already resolved ticket.
Am I missing something obvious here?

This has been an annoyance to me since RT 2, but I just live with it.
You have to go back and re-resolve the ticket. The UI never reports
that the ticket status was changed (ie, it happens silently, which is
also an annoyance). It just hasn’t bothered me enough to file a formal
bug.

smime.p7s (2.42 KB)

This has been an annoyance to me since RT 2, but I just live with it.
You have to go back and re-resolve the ticket. The UI never reports
that the ticket status was changed (ie, it happens silently, which is
also an annoyance).

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

This has been an annoyance to me since RT 2, but I just live with it.
You have to go back and re-resolve the ticket. The UI never reports
that the ticket status was changed (ie, it happens silently, which is
also an annoyance).

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

But I think there’s a UI issue. When I correspond and leave the status
as “resolved” two thing’s don’t happen:

  1. it doesn’t leave it resolved (which is arguable as per your note
    above)
  2. it doesn’t indicate that the status was changed on the result screen.

can we make it to somehow fire the on correspond scrip before the
status is checked/set by the ticket update? somehow I doubt it.

Vivek Khera, Ph.D.
+1-301-869-4449 x806

smime.p7s (2.42 KB)

But I think there’s a UI issue. When I correspond and leave the status
as “resolved” two thing’s don’t happen:

  1. it doesn’t leave it resolved (which is arguable as per your note
    above)

You’re not changing it during your update. The system is changing it
after you fire off your update. The UI has never displayed the results
of scrips that are fired on your transactions. It’s not something that’s
on our list to change any time soon.

-J

But I think there’s a UI issue. When I correspond and leave the status
as “resolved” two thing’s don’t happen:

  1. it doesn’t leave it resolved (which is arguable as per your note
    above)

You’re not changing it during your update. The system is changing it
after you fire off your update. The UI has never displayed the
results
of scrips that are fired on your transactions. It’s not something
that’s
on our list to change any time soon.

-J

Like I said, never bothered me enough to file a bug :slight_smile:

smime.p7s (2.42 KB)

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

Yes I do have that scrip active. However even the update screen says
‘Resolved (Unchanged)’ but it does not stay unchanged it moves the
status to open. So currently there is no way to reply to the ticket
and keep it from playing the flip-flop game. The requestor then gets
another ‘Your ticket is resolved’ email from us which I don’t like. I
would have to use a comment instead and CC the requestor which doesn’t
seem right and was not how the original RT worked (We just upgraded
from RT 1.X).

As Vivek mentioned it also doesn’t tell you that it changed the status
in the WebUI it just does it. It seems counter to the ‘Resolved
(Unchanged)’ message shown in the status field and to the logic of the
system.

Kent wrote:

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

Yes I do have that scrip active. However even the update screen says
‘Resolved (Unchanged)’ but it does not stay unchanged it moves the
status to open. So currently there is no way to reply to the ticket
and keep it from playing the flip-flop game. The requestor then gets
another ‘Your ticket is resolved’ email from us which I don’t like. I
would have to use a comment instead and CC the requestor which doesn’t
seem right and was not how the original RT worked (We just upgraded
from RT 1.X).
Change this scrip. As far as I remeber I’ve modified it locally. If
owner of ticket answers then RT doesn’t open ticket. If somebody else
replies then RT open it. That’s all.

As Vivek mentioned it also doesn’t tell you that it changed the status
in the WebUI it just does it. It seems counter to the ‘Resolved
(Unchanged)’ message shown in the status field and to the logic of the
system.
Adjust your scrips. Scrips and Web UI is a little different things.

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

In an effort to fix my logic I have copied AutoOpen.pm to my
local/RT/Action directory and made the following changes to it listed
below. I am trying to make it so a correspondence from the WebUI or
Email does not re-open the ticket if CurrentUser=Owner.

However this does not seem to have any afffect (Yes I stopped/started
my http processes). Any suggestions?

{{{ sub Prepare

sub Prepare {
my $self = shift;

# if the ticket is already open or the ticket is new and the

message is more mail from the
# requestor, don’t reopen it.

if ( ( $self->TicketObj->Status eq 'open' )
     || ( ( $self->TicketObj->Status eq 'new' )
          && $self->TransactionObj->IsInbound )
  ) {

    return undef;
}

#If status is resolved and CurrentUser is Owner don't re-open.
if ( ( $self->TicketObj->Status eq 'resolved' )
     && ( $self->TicketObj->Owner eq $self->TransactionObj->CurrentUser )
  ) {
    return undef;
}

# Fell through to this if none of the above returned.
return (1);

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

In an effort to fix my logic I have copied AutoOpen.pm to my
local/RT/Action directory and made the following changes to it listed
below. I am trying to make it so a correspondence from the WebUI or
Email does not re-open the ticket if CurrentUser=Owner.

I finally figured out the proper syntax for this.
For all those interested here is the change to allow AutoOpen to NOT
open a resolved ticket if the person doing the update is the current
owner. You do need to restart apache after making the changes.

Thanks go to Ruslan and Jesse for pointing me in the right direction.

{{{ sub Prepare

sub Prepare {
my $self = shift;

# if the ticket is already open or the ticket is new and the

message is more mail from the
# requestor, don’t reopen it.
if ( ( $self->TicketObj->Status eq ‘open’ )
|| ( ( $self->TicketObj->Status eq ‘new’ )
&& $self->TransactionObj->IsInbound )
) {

    return undef;
  • } 
    
  • else {
    
  •        return (1);
    
    }
  • #If status is resolved and actor is owner don’t open.
  • if ( ( $self->TicketObj->Status eq ‘resolved’ )
  •     && ( $self->TicketObj->OwnerObj->Name eq
    

&self->TransactionObj->CreatorObj->Name )

  •  ) {
    
  •   return undef;
    
  • }

  • #Nothing matched. Exit OK

  • return (1);
    

}

}}}

Kent wrote:

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

In an effort to fix my logic I have copied AutoOpen.pm to my
local/RT/Action directory and made the following changes to it listed
below. I am trying to make it so a correspondence from the WebUI or
Email does not re-open the ticket if CurrentUser=Owner.

I finally figured out the proper syntax for this.
:slight_smile:
use next
$self->TicketObj->Owner == $self->TransactionObj->Creator
faster and less chances to get error

Because you’ve got an “OnCorrespond, Open ticket” scrip. It’s not done
“in the user’s process”. It’s done by the business logic.

The upgrade process adds back those scrips – has that been changed? It’s very
frustrating that when you upgrade, you get the default scrips. I have to delete
them after every upgrade.

Thanx!

-Sheeri