Closing a ticket

Hi,

when I close a ticket no mail is sent out to the requestor. I’ve checked
that there is a scrip “On Resolve Notify Requestors” with the condition
“on resolve”. This is the case after upgrading from 4.0.x to 4.3.x. How
to fix this?

An other question: What is the difference between “on resolve” and “on
close” in the condition drop down field?

TIA
Matthias

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschï¿œftsfï¿œhrer: Matthias Henze

By default, RT_Config variable $NotifyActors is set to a false value, which
means RT doesn’t send mail to the person that initiated the action. If
you’re resolving a ticket and you’re one of the requestors, you won’t
receive email in this scenario.

If that’s not the problem, is the relevant scrip applied to the correct
queues?

If that’s not the problem, what does RT’s debug log report when you resolve
a ticket?

The “on resolve” condition only matches when a ticket is set to “resolved.”
The “on close” condition matches when a ticket is set to an “inactive”
status (which in a default RT configuration is “resolved” or “rejected”).On 6 August 2014 18:03, Matthias Henze lists@mhcsoftware.de wrote:

Hi,

when I close a ticket no mail is sent out to the requestor. I’ve checked
that there is a scrip “On Resolve Notify Requestors” with the condition
“on resolve”. This is the case after upgrading from 4.0.x to 4.3.x. How
to fix this?

An other question: What is the difference between “on resolve” and “on
close” in the condition drop down field?

TIA
Matthias

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschäftsführer: Matthias Henze


RT Training - Boston, September 9-10
http://bestpractical.com/training

By default, RT_Config variable $NotifyActors is set to a false value,
which means RT doesn’t send mail to the person that initiated the
action. If you’re resolving a ticket and you’re one of the requestors,
you won’t receive email in this scenario.

When I set “$NotifyActors” to 1 the the staff person get a notification
when he takes the ticket. The requestor does not get any auto generated
message but the initial reply for the ticket.

If that’s not the problem, is the relevant scrip applied to the correct
queues?

When I look at the scrips for the queue I can see the scrip for
notification on resolve.

If that’s not the problem, what does RT’s debug log report when you
resolve a ticket?

RT logs when I resolve the ticket and set “Update Type” ot “Comments”
and “Status” to “resolved”, as I was used to with 4.0 where the
requestor got notified that the ticket was closed :

[23619] [Wed Aug 6 09:44:09 2014] [debug]: About to prepare scrips for
transaction #11167 (/opt/rt4/sbin/…/lib/RT/Transaction.pm:187)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Found 5 scrips for
TransactionCreate stage with applicable type(s) Status for txn #11167 on
ticket #637 (/opt/rt4/sbin/…/lib/RT/Scrips.pm:495)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #2 because it
isn’t applicable (/opt/rt4/sbin/…/lib/RT/Scrips.pm:353)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #10 because
it didn’t Prepare (/opt/rt4/sbin/…/lib/RT/Scrips.pm:361)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #12 because
it isn’t applicable (/opt/rt4/sbin/…/lib/RT/Scrips.pm:353)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #13 because
it didn’t Prepare (/opt/rt4/sbin/…/lib/RT/Scrips.pm:361)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: About to commit scrips for
transaction #11167 (/opt/rt4/sbin/…/lib/RT/Transaction.pm:210)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Committing scrip #11 on txn
#11167 of ticket #637 (/opt/rt4/sbin/…/lib/RT/Scrips.pm:306)
[23619] [Wed Aug 6 09:44:09 2014] [warning]: Couldn’t load object
RT::Transaction #0 (/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:3027)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Found 0 scrips for
TransactionBatch stage with applicable type(s) Status for txn #11167 on
ticket #637 (/opt/rt4/sbin/…/lib/RT/Scrips.pm:495)
[23619] [Wed Aug 6 09:44:10 2014] [debug]: Rendering attachment #7820
of ‘text/html’ type
(/opt/rt4/share/html/Elements/ShowTransactionAttachments:182)

The “on resolve” condition only matches when a ticket is set to
“resolved.” The “on close” condition matches when a ticket is set to an
“inactive” status (which in a default RT configuration is “resolved” or
“rejected”).

Hi,

when I close a ticket no mail is sent out to the requestor. I've checked
that there is a scrip "On Resolve Notify Requestors" with the condition
"on resolve". This is the case after upgrading from 4.0.x to 4.3.x. How
to fix this?

