Re: [rt-users] rt-importer doesn't keep scrips-queues bindings

[Thibault Le Meur]

Le 31/05/2014 08:22, Thibault Le Meur a écrit :
  
On Friday, May 30, 2014 18:11 CEST, Kevin Falcone  wrote:
  

I believe you're running into this
http://issues.bestpractical.com/Ticket/Display.html?id=29949

Thanks for your answer.
This ticket is about objectscrips not serialized. However, in my case, scrips  
are correctly exported and imported into my new DB, only the bindings are 
missing.


My mistake, this ticket is exactly about my problem, but I'm not used to 
the mobile version of RT and didn't read the history, just the summary.


I'll try the proposed patch then.

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

Re: [rt-users] rt-importer doesn't keep scrips-queues bindings

[Thibault Le Meur]

 
On Friday, May 30, 2014 18:11 CEST, Kevin Falcone  
wrote: 
 
> I believe you're running into this
> http://issues.bestpractical.com/Ticket/Display.html?id=29949


Thanks for your answer.
This ticket is about objectscrips not serialized. However, in my case, scrips  
are correctly exported and imported into my new DB, only the bindings are 
missing.
Another difference is that I'm running only version 4.2.2 of rt-serializer and 
rt-importer, and the reported ticket seems to refer to version 4.2.3! Note 
however that I've seen no changelog entry related to serializer/importer in 
version 4.2.3 so this can be a mistake in the ticket.

Regards,
Thibault
 
 
 
 

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

Re: [rt-users] remote sql server w/ ssl RT make upgrade-database problem

[Kevin Falcone]

On Thu, May 29, 2014 at 03:29:23PM +, Pollard, James R wrote:
>Trying to upgrade from RT 4.2.1 to 4.2.4 with a remote SSL required Mysql 
> server.  I've had
>the current version working fine for months by modifying 
> /opt/rt/lib/RT/Handle.pm as such,
>where ++ denotes added lines.

This seems like the sort of thing that could be contributed to core,
assuming it worked on upgrades...

>I have already run make upgrade, copied my changes to Handle.pm and 
> verified that the
>connection works using the web interface.  Make upgrade-database fails 
> however saying "access
>denied for  (using password: YES)"

Unfortunately, you cut the important parts, seeing the connection
details printed by make upgrade-database and which step bailed out,
since there are schema changes *and* content changes.

>2.   Do a manual database upgrade using a manual connection via mysql 
> -D  Etc. etc.

Not possible, since there are changes that require RT to execute perl
code in those (and future) upgrade steps.

I assume you're tripping over RT trying to get a privileged handle for
schema changes and failing somewhere.

-kevin


pgp2v2ZxCG8G_.pgp
Description: PGP signature
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] RT could not load a valid user

[Kevin Falcone]

On Thu, May 29, 2014 at 02:37:47PM -0400, Techno Buddha wrote:
>/var/log/messages:

Instead of /var/log/messages which appears to be getting chopped up by
something, I suggest you
Set($LogToSTDERR, 'debug');
and read the debug logs in your apache logs.

You should also show the bounce email you get, since it implies mail
is looping.

>RT could not load a valid user, and RT's configuration does not allow
>for the creation of a new user for this email ([5]someem...@domain.com).
> 
>You might need to grant 'Everyone' the right 'CreateTicket' for the
>queue -SupportQ-.

While this generally means you need to change permissions, it can also
mean that you have a customization mucking about which might show up
in the debug logs.

>Set($AutoCreate, {UnPrivileged => 1});
>Set($AutoCreate, {Privileged => 0});

The first of these means nothing, and in either case, AutoCreate is no
longer correct under 4.2, and only works when logging in with the web
UI, not email:

http://bestpractical.com/docs/rt/latest/RT_Config.html#WebRemoteUserAutocreate

>Set($AutoCreateNonExternalUsers,1);
>Set($AutoCreateNonExternalUsers, 0);

This only applies if you have RT-Authen-ExternalAuth enabled.

># Enable 'code' tickets in approval processing
>Set($UseCodeTickets, 1);

This has not been a valid configuration option for almost a decade.

># Enable batch transaction scrips
>Set($UseTransactionBatch , 1);

