We’re currently running RT 4.0.12. I can’t work out why this would be happening at all
Please can someone help me out?
Thanks in advance,
Samuel (OrangutanClyde)
A straight-up RT 4.0.13 install should yield this in the Subject: line
Notice all the backslashes that you’re missing?
In particular, [Comment] becoming [Comment] means the code will
remove any C, o, m, e, n or t from the Subject on Comments.
You say you’re on 4.0.12, your email headers say you’re on 4.0.4. Was
this an upgrade, if so from what version. You can also look at the
Templates table for the LastUpdated and LastUpdatedBy fields to see if
there are hints (compare them to Created). If you upgraded from 3.8,
some of those columns won’t have useful values.
It’s a fresh 4.0.12 install with the old data imported rather than an upgrade,
I’m presuming that import mangled the global templates somehow! Well spotted.
I’ll c+p the proper global template in and see if that clears the issue up,
and look at updated to 4.0.13 in the mean time too! (Didn’t know it was out,
best sign up for rt-announce!)On Wednesday 03 Jul 2013 09:19:55 Kevin Falcone wrote:
On Wed, Jul 03, 2013 at 11:32:47AM +0100, Samuel Jones wrote:
The template is below, all our queues use this global template for ‘On
Comment Notify
AdminCcs as Comment’
A straight-up RT 4.0.13 install should yield this in the Subject: line
Subject: [Comment] {my $s=($Transaction->Subject||$Ticket->Subject||“”); $s
=~ s/[Comment]\s*//g; $s =~ s/^Re:\s*//i; $s;}
Notice all the backslashes that you’re missing?
In particular, [Comment] becoming [Comment] means the code will
remove any C, o, m, e, n or t from the Subject on Comments.
You say you’re on 4.0.12, your email headers say you’re on 4.0.4. Was
this an upgrade, if so from what version. You can also look at the
Templates table for the LastUpdated and LastUpdatedBy fields to see if
there are hints (compare them to Created). If you upgraded from 3.8,
some of those columns won’t have useful values.
-kevin
{RT->Config->Get(‘WebURL’)}Ticket/Display.html?id={$Ticket->id}
This is a comment. It is not sent to the Requestor(s):
{$Transaction->Content()}
On Tuesday 02 Jul 2013 16:22:29 Kevin Falcone wrote:
On Tue, Jul 02, 2013 at 05:37:44PM +0100, Samuel Jones wrote:
We’ve noticed a problem on our helpdesk recently, where e-mailed
notifications of new comments are loosing letters in their subject
lines!
As an Admin - go check your Admin Comment Template
Tools → Configuration → Global → Templates
Show us the contents.
You should also check for queue level templates. I expect a mis-edit
or a mis-upgrade of some kind.
-kevin
Some examples are:
[Comment] Missig Ev Rpr
should be: [Comment] Missing Event Report
[Comment] Vhicl Rd ha ar du PMI
should be: [Comment] Vehicles Rented that are due PMI
but, the outgoing e-mail event item from within the ticket shows
the
subject line as OK
Subject: [CVS Helpdesk #745] [Comment] Vehicles Rented that are due
PMI
It’s a fresh 4.0.12 install with the old data imported rather than an upgrade,
I’m presuming that import mangled the global templates somehow! Well spotted.
If your old data was from a non-4.0.12 install (and your email headers
imply that you were running 4.0.4) you really need to stop and do a
proper upgrade.
Would the regular upgrade path from 4.0.12 → 4.0.13 resolve the issues,
leave the data where it is and update RT around it?
4.0.12 was a fresh empty install and then the data imported as the documents
say to do. (just importing the mysql essentially, with some scripting to
adjust it from SQLite to MySQL)On Wednesday 03 Jul 2013 12:03:32 Kevin Falcone wrote:
On Wed, Jul 03, 2013 at 02:42:40PM +0100, Samuel Jones wrote:
It’s a fresh 4.0.12 install with the old data imported rather than an
upgrade, I’m presuming that import mangled the global templates somehow!
Well spotted.
If your old data was from a non-4.0.12 install (and your email headers
imply that you were running 4.0.4) you really need to stop and do a
proper upgrade.
I’ll c+p the proper global template in and see if that clears the issue
up,
and look at updated to 4.0.13 in the mean time too! (Didn’t know it was
out, best sign up for rt-announce!)
On Wednesday 03 Jul 2013 09:19:55 Kevin Falcone wrote:
On Wed, Jul 03, 2013 at 11:32:47AM +0100, Samuel Jones wrote:
The template is below, all our queues use this global template for ‘On
Comment Notify
AdminCcs as Comment’
A straight-up RT 4.0.13 install should yield this in the Subject: line
Subject: [Comment] {my $s=($Transaction->Subject||$Ticket->Subject||“”);
$s
=~ s/[Comment]\s*//g; $s =~ s/^Re:\s*//i; $s;}
Notice all the backslashes that you’re missing?
In particular, [Comment] becoming [Comment] means the code will
remove any C, o, m, e, n or t from the Subject on Comments.
You say you’re on 4.0.12, your email headers say you’re on 4.0.4. Was
this an upgrade, if so from what version. You can also look at the
Templates table for the LastUpdated and LastUpdatedBy fields to see if
there are hints (compare them to Created). If you upgraded from 3.8,
some of those columns won’t have useful values.
-kevin
{RT->Config->Get(‘WebURL’)}Ticket/Display.html?id={$Ticket->id}
This is a comment. It is not sent to the Requestor(s):
{$Transaction->Content()}
On Tuesday 02 Jul 2013 16:22:29 Kevin Falcone wrote:
On Tue, Jul 02, 2013 at 05:37:44PM +0100, Samuel Jones wrote:
We’ve noticed a problem on our helpdesk recently, where
e-mailed
notifications of new comments are loosing letters in their
subject
lines!
As an Admin - go check your Admin Comment Template
Tools → Configuration → Global → Templates
Show us the contents.
You should also check for queue level templates. I expect a
mis-edit
or a mis-upgrade of some kind.
-kevin
Some examples are:
[Comment] Missig Ev Rpr
should be: [Comment] Missing Event Report
[Comment] Vhicl Rd ha ar du PMI
should be: [Comment] Vehicles Rented that are due PMI
but, the outgoing e-mail event item from within the ticket
shows
the
subject line as OK
Subject: [CVS Helpdesk #745] [Comment] Vehicles Rented that are
due
PMI
Would the regular upgrade path from 4.0.12 → 4.0.13 resolve the issues,
leave the data where it is and update RT around it?
4.0.12 was a fresh empty install and then the data imported as the documents
say to do. (just importing the mysql essentially, with some scripting to
adjust it from SQLite to MySQL)
No, that won’t probably not work. If the imported data is from 4.0.3
then you’ll need to run ‘make upgrade-database’ and fill in the
requested pieces of information. In short, you’ll need the source
package and it will apply the updates that are in ./etc/upgrade/… from
the version you have to the version you specify or till the last that is
available, thats is if you have 4.0.13 source it will stop at 4.0.13
Without reading back I’m suspecting that you’re using a rt package
(debian?) and then I don’t know if you can run ‘make upgrade-database’.
Someone on the list will probably know what todo then (got some ideas
but they are rather hackish, I use RT from source, then no such problems)
The fresh installation of 4.0.12 was to move away from system packages to
source
I’m all ready to upgrade to 4.0.13, but on make upgrade-database, is it best
to run it as upgrade from 4.0.12 or from 4.0.4 which was the previous system
package?
I reckon from 4.0.4 but I don’t want to cause any other damage along the way.On Thursday 04 Jul 2013 21:35:43 Joop wrote:
Samuel Jones wrote:
Would the regular upgrade path from 4.0.12 → 4.0.13 resolve the issues,
leave the data where it is and update RT around it?
4.0.12 was a fresh empty install and then the data imported as the
documents say to do. (just importing the mysql essentially, with some
scripting to adjust it from SQLite to MySQL)
No, that won’t probably not work. If the imported data is from 4.0.3
then you’ll need to run ‘make upgrade-database’ and fill in the
requested pieces of information. In short, you’ll need the source
package and it will apply the updates that are in ./etc/upgrade/… from
the version you have to the version you specify or till the last that is
available, thats is if you have 4.0.13 source it will stop at 4.0.13
Without reading back I’m suspecting that you’re using a rt package
(debian?) and then I don’t know if you can run ‘make upgrade-database’.
Someone on the list will probably know what todo then (got some ideas
but they are rather hackish, I use RT from source, then no such problems)
The fresh installation of 4.0.12 was to move away from system packages to
source
I’m all ready to upgrade to 4.0.13, but on make upgrade-database, is it best
to run it as upgrade from 4.0.12 or from 4.0.4 which was the previous system
package?
I reckon from 4.0.4 but I don’t want to cause any other damage along the way.
From 4.0.4 to 4.0.13, backup and/or test instance is your friend
Did the upgrade, specified 4.0.4 as the start and 4.0.13 as the end, which went
great and its all working, it didn’t however replace the admin comment scrip,
so I think I’ll just need to go in and change that manually!On Friday 05 Jul 2013 16:05:56 Joop wrote:
Samuel Jones wrote:
The fresh installation of 4.0.12 was to move away from system packages to
source
I’m all ready to upgrade to 4.0.13, but on make upgrade-database, is it
best to run it as upgrade from 4.0.12 or from 4.0.4 which was the
previous system package?
I reckon from 4.0.4 but I don’t want to cause any other damage along the
way.
From 4.0.4 to 4.0.13, backup and/or test instance is your friend
The fresh installation of 4.0.12 was to move away from system packages to
source
I’m all ready to upgrade to 4.0.13, but on make upgrade-database, is it
best to run it as upgrade from 4.0.12 or from 4.0.4 which was the
previous system package?
I reckon from 4.0.4 but I don’t want to cause any other damage along the
way.
From 4.0.4 to 4.0.13, backup and/or test instance is your friend
Did the upgrade, specified 4.0.4 as the start and 4.0.13 as the end, which went
great and its all working, it didn’t however replace the admin comment scrip,
so I think I’ll just need to go in and change that manually!
I’m not sure anyone thought that Template was going to be fixed by an
upgrade. Now that we know you did an export from sqlite into another
database, I’d place any blame on that step.
If I were you, I’d be comparing all my Templates with the shipped
versions.