An other question: What is the difference between "on resolve" and "on
close" in the condition drop down field?

TIA
Matthias


--

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de <mailto:info@mhcsoftware.de>

HR Coburg: B2242
Geschäftsführer: Matthias Henze



--
RT Training - Boston, September 9-10
http://bestpractical.com/training

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschäftsführer: Matthias Henze

What’s the numeric ID of the scrip responsible for emailing requestors when
a ticket is resolved, and what is its configuration?On 6 August 2014 19:51, Matthias Henze lists@mhcsoftware.de wrote:

Am 06.08.2014 11:20, schrieb Alex Peters:

By default, RT_Config variable $NotifyActors is set to a false value,
which means RT doesn’t send mail to the person that initiated the
action. If you’re resolving a ticket and you’re one of the requestors,
you won’t receive email in this scenario.

When I set “$NotifyActors” to 1 the the staff person get a notification
when he takes the ticket. The requestor does not get any auto generated
message but the initial reply for the ticket.

If that’s not the problem, is the relevant scrip applied to the correct
queues?

When I look at the scrips for the queue I can see the scrip for
notification on resolve.

If that’s not the problem, what does RT’s debug log report when you
resolve a ticket?

RT logs when I resolve the ticket and set “Update Type” ot “Comments”
and “Status” to “resolved”, as I was used to with 4.0 where the
requestor got notified that the ticket was closed :

[23619] [Wed Aug 6 09:44:09 2014] [debug]: About to prepare scrips for
transaction #11167 (/opt/rt4/sbin/…/lib/RT/Transaction.pm:187)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Found 5 scrips for
TransactionCreate stage with applicable type(s) Status for txn #11167 on
ticket #637 (/opt/rt4/sbin/…/lib/RT/Scrips.pm:495)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #2 because it
isn’t applicable (/opt/rt4/sbin/…/lib/RT/Scrips.pm:353)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #10 because
it didn’t Prepare (/opt/rt4/sbin/…/lib/RT/Scrips.pm:361)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #12 because
it isn’t applicable (/opt/rt4/sbin/…/lib/RT/Scrips.pm:353)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #13 because
it didn’t Prepare (/opt/rt4/sbin/…/lib/RT/Scrips.pm:361)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: About to commit scrips for
transaction #11167 (/opt/rt4/sbin/…/lib/RT/Transaction.pm:210)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Committing scrip #11 on txn
#11167 of ticket #637 (/opt/rt4/sbin/…/lib/RT/Scrips.pm:306)
[23619] [Wed Aug 6 09:44:09 2014] [warning]: Couldn’t load object
RT::Transaction #0 (/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:3027)
[23619] [Wed Aug 6 09:44:09 2014] [debug]: Found 0 scrips for
TransactionBatch stage with applicable type(s) Status for txn #11167 on
ticket #637 (/opt/rt4/sbin/…/lib/RT/Scrips.pm:495)
[23619] [Wed Aug 6 09:44:10 2014] [debug]: Rendering attachment #7820
of ‘text/html’ type
(/opt/rt4/share/html/Elements/ShowTransactionAttachments:182)

The “on resolve” condition only matches when a ticket is set to
“resolved.” The “on close” condition matches when a ticket is set to an
“inactive” status (which in a default RT configuration is “resolved” or
“rejected”).

On 6 August 2014 18:03, Matthias Henze <lists@mhcsoftware.de mailto:lists@mhcsoftware.de> wrote:

Hi,

when I close a ticket no mail is sent out to the requestor. I've

checked

that there is a scrip "On Resolve Notify Requestors" with the

condition

"on resolve". This is the case after upgrading from 4.0.x to 4.3.x.

How

to fix this?

An other question: What is the difference between "on resolve" and

"on

close" in the condition drop down field?

TIA
Matthias


--

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de <mailto:info@mhcsoftware.de>

HR Coburg: B2242
Geschäftsführer: Matthias Henze



--
RT Training - Boston, September 9-10
http://bestpractical.com/training

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschäftsführer: Matthias Henze


RT Training - Boston, September 9-10
http://bestpractical.com/training

What’s the numeric ID of the scrip responsible for emailing requestors
when a ticket is resolved, and what is its configuration?