This is the default since midway through 3.8

>@EmailInputEncodings = qw(utf-8 big5 us-ascii);

This doesn't do anything

>Set($CompanySpecific, '');

This implies you have customizations, what are they?

>Set($DatabaseUser , 'root');

Don't run RT as the root mysql user

>Set($DatabasePassword , '');

You just leaked your root database password to several mailing list
archives.

>Set($WebDomain, 'rt.switchworks.com');
>Set($WebBaseURL , "http://rt.switchworks.com";);
>Set($WebPath , "");
>Set($WebURL , "http://rt.switchworks.com"; . $WebPath . "/");
>Set($WebImagesURL , "http://rt.switchworks.com/"; . "NoAuth/images/");
>Set($LogoURL , "http://rt.switchworks.com/NoAuth/images/"; . "rt.jpg");

The last 2 of these may not do what you mean, and you generally only
want to set WebDomain, WebPath and WebPort and let us calculate.  Your
WebPath is the default and does not need to be specified.
http://bestpractical.com/docs/rt/latest/RT_Config.html#WebBaseURL-WebURL

># Enable HTML in tickets
>Set($PreferRichText, 1);
>Set($MessageBoxRichText, 1);
>Set($MessageBoxRichTextHeight, 200);

These are all the defaults

>Set($AutoCreateNonExternalUsers, 1);

Irrelevant unless you have RT-Authen-ExternalAuth installed

-kevin


pgpW_ggP7SukQ.pgp
Description: PGP signature
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Ticket replies not going to another queue

[Kevin Falcone]

On Fri, May 30, 2014 at 03:07:05PM +, Guadagnino Cristiano wrote:
> > While we understand this use case (and in fact have developed code for
> > users who needed to be able to email other RT queues from inside RT):

> Is this something you have developed under a paid contract or is it part 
> of the standard RT? If so, I may have missed something.

It is something we have delivered to customers and has not seen a
public release.  Before public release, it would require refactorings
to make supporting it in future releases easier and there has not been
sufficient clamor nor support for it.

-kevin


pgpZII5rvGKim.pgp
Description: PGP signature
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] In Line Images in Emails

[Emmanuel Lacour]

On Fri, May 30, 2014 at 11:57:22AM +0100, Kevin Curtis wrote:
> 
>We have found that whenever RT receives an email that contains an inline
>image (internally or externally), any emails that get sent out by RT (for
>example to the CC list or the requestor or the owner) the email that gets
>sent out has the text/html section stripped of any html formatting and the
>text is encased in a  ..  block.

html/body is stripped in RT::Transaction->Content, but not wrapped in
 ...

can you send more information (test case) for this problem?

> 
>There is not an image either.
> 

The problem appears when the image is referenced as src="cid:...". There is a
bug caused by the fact that RT changes multipart/related to
multipart/mixed that breaks displaying of inline images.


I worked a bit on this but did not found a beautiful fix (as a template
may makes reference to another Transaction content than the current one
...).

A quick fix is to hack RT::Transaction::Content so it looks for CIDs,
then try to find corresponding images attachments in
RT::Tickets->Attachments, then replaced the CID by
src="data:image...".


-- 
Easter-eggs  Spécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37-   Fax: +33 (0) 1 43 35 00 76
mailto:elac...@easter-eggs.com  -   http://www.easter-eggs.com
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Different template according to requestor email address

[Emmanuel Lacour]

On Fri, May 30, 2014 at 12:59:48AM -0700, andkulb wrote:
> 
> How can I separate these to get different messages according to their email
> address?
> 


scrips uses lib/RT/Action/SendEmail.pm which is designed to send one
template to all scrip recipients.

it's not unfaisible to send different templates to different recipients,
you have to hack this file (and maybe others) a lot ...

-- 
Easter-eggs  Spécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37-   Fax: +33 (0) 1 43 35 00 76
mailto:elac...@easter-eggs.com  -   http://www.easter-eggs.com
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Problems with ! in html format emails

[Kevin Curtis]

Hi,
I am sorry I just noticed that this question didn't have a proper Subject, 
which I have now added.


Regards

Kevin Curtis
FarSite Communications


