[otrs] Tickets not re-opening on customer reply.

[Atom Powers]

We have been running OTRS for about a month and I think it is the best
OSS ticketing system I've ever used.

Lately it came to my attention that when a customer replies to a "ticket
closed" email the ticket is not re-opened; the customer receives a "your
ticket has been updated" message immediately followed by a "your ticket
has been closed" message. The ticket state remains "resolved" (re-named
from "closed successful"). We are running 3.2.1.

I feel that I've already check all the obvious settings but I must be
missing something. Where else should I be looking?

My Queue is set to "Follow up Option: possible" and
Core::PostMaster::PostmasterFollowUpStateClose -> "open"

Logs indicate the follow up is processed and "ticket closed" message is
sent out immediately following:

Jan 28 09:58:38 support0 OTRS-otrs.PostMaster.pl-3[9663]:
[Notice][Kernel::System::PostMaster::FollowUp::Run] FollowUp Article to
Ticket [3000260] created (TicketID=208, ArticleID=976). ,

Jan 28 09:58:51 support0 OTRS-CGI-3[14733]:
[Notice][Kernel::System::Ticket::Article::ArticleSend] Sent email to
'cust...@digipen.edu' from 'DigiPen Helpdesk <help...@digipen.edu>'.
HistoryType => SendCustomerNotification, Subject => [DP#3000118] Your
HelpDesk request has been closed.;

--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--
Director of IT
DigiPen Institute of Technology
+1 (425) 895-4443
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

[Vadim S. Goncharov]

On 26.02.2013 21:09, Atom Powers wrote:
>
> We have been running OTRS for about a month and I think it is the best OSS
> ticketing system I've ever used.

Having to dig in OTRS code for half a year, I doubt. You situation (see
below) is nice illustration, there are many such things floating around.

> Lately it came to my attention that when a customer replies to a "ticket
> closed" email the ticket is not re-opened; the customer receives a "your
> ticket has been updated" message immediately followed by a "your ticket has
> been closed" message. The ticket state remains "resolved" (re-named from
> "closed successful"). We are running 3.2.1.

Precisely because you've renamed it. The code's one of conditions is:

$Ticket{StateType} =~ /^close/

It is hardcoded (bad programming practice), so you have to rename back or
patch Kernel/System/PostMaster/FollowUp.pm.