scrip #10

Description: On Resolve Notify Requestors

Condition: On Reslove

Action: Notify Requestor

Template: Resolved

Applies to: Global

Enabled

No “User Defined conditions and results”

What I also miss is an option to just close a ticket (e.g. due to
inactivtiy) without marking it as resoved.

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschäftsführer: Matthias Henze

Your previous log says this about scrip #10:

[23619] [Wed Aug 6 09:44:09 2014] [debug]: Skipping Scrip #10 because it
didn’t Prepare (/opt/rt4/sbin/…/lib/RT/Scrips.pm:361)

which means that the scrip is not running, which explains why requestors
aren’t receiving a “resolved” email. I don’t understand why it’s not
running though, as the definition seems correct.

Did you follow all of the upgrade steps as documented in the README,
including running “make upgrade-database” or “rt-setup-database”?

You can close tickets without marking them as resolved by setting their
status to "rejected."On 6 August 2014 22:07, Matthias Henze lists@mhcsoftware.de wrote:

Am 06.08.2014 um 13:41 schrieb Alex Peters:

What’s the numeric ID of the scrip responsible for emailing requestors
when a ticket is resolved, and what is its configuration?

scrip #10

Description: On Resolve Notify Requestors

Condition: On Reslove

Action: Notify Requestor

Template: Resolved

Applies to: Global

Enabled

No “User Defined conditions and results”

What I also miss is an option to just close a ticket (e.g. due to
inactivtiy) without marking it as resoved.

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschäftsführer: Matthias Henze


RT Training - Boston, September 9-10
http://bestpractical.com/training

Did you follow all of the upgrade steps as documented in the README,
including running “make upgrade-database” or “rt-setup-database”?

Well … I think so … at least the database is upgraded.

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschäftsführer: Matthias Henze

A possible fix is to delete that scrip and recreate it, but I’m not sure
what else to do. If that doesn’t fix it, perhaps the “on resolve”
definition in your database is somehow corrupted. You could possibly use
the rt-setup-database script to re-apply the "initialdata."On 6 August 2014 23:01, Matthias Henze lists@mhcsoftware.de wrote:

Am 06.08.2014 um 14:52 schrieb Alex Peters:

Did you follow all of the upgrade steps as documented in the README,
including running “make upgrade-database” or “rt-setup-database”?

Well … I think so … at least the database is upgraded.

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Geschäftsführer: Matthias Henze


RT Training - Boston, September 9-10
http://bestpractical.com/training

Am 06.08.2014 um 14:52 schrieb Alex Peters:

Did you follow all of the upgrade steps as documented in the README,
including running “make upgrade-database” or “rt-setup-database”?

Well … I think so … at least the database is upgraded.

The only real reason that On Resolve Notify Requestors can fail to
prepare is that the Template fails to parse.

Check that
a)
Nobody has a blank Queue Level template called Resolved which would
disable outgoing mail (common trick on older RTs that have been
upgraded).
b)
The Resolved template exists and is valid (try editing and saving it)

-kevin

Thanks! Found the problem. The template was name - for what reason ever

  • with my username instead of “Resolved”. I renamed it to “Resolved” and
    every thing works as expected. Thanks again!Am 06.08.2014 um 19:01 schrieb Kevin Falcone:

On Wed, Aug 06, 2014 at 03:01:29PM +0200, Matthias Henze wrote:

Am 06.08.2014 um 14:52 schrieb Alex Peters:

Did you follow all of the upgrade steps as documented in the README,
including running “make upgrade-database” or “rt-setup-database”?

Well … I think so … at least the database is upgraded.

The only real reason that On Resolve Notify Requestors can fail to
prepare is that the Template fails to parse.

Check that
a)
Nobody has a blank Queue Level template called Resolved which would
disable outgoing mail (common trick on older RTs that have been
upgraded).
b)
The Resolved template exists and is valid (try editing and saving it)

MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany

voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info@mhcsoftware.de

HR Coburg: B2242
Gesch�ftsf�hrer: Matthias Henze

Thanks! Found the problem. The template was name - for what reason ever

  • with my username instead of “Resolved”. I renamed it to “Resolved” and
    every thing works as expected. Thanks again!

Ok, great. This points to needing a much better error message there.

-kevin