From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Kevin Curtis
Sent: 29 May 2014 15:05
To: rt-users@lists.bestpractical.com
Subject: [rt-users] (no subject)

Hi,
I have searched hard for the answer to this one, but haven't seen it yet, 
maybe someone can point me in the right direction.

We have RT version 4.2.1 installed on Ubuntu 12.04.  The main mailbox is on a 
Windows Exchange server, and we use fetchmail to get the mail every minute or 
so.  Mail sent by RT goes through sendmail.

We use RT as a Ticket handling tool for customer problems.  Our inhouse support 
staff use Office Outlook version 12.  The email client composes html formatted 
email.

The problem that I have spent the last week trying to solve is that the emails 
sent out have an exclamation marks "!" inserted into them at various places.

Now I have tracked down that the sendmail tool is doing this because some of 
the lines are longer than the maximum line length supported by SMTP (990 
characters).

And I have also tracked down that the Office Outlook email client is creating 
the long lines when html is chosen as the message format.  (It doesn't appear 
to be a problem with rtf or plain text).

I know the problem isn't in RT itself, but our configuration must so typical of 
many RT installations that I can't believe that we are the first to see this 
problem, and that there isn't a solution already out there somewhere.  If 
someone knows what it is then I'd be pleased to hear it.

I am not an expert in any of the component parts (fetchmail, sendmail or RT), 
but it seemed to me the best place to try and solve the issue was in the 
fetchmail/mailgate interface.  So I have added a new method to EmailParser.pm.

I have used the RescueOutlook method as a template and I have tried to break 
lines (using the perl Text::Wrap) but this doesn't seem to be doing the job.  
It looks like what I really need to do is process just the text/html section of 
the email and be a bit more intelligent about where the line breaks are placed. 
 At the moment it's just if the line is greater than 132 characters.

It's been quite a steep learning curve this week!  And it looks like it will 
take me a long time to get this fixed using the method I have chosen.  I hope 
that there is already a fix.

Thanks in Advance

Kevin Curtis
Farsite Communications.

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

Re: [rt-users] rt-importer doesn't keep scrips-queues bindings

[Kevin Falcone]

On Fri, May 30, 2014 at 10:19:52AM +0200, Thibault Le Meur wrote:
> Almost everything is working but I'm facing a small issue: rt-importer 
> correctly imports queues, tickets, attachments, scrips, ... but doesn't 
> keep the binding between scrips and queues.
> 
> For instance no scrip is "applied" in the Global section, and no scrip 
> is "applied" on queues.

I believe you're running into this
http://issues.bestpractical.com/Ticket/Display.html?id=29949

-kevin


pgpUum_aD7Xzs.pgp
Description: PGP signature
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] RT 4.2.3 - Charting - Group By Ticket ID

[Kevin Falcone]

On Thu, May 29, 2014 at 04:22:39PM -0700, sinical wrote:
> Hi List (Sorry if this is a doubleup I cant seem to post even though I am
> subscribed),
> 
>   Trying to make a performance report where the x-axis value is the Ticket
> ID so we can see if a job was done on time (Due Date set via the SLA
> Extension)
> 
>   However I couldn't select this as an option in the group by field.
> 
> and am able to use id as an x-axis value and I can generate all the graphs
> we wanted. However is this the proper way to do this or is there a better
> way to get this functionality that will survive through upgrades?

To get something that will survive via upgrades, you want to use a
_Local.pm overlay.  However, if you think this is a genuinely useful
enhancement to the charting features of RT 4.2, send a patch,
preferably with some screenshots showing what you're doing with it.

-kevin


pgpXiDgHivksx.pgp
Description: PGP signature
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Ticket replies not going to another queue

[Guadagnino Cristiano]

Kevin Falcone ha scritto:
> On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote:
>> The problem arises when one requestor (requestors often are completely
>> unaware of the fact we are using RT internally) send a ticket to a
>> division, and that division replies that the request should be made to
>> another division. At this point, the requestor often takes the reply and
>> forwards it to the other division, leaving it intact.
>> Now, if the other division is using RT, the mail message from the
>> requestor is again turned into a ticket and - due to the fact that it
>> already contains a ticket number - it is appended to the old ticket
>> thread instead of creating a new ticket in the other division's queues.
>>
>> Is anybody having this issue? How did you solve it?
> While we understand this use case (and in fact have developed code for
> users who needed to be able to email other RT queues from inside RT):
Kevin, I am curious about this.
Is this something you have developed under a paid contract or is it part 
of the standard RT? If so, I may have missed something.