> I feel that I've already check all the obvious settings but I must be
> missing something. Where else should I be looking?
>
> My Queue is set to "Follow up Option: possible" and
> Core::PostMaster::PostmasterFollowUpStateClose -> "open"
>
> Logs indicate the follow up is processed and "ticket closed" message is sent
> out immediately following:
>
> Jan 28 09:58:38 support0 OTRS-otrs.PostMaster.pl-3[9663]:
> [Notice][Kernel::System::PostMaster::FollowUp::Run] FollowUp Article to
> Ticket [3000260] created (TicketID=208, ArticleID=976). ,
>
> Jan 28 09:58:51 support0 OTRS-CGI-3[14733]:
> [Notice][Kernel::System::Ticket::Article::ArticleSend] Sent email to
> 'cust...@digipen.edu' from 'DigiPen Helpdesk <help...@digipen.edu>'.
> HistoryType => SendCustomerNotification, Subject => [DP#3000118] Your
> HelpDesk request has been closed.;
>


--

Vadim Goncharov <vgonc...@nic.ru> RU-Center
NET Department http://www.nic.ru
NET-SYS Group phone:+7(495)737-7646 (ext.4019)

[Gerald Young]

The relevant code from Kernel/System/PostMaster/FollowUp.pm

 my $State = $Self->{ConfigObject}->Get('PostmasterFollowUpState') || 'open';

    if (

        $Ticket{StateType} =~ /^close/

        && $Self->{ConfigObject}->Get('PostmasterFollowUpStateClosed')

        )

    {

        $State = $Self->{ConfigObject}->Get('PostmasterFollowUpStateClosed');

    }

    if ( $GetParam{'X-OTRS-FollowUp-State'} ) {

        $State = $GetParam{'X-OTRS-FollowUp-State'};

    }

    if ( $Ticket{StateType} !~ /^new/ || $GetParam{'X-OTRS-FollowUp-State'} ) {

Translation

If "PostmasterFollowupState" is set, it overrides "open", and that's the current value.

If the current state TYPE begins with "close", obey the value in PostmasterFollowupStateClosed, but only if one is set. (resolved can be resolved as long as the state type begins with closed)

If the header or PostmasterFilter sets an X-OTRS-FollowUp-State, that wins.

If the ticket is NOT of StateType that begins with "new" (the state could be named anything) OR X-OTRS-FollowUp-State is set, set the state of either the result of above or the X-OTRS-FollowUp-State 

It will be, in order of processing result:

"open" (or) PostMasterFollowUpState (if set) (unless closed)

PostMasterFollowUpStateClosed (if closed)

(whatever state it is in if the state is "new")

X-OTRS-FollowUp-State (always wins, if set)

It appears you're closing on a notification event or a postmaster filter.

[Atom Powers]

On 02/26/2013 01:14 PM, Gerald Young wrote:
> If "PostmasterFollowupState" is set, it overrides "open", and that's the
> current value.
> If the current state TYPE begins with "close", obey the value in
> PostmasterFollowupStateClosed, but only if one is set. (resolved can be
> resolved as long as the state type begins with closed)
> If the header or PostmasterFilter sets an X-OTRS-FollowUp-State, that wins.
> If the ticket is NOT of StateType that begins with "new" (the state
> could be named anything) OR X-OTRS-FollowUp-State is set, set the state
> of either the result of above or the X-OTRS-FollowUp-State

Thanks.

>
> It appears you're closing on a notification event or a postmaster filter.

I've gone over those and don't see anything about closing a ticket. I
have five PostMaster filters for different queues, none of them close
tickets and two PostMaster filters to ignore junk.

I have two notification events, one to notify the customer when a "note
- external" is created and one when TicketStateUpdate event is becomes
State="resolved".

I don't see how a notification event could keep the ticket closed, the
only options I see are for how and when the notification is sent.

--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--
Director of IT
DigiPen Institute of Technology
+1 (425) 895-4443

[Gerald Young]

can you share a ticket history (in TicketZoom) for a relevant ticket?

[Atom Powers]

Is this what you are looking for? (This is the ticket I'm testing with.)

19 customer – email-external Atom Powers
Re-Open Test 02/26/2013 13:16

20 system – email-external DigiPen Helpdesk
Your HelpDesk request has been updated. 02/26/2013 13:16

21 system – email-notification-ext DigiPen Helpdesk
Your HelpDesk request has been closed 02/26/2013 13:16

On 02/26/2013 01:39 PM, Gerald Young wrote:
> can you share a ticket history (in TicketZoom) for a relevant ticket?
>

[Gerald Young]

There should be additional information in the Admin/System Log about the same time to reflect what happened.

[Atom Powers]

I see a lot of "Can't write [to Cache*]: Permission denied" Errors.
Could that be preventing the ticket state from updating? That seems
unlikely.

---------------
Tue Feb 26 13:16:30 2013 notice OTRS-otrs.PostMaster.pl-3 Sent
customer 'Notify Customer on Ticket Close' notification to
'apo...@digipen.edu'.
Tue Feb 26 13:16:30 2013 notice OTRS-otrs.PostMaster.pl-3 Sent email
to 'apo...@digipen.edu' from 'DigiPen Helpdesk <help...@digipen.edu>'.
HistoryType => SendCustomerNotification, Subject => [DP#3000920] Your
HelpDesk request has been closed.;
Tue Feb 26 13:16:30 2013 error OTRS-otrs.PostMaster.pl-3 Can't write
'/data/webs/helpdesk/otrs/var/tmp/CacheFileStorable/CacheInternalTicket/5/5/5540d594040585be2401dd43af7480c5':
Permission denied
Tue Feb 26 13:16:30 2013 error OTRS-otrs.PostMaster.pl-3 Can't write
'/data/webs/helpdesk/otrs/var/tmp/CacheFileStorable/CacheInternalUser/2/8/28ab988d263314100741dd45cf3a36ec':
Permission denied
Tue Feb 26 13:16:29 2013 notice OTRS-otrs.PostMaster.pl-3 FollowUp
Article to Ticket [3000920] created (TicketID=850, ArticleID=6866). ,
Tue Feb 26 13:16:29 2013 error OTRS-otrs.PostMaster.pl-3 Can't write
'/data/webs/helpdesk/otrs/var/tmp/CacheFileStorable/DynamicField/e/d/ed86045249e6eee50d9bfc1a26adc3d7':
Permission denied
...
Tue Feb 26 13:16:29 2013 error OTRS-otrs.PostMaster.pl-3 Can't write
'/data/webs/helpdesk/otrs/var/tmp/CacheFileStorable/CacheInternalGroup/7/a/7a4de665a450975bfb754c69644aef4a':
Permission denied
Tue Feb 26 13:16:29 2013 notice OTRS-otrs.PostMaster.pl-3 Sent agent
'FollowUp' notification to 'apo...@digipen.edu'.
Tue Feb 26 13:16:28 2013 error OTRS-otrs.PostMaster.pl-3 Can't write
'/data/webs/helpdesk/otrs/var/tmp/CacheFileStorable/CacheInternalUser/b/c/bccca8f9e6278bc47d7371641c3f486d':
Permission denied
Tue Feb 26 13:16:28 2013 notice OTRS-otrs.PostMaster.pl-3 Sent auto
response (SendAutoFollowUp) for Ticket [3000920] (TicketID=850,
ArticleID=6867) to 'Atom Powers <apo...@digipen.edu>'.
Tue Feb 26 13:16:28 2013 notice OTRS-otrs.PostMaster.pl-3 Sent email
to 'Atom Powers <apo...@digipen.edu>' from 'DigiPen Helpdesk
<help...@digipen.edu>'. HistoryType => SendAutoFollowUp, Subject =>
[DP#3000920] Your HelpDesk reques [...];

On 02/26/2013 02:18 PM, Gerald Young wrote:
> There should be additional information in the Admin/System Log about the
> same time to reflect what happened.

[Atom Powers]

One more thing that might be relevant.
Tickets are coming in through the local mail system via an alias:

/etc/aliases
--
helpdesk: "|/data/webs/helpdesk/otrs/bin/otrs.PostMaster.pl -q 'Redmond
HelpDesk' -t 0"

[Atom Powers]

s/might be relevant/is very relevant/

I just tested through the Mail Account interface and it re-opens the
ticket as expected. So what am I doing wrong with the command below?

On 02/26/2013 02:38 PM, Atom Powers wrote:
> One more thing that might be relevant.
> Tickets are coming in through the local mail system via an alias:
>
> /etc/aliases
> --
> helpdesk: "|/data/webs/helpdesk/otrs/bin/otrs.PostMaster.pl -q 'Redmond
> HelpDesk' -t 0"

[Gerald Young]

why not just 

helpdesk: otrs

and do a Postmasterfilter?

[Atom Powers]

I could, and that would probably simply the configuration a bit, but how
would that solve this issue?

On 02/26/2013 03:27 PM, Gerald Young wrote:
> why not just
> helpdesk: otrs
> and do a Postmasterfilter?
>
>
> On Tue, Feb 26, 2013 at 6:21 PM, Atom Powers <apo...@digipen.edu
> <mailto:apo...@digipen.edu>> wrote:
>
> s/might be relevant/is very relevant/
>
> I just tested through the Mail Account interface and it re-opens the
> ticket as expected. So what am I doing wrong with the command below?
>
>
> On 02/26/2013 02:38 PM, Atom Powers wrote:
>
> One more thing that might be relevant.
> Tickets are coming in through the local mail system via an alias:
>
> /etc/aliases
> --

> helpdesk: "|/data/webs/helpdesk/otrs/__bin/otrs.PostMaster.pl
> <http://otrs.PostMaster.pl> -q 'Redmond

[Gerald Young]

-t 0 says don't trust the headers. 

That's about it.

[Atom Powers]

I tested without "-t 0" and through a mail pipe (postfix, in master.cf)
and neither had any effect. I fixed the ACL issue on the tmp directory
by moving/linking it into a tmpfs mount and now it will re-open tickets
as expected.

I'm not sure how an error writing a temporary file would affect how the
ticket state changes, but that seems to have been the issue.

On 02/26/2013 04:36 PM, Gerald Young wrote:
> -t 0 says don't trust the headers.
> That's about it.
>

> On 02/26/2013 03:27 PM, Gerald Young wrote:
>
> why not just
> helpdesk: otrs
> and do a Postmasterfilter?
>

[Michiel Beijen]

Hi Vadim,

On Tue, Feb 26, 2013 at 8:48 PM, Vadim S. Goncharov <vgonc...@nic.ru> wrote:

>> Lately it came to my attention that when a customer replies to a "ticket
>> closed" email the ticket is not re-opened; the customer receives a "your
>> ticket has been updated" message immediately followed by a "your ticket has
>> been closed" message. The ticket state remains "resolved" (re-named from
>> "closed successful"). We are running 3.2.1.
>
>
> Precisely because you've renamed it. The code's one of conditions is:
>
> $Ticket{StateType} =~ /^close/
>
> It is hardcoded (bad programming practice), so you have to rename back or patch Kernel/System/PostMaster/FollowUp.pm.

I'm sorry but here you see the state TYPE, not the state. You can
rename states all you want, you'll need to update the configuration,
but you need not mess with the code.
State TYPES are different and you should not rename them; you can not
do that without direct DB access anyway, they are internal and they
are never displayed to users.

--
Mike

[David Boyes]

One reason: by using an alias and processing the stuff immediately as it comes in, he doesn’t have any exposure to DOS attacks on an actual userid on the system with the potential to fill /var/mail before the postmaster filter runs, and it increases the responsiveness of the system as a whole (with the postmaster filter, your reaction time to a incoming ticket can be no shorter than the period of the postmaster filter runs, which may be significant for some providers). His approach runs in real time.

 

This using polling for POP/IMAP mailboxes may be necessary for Windows systems, but it’s icky in a system that can do better.

[Vadim S. Goncharov]

On 27.02.2013 13:07, Michiel Beijen wrote:
> Hi Vadim,
>
> On Tue, Feb 26, 2013 at 8:48 PM, Vadim S. Goncharov<vgonc...@nic.ru> wrote:
>
>>> Lately it came to my attention that when a customer replies to a "ticket
>>> closed" email the ticket is not re-opened; the customer receives a "your
>>> ticket has been updated" message immediately followed by a "your ticket has
>>> been closed" message. The ticket state remains "resolved" (re-named from
>>> "closed successful"). We are running 3.2.1.
>>
>>
>> Precisely because you've renamed it. The code's one of conditions is:
>>
>> $Ticket{StateType} =~ /^close/
>>
>> It is hardcoded (bad programming practice), so you have to rename back or patch Kernel/System/PostMaster/FollowUp.pm.
>
> I'm sorry but here you see the state TYPE, not the state. You can
> rename states all you want, you'll need to update the configuration,
> but you need not mess with the code.
> State TYPES are different and you should not rename them; you can not
> do that without direct DB access anyway, they are internal and they
> are never displayed to users.

Sorry, missed that (was reading that briefly another day for another
problem, just remembered the place), so has given wrong answer.

There are many hardcoded things in OTRS, still.

--
Vadim Goncharov <vgonc...@nic.ru> RU-Center
NET Department http://www.nic.ru
NET-SYS Group phone:+7(495)737-7646 (ext.4019)

[Gerald Young]

Vadim, 

If you have proof, show it.

[Vadim S. Goncharov]

On 01.03.2013 17:40, Gerald Young wrote:
> Vadim,
>
> If you have proof, show it.

Hopefully these examples are enough:

my $Line = 2500;

$Data{Body} .= "<br/>---- $EndForwardedMessage ---<br/>";

$Ticket{CreateBy} = $Row[27];
$Ticket{ArchiveFlag} = $Row[26] ? 'y' : 'n';
$Ticket{Changed} = $Row[16];

the whole TicketFreeKey[1-16] (replaced with dynamic, finally)

elsif ( $Row[0] =~ /^Ticket moved to Queue '.+?' \(ID=(.+?)\)/ ) {

$Param{Name} = substr( $Param{Name}, 0, 200 );

elsif ( substr( $Item, 0, 8 ) eq '[RegExp]' ) {

CompanyTickets => {
All => {
Name => 'All',
Prio => 1000,

$Param{SLAStrg} = $Self->{LayoutObject}->BuildSelection(
Max => 200,

$Param{$_} = substr( $Param{$_}, 0, 3800 );


# undocumented mentioned in bug#8953:
if (
$UserData{UserSendFollowUpNotification}
&& $UserData{UserSendFollowUpNotification} == 2

( $File{Filename} =~ /^file-[12]$/ || $File{Filename} eq 'file-1.html' )

sub CustomerSearch {
for my $Count ( '', 1 .. 10 ) {

if ( $Param{NewLine} && length( ${$Text} ) < 140_000 ) {

my $Key = sprintf( "%07d", $Item->{Prio} );
for ( 1 .. 51 ) {
last if !$NavBarModule{$Key};

if ( $Self->{ArticleFilter} ) {
$HighlightStyle = 'PriorityID-5';


that's far from complete list, of course.