>> Ideally I think RT should append to the original ticket only if the
>> receiving address is the same as the original ticket. Or at least, this
>> is how it could work in our environment. Anybody foreseeing possible
>> problems with this approach?
> This workflow will never become the default RT workflow.  Too many
> people (including us) rely on email finding their way to an RT ticket
> regardless of whether they've moved to a separate escalation queue or
> just to the 'correct' queue.
>
> Also consider the many many people who have 5+ email addresses all
> feed into one queue.
>
> Assuming usage of a modern RT, the following extension forces creation
> of new tickets when a reply comes in to a resolved ticket.  You could
> either use it as is, or modify it to check To: (and Cc:) vs Queue's
> correspond address and then trigger the new ticket creation.
>
> https://metacpan.org/release/RT-Extension-RepliesToResolved
>
> -kevin
>
Thank you Kevin, I think I'll be perusing this extension.
BTW, we're using RT 4.2.3.

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

Re: [rt-users] Ticket replies not going to another queue

[Kevin Falcone]

On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote:
> The problem arises when one requestor (requestors often are completely 
> unaware of the fact we are using RT internally) send a ticket to a 
> division, and that division replies that the request should be made to 
> another division. At this point, the requestor often takes the reply and 
> forwards it to the other division, leaving it intact.
> Now, if the other division is using RT, the mail message from the 
> requestor is again turned into a ticket and - due to the fact that it 
> already contains a ticket number - it is appended to the old ticket 
> thread instead of creating a new ticket in the other division's queues.
> 
> Is anybody having this issue? How did you solve it?

While we understand this use case (and in fact have developed code for
users who needed to be able to email other RT queues from inside RT):

> Ideally I think RT should append to the original ticket only if the 
> receiving address is the same as the original ticket. Or at least, this 
> is how it could work in our environment. Anybody foreseeing possible 
> problems with this approach?

This workflow will never become the default RT workflow.  Too many
people (including us) rely on email finding their way to an RT ticket
regardless of whether they've moved to a separate escalation queue or
just to the 'correct' queue.

Also consider the many many people who have 5+ email addresses all
feed into one queue.

Assuming usage of a modern RT, the following extension forces creation
of new tickets when a reply comes in to a resolved ticket.  You could
either use it as is, or modify it to check To: (and Cc:) vs Queue's
correspond address and then trigger the new ticket creation.

https://metacpan.org/release/RT-Extension-RepliesToResolved

-kevin


pgpPy072m7JLo.pgp
Description: PGP signature
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Ticket replies not going to another queue

[Guadagnino Cristiano]

> On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote:
>> Hi all,
>> RT usage is taking off lately here: we started with one division using
>> it, and now there are four divisions using it and a fifth coming soon.
>>
>> We have been using just one RT instance, using groups and ACLs to
>> separate the queues of one division from the others.
>> Every division has its own email address that forwards to RT, and
>> everything has been working very well till now.
>>
>> However, we have had a little nuisance that is slowly becoming bigger
>> due to the increased number of users and requestors.
>>
>> The problem arises when one requestor (requestors often are completely
>> unaware of the fact we are using RT internally) send a ticket to a
>> division, and that division replies that the request should be made to
>> another division. At this point, the requestor often takes the reply and
>> forwards it to the other division, leaving it intact.
>> Now, if the other division is using RT, the mail message from the
>> requestor is again turned into a ticket and - due to the fact that it
>> already contains a ticket number - it is appended to the old ticket
>> thread instead of creating a new ticket in the other division's queues.
>>
>> Is anybody having this issue? How did you solve it?
>>
>> Ideally I think RT should append to the original ticket only if the
>> receiving address is the same as the original ticket. Or at least, this
>> is how it could work in our environment. Anybody foreseeing possible
>> problems with this approach?
>>
>> Thank you in advance.
>> Bye
>> Cris
>
> Hi Cris,
>
> We a more general Helpdesk as one of the areas using RT and they have
> the rights to put a ticket in any of the other areas' submission queues.
> Then if something is mis-routed, we just drop it in the Helpdesk submission
> queue for re-routing.
>
> Regards,
> Ken
>

Ken, thank you for your reply.
This is what we do if it is immediately apparent to us that the request 
should be routed to another division.

Probably my example was a bit too simplistic, however the fact is that 
sometimes the requestor feels the urge to reissue a rejected request to 
a different division.

In that case we're out of luck, as we see the ticket re-opening the old 
thread, instead of opening a new ticket in another queue.

Any other suggestions?

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

Re: [rt-users] Ticket replies not going to another queue

[k...@rice.edu]

On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote:
> Hi all,
> RT usage is taking off lately here: we started with one division using 
> it, and now there are four divisions using it and a fifth coming soon.
> 
> We have been using just one RT instance, using groups and ACLs to 
> separate the queues of one division from the others.
> Every division has its own email address that forwards to RT, and 
> everything has been working very well till now.
> 
> However, we have had a little nuisance that is slowly becoming bigger 
> due to the increased number of users and requestors.
> 
> The problem arises when one requestor (requestors often are completely 
> unaware of the fact we are using RT internally) send a ticket to a 
> division, and that division replies that the request should be made to 
> another division. At this point, the requestor often takes the reply and 
> forwards it to the other division, leaving it intact.
> Now, if the other division is using RT, the mail message from the 
> requestor is again turned into a ticket and - due to the fact that it 
> already contains a ticket number - it is appended to the old ticket 
> thread instead of creating a new ticket in the other division's queues.
> 
> Is anybody having this issue? How did you solve it?
> 
> Ideally I think RT should append to the original ticket only if the 
> receiving address is the same as the original ticket. Or at least, this 
> is how it could work in our environment. Anybody foreseeing possible 
> problems with this approach?
> 
> Thank you in advance.
> Bye
> Cris

Hi Cris,

We a more general Helpdesk as one of the areas using RT and they have
the rights to put a ticket in any of the other areas' submission queues.
Then if something is mis-routed, we just drop it in the Helpdesk submission
queue for re-routing.

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

[rt-users] Ticket replies not going to another queue

[Guadagnino Cristiano]

Hi all,
RT usage is taking off lately here: we started with one division using 
it, and now there are four divisions using it and a fifth coming soon.

We have been using just one RT instance, using groups and ACLs to 
separate the queues of one division from the others.
Every division has its own email address that forwards to RT, and 
everything has been working very well till now.

However, we have had a little nuisance that is slowly becoming bigger 
due to the increased number of users and requestors.

The problem arises when one requestor (requestors often are completely 
unaware of the fact we are using RT internally) send a ticket to a 
division, and that division replies that the request should be made to 
another division. At this point, the requestor often takes the reply and 
forwards it to the other division, leaving it intact.
Now, if the other division is using RT, the mail message from the 
requestor is again turned into a ticket and - due to the fact that it 
already contains a ticket number - it is appended to the old ticket 
thread instead of creating a new ticket in the other division's queues.

Is anybody having this issue? How did you solve it?

Ideally I think RT should append to the original ticket only if the 
receiving address is the same as the original ticket. Or at least, this 
is how it could work in our environment. Anybody foreseeing possible 
problems with this approach?

Thank you in advance.
Bye
Cris
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

[rt-users] unsubscribe

[Sears, Mark]

Thanks,
Mark Sears - CISSP-M.S. IA
Principal Information Security Analyst
 [cid:image001.png@01CE728F.61780B30]
12249 Science Drive Suite 160
Orlando, FL 32826
office: (407) 541-4062
fax: (407) 380-3823
mark.se...@gdit.com
www.gdit.com



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

[rt-users] (no subject)

[Sears, Mark]

unsubscribe

Thanks,
Mark Sears - CISSP-M.S. IA
Principal Information Security Analyst
 [cid:image001.png@01CE728F.61780B30]
12249 Science Drive Suite 160
Orlando, FL 32826
office: (407) 541-4062
fax: (407) 380-3823
mark.se...@gdit.com
www.gdit.com



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

Re: [rt-users] Creating ticket through REST API with AJAX

[Jim Brandt]

On 5/29/14 4:40 PM, Brian C. Duggan wrote:

On Thu, May 29, 2014 at 01:58:48PM -0400, Jim Brandt wrote:

  >  jQuery(document).ready( function() {

 var formData = new FormData();
 formData.append( 'content', fields );

 $.ajax({
type: 'POST',
url: 'https://rt.myrtsrv.com/REST/1.0/edit',


Maybe call new instead of edit?

https://rt.myrtsrv.com/REST/1.0/ticket/new



Thanks, Jim. I should have checked the wiki. Progress, but now the server 
replies

 RT/4.2.3 200 Ok

 # Could not create ticket.
 # Could not create ticket. Queue not set

The user has all 'Modify' rights on the queue directly, not through a group. I 
can tell that RT is consuming all the headers because RT logs the 'Starts' and 
'Due' fields.

Any suggestions appreciated.


Confirm the queue name in the call is exactly the same as the queue name 
in RT. Also try running it with SuperUser rights. If it works you know 
it's a rights issue and can focus there (confirm SeeQueue, CreateTicket, 
etc.).


--

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

[rt-users] In Line Images in Emails

[Kevin Curtis]

Hi,
I have searched hard for the answer to this one, but there seems to be some 
confusion.  I am hoping that someone can provide some definitive answers.

We have RT version 4.2.1 installed on Ubuntu 12.04.  The main mailbox is on a 
Windows Exchange server, and we use fetchmail to get the mail every minute or 
so.  Mail sent by RT goes through sendmail.

We use RT as a Ticket handling tool for customer problems.  Our inhouse support 
staff use Office Outlook version 12.  The email client composes html formatted 
email.

We have found that whenever RT receives an email that contains an inline image 
(internally or externally), any emails that get sent out by RT (for example to 
the CC list or the requestor or the owner) the email that gets sent out has the 
text/html section stripped of any html formatting and the text is encased in a 
 ..  block.
There is not an image either.

The email can be viewed in the Web GUI as it was sent by the originator.  The 
reformatting is performed by RT when generating the outgoing mail.

If the email had contained a url to an image instead of an embedded image, then 
all seems to work fine.  In this case the outgoing emails are not converted to 
plain text in a text/html wrapper.

So my questions are as follows:


1)  Is there any documentation anywhere about the limitations of using the 
email interface?

2)  Should the email with an embedded image in it have not had the html 
formatting stripped out?

3)  Have I misconfigured something?


The questions
Thanks in Advance

Kevin Curtis
Farsite Communications.


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

[rt-users] Different template according to requestor email address

[andkulb]

Hello, 

There are tickets coming from internal users (@interal.aa) and from external
users (@gmail.com, @yahoo.com, etc).
I want to send different king of template according to requestor address.

Subject: {$Ticket->Subject}
Content-Type: text/html
{
 if($Ticket->RequestorAddresses =~ /@internal.aa/) {
 "You are internal"
 } else {
"You are external"
 }
}

Everything works fine if there are only one requestor (a...@internal.aa or
a...@google.com), but if there are situation like this (a...@internal.aa,
a...@gmail.com) both, the gmail.com and internal.aa mails get message saying
"You are internal". 

How can I separate these to get different messages according to their email
address?




--
View this message in context: 
http://requesttracker.8502.n7.nabble.com/Different-template-according-to-requestor-email-address-tp57533.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

[rt-users] rt-importer doesn't keep scrips-queues bindings

[Thibault Le Meur]

Hello,

I'm in the process of migrating a mysql-based RT installation to 
postgresql (I'll post a quick howto if it is of interest to someone).


Almost everything is working but I'm facing a small issue: rt-importer 
correctly imports queues, tickets, attachments, scrips, ... but doesn't 
keep the binding between scrips and queues.


For instance no scrip is "applied" in the Global section, and no scrip 
is "applied" on queues.


I'm exporting from RT 4.2.2 and importing to the same version.
No error was reported during export with rt-serializer or import.

Is this normal ?

Thanks in advance for any tip,
Thibault
--
RT Training - Boston, September 9-10
http://bestpractical.com/training