[rt-users] RT Perl dependencies (CentOS 5)
Hey folks, First let me say RT is a good tool - thanks! I've been playing with 4.0 in my development environment and am preparing to push it out to production. I've a few issues I'm working through including: 1) CC requirement - it seems that RT 4's configure wants a C compiler but we do not keep compilers on our production server. My solution here is to build in a pristine environment (VM similar to production) and then tar up the package and plop it into production. 2) Perl dependencies. In my dev environment I used CPAN (via make fixdeps). In production we don't use CPAN. My approach to here is to generate a list of Perl module dependencies, starting with the direct dependencies out of the rt-4.0.0/configure script, and then finding RPMs from repos we allow for use in production to fill in the gaps. Where this isn't enough I have to either cpan2rpm them or otherwise get Dag to add the modules to his RPMForge area (according to him he is happy to add any CPAN modules that are requested - sweet aye!) If anyone is already working on this from some other angle or has suggestions I am eager for input. cheers, ram
[rt-users] Native FullText Search in mysql
Hey folks, Looks like MySQL has FTS built in : http://dev.mysql.com/doc/refman/5.5/en/fulltext-search.html Is this supported by RT 4.0x? Thanks! RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
Re: [rt-users] Native FullText Search in mysql
Never mind... looks likt it's MyISAM only :( On Wed, Nov 2, 2011 at 11:59 AM, Ram Moskovitz ram0...@gmail.com wrote: Hey folks, Looks like MySQL has FTS built in : http://dev.mysql.com/doc/refman/5.5/en/fulltext-search.html Is this supported by RT 4.0x? Thanks! RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
[rt-users] REST user
Hi all, I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? thanks ram RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
[rt-users] REST user
On Fri, Nov 04, 2011 at 05:37:25PM +, Ram Moskovitz wrote: I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? Not unless you can log in as the user via the REST interface. The Perl API allows you to load the ticket as a user and Correspond as them. I assume our SelfService interface wasn't sufficient for your needs? So far you've listed features it has, and it handles Correspondence correctly. -kevin I can have the web-app login as the user via the REST interface in theory. Currently the users are auto-created and unprivileged - does that have to change? As for using the native RT self-service web interface - I don't want to frame it with-in my app and I don't want to swizzle my app through RT. RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
[rt-users] REST
I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? Not unless you can log in as the user via the REST interface. The Perl API allows you to load the ticket as a user and Correspond as them. I assume our SelfService interface wasn't sufficient for your needs? So far you've listed features it has, and it handles Correspondence correctly. -kevin I can have the web-app login as the user via the REST interface in theory. Currently the users are auto-created and unprivileged - does that have to change? You just have to ensure that they have sufficient rights, probably by granting them to the Requestors role. Will they need to be privileged or have passwords to be usable via REST? RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
Re: [rt-users] rt-users Digest, Vol 92, Issue 15
On Mon, Nov 07, 2011 at 08:14:13PM +, Ram Moskovitz wrote: I can have the web-app login as the user via the REST interface in theory. Currently the users are auto-created and unprivileged - does that have to change? You just have to ensure that they have sufficient rights, probably by granting them to the Requestors role. Will they need to be privileged No, but you will need to tell RT that unprivileged users can reach the REST endpoint using the SelfServiceRegex config or have passwords to be usable via REST? Yes - otherwise how would you log in as them? Also, your mail client appeared to pick a new subject and break threading. -kevin Thanks! ram RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
Re: [rt-users] rt-users Digest, Vol 92, Issue 53
Date: Wed, 30 Nov 2011 12:44:23 +0100 From: Bart b...@pleh.info To: rt-users rt-users@lists.bestpractical.com Subject: Re: [rt-users] The RT Wiki - Restructure (start using categories?) Message-ID: cab2d3rakg39ni-3g3h-r0ewteltgsep+djaalk87mlhhwbp...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, Jay, thanks for your input. I do feel that approaching it with a blank sheet of paper will be the best approach. Though we'll have to use Wikia's abilities/structure, the below is aimed at just that with a slight eye on structuring from scratch. *--- A rough sketch of the idea ---* I like it at first glance. * * The idea I have relies allot on the categories within Wikia. A categorie page can contain content, thus e.g. the contributions page could instead be a categorie page with some specific information on what you can expect, maybe some extra links to other stuff, etc. But the difference would be that since it is now a categorie page, that all scripts/contributions that have the categorie set to contributions would be automatically listed on that one page. (alphabetized) With that in mind you can quite easily create general categorie pages for all major topics and have any page regarding that topic being linked to that categorie. The front page would then contain a hierarchical structure with links to all the sections (a.k.a. categorie pages). And obviously information on what RT is, latest news/updates/etc. Another thing which you can easily add to the front page is an RSS feed of the Bestpractical blog, and maybe add a feed of the RT wiki itself showing the latest updates newest pages. (should both be doable I think) Other things that might be nice to add are some Wikia features for the community to promote the usage of the RT wiki (achievements and other fun stuff). *--- The structure (concept) ---* Since the above shows what categories and categorie pages can do for you it's important to create a structure (at first on paper) which will make sure that all major topics regarding RT are covered so that any new article can add a categorie appropriate for that specific article. (I assume that the structure will eventually grow naturally) Since this is just a concept I've sort of just looked at the current wiki and tried to gather some basic topics, what I want to achieve with this concept is to get input from others so that we can improve it further: - RT Basics - User Manual - Custom Fields - Articles - REST - RT Tool - RT Cron Tool - RT Installation (rough categories so that people can link install guides to an OS categorie, no more/no less) - Linux - FreeBSD - Other - Manual - RT Config: (a categorie for each major release) - RT 4 - RT 3.8 - RT 3.6 - Plugins: - A categorie page for all plugins! This way you can link scrips/configs/other goodies for a plugin to that specific categorie page. - Scrips: - Basically a summary of all scrips available for RT. - Automation At this point I'm blank on ideas, I'll just leave it at this and see what responses there are. I'm pretty sure this list can be better/structured better, but you have to start somewhere ^_~ *--- Rough plan of action ---* This is a rather rough plan for setting up the structure: - Remove all current categories (double check that the categorie pages don't contain content of any kind). - Add every single page currently in the wiki to a new categorie called Archive. Might I suggest instead creating a page called restructure todo list and put a list of all the current pages on that page... that way the current structure and organization, to the extent it is useful or familiar, is maintained and yet we have a todo list to work off of? cheers, ram - This sounds ugly but it's an easy way of keeping track of all the wiki pages that still need better categorization. - Basically a todo list, anything still in there needs to be categorized. - The idea is to do a few articles each day and eventually everything will be nicely categorized. - Create all the categories which have been though of, make sure that theres's at least some basic information on the categorie page. - Modify the home page to, at first, also contain the new categorie structure (keep the old links for now). - Start categorizing anything that's still in under Archive. - And last but not least, at a certain point modify the front page to only contain the new categorie structure. So, those are some ideas. Time for everyone to shoot at them ^_~ -- Bart RT Training Sessions (http://bestpractical.com/services/training.html) * Boston TBA
[rt-users] Upgrade path from 4.0.2 - 4.0.4
Date: Wed, 14 Dec 2011 15:41:12 +0400 From: Ruslan Zakirov r...@bestpractical.com To: Ram Moskovitz ram0...@gmail.com Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Upgrade path from 4.0.2 - 4.0.4 Message-ID: CAMOxC8uZmQARQ_ApR3kYEXHq3F+ouyAkGLepqz=ssgs-wte...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Wed, Dec 14, 2011 at 02:50, Ram Moskovitz ram0...@gmail.com wrote: Looking for a 'yep'. Looks like the upgrade path is going to be pretty painless - nothing in docs/UPGRADE* applies so my steps are: backup rt installation untar to tmp ./configure ? #using the same options I used for my initial clean install of 4.0.2 make testdeps make fixdeps repeat make testdeps and make fixdeps until make testdeps is happy compare generated /tmp/rt-4.0.4/etc/RT_Config with my live one Stop web-server backup DB make upgrade make upgrade-database #won't do anything but I'll run it anyway rm -fr /opt/rt4/var/mason_data/obj ? #Clear mason cache compare etc/RT_SiteConfig with the one backed up at the start of this process Start web-server # Win! This largely what the README suggests. Does this sound right? Any gotchas I should look for? Steps I can skip? Everything is right. In stable series: * we don't bump required versions of dependencies unless there is a bug * we don't bring new dependencies * we try to avoid database schema changes There is always a place for an exception, so it's not recommended to skip steps. If it's a normal release then most steps would be very fast. Thanks! ram RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] Full Text Search on mysql 5.6.4 off the shelf
From the mysql 5.6.4 release notes: MySQL Server 5.6.4 (Milestone Release) is a new version of the world's most popular open source database. MySQL now supports FULLTEXT indexes for InnoDB tables. http://forums.mysql.com/read.php?3,506409,506409 I can't get this release onto a production box, though it's good to see it's come down the pike! RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] Automation
Our office RT4 installation is humming a long. Training is going reasonably well. Now for some automation... We have a few very common requests that come in - folks looking for a particular report. I'd like to add a link somewhere in RT (perhaps on the Basics page or a new page instead of Basics?) where I can wire in a scrip (or perl module of any flavor... we have good perl skills in house) that will: 1 Build a URL based on well defined fields in the request 2 Pull a file from the dynamic URL 3 Correspond to requestor: with canned text (substitutions from the original request), attaching the retrieved file, changing the status to resolved What's the right way to go about this? thanks ram RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] Filter by requestor email domain
Hey there, I'm looking to not auto-reply on create to inbound emails from a certain domain ( anyth...@example.com and even anyth...@sd.example.com). I suppose the right way to go about this is via user defined condition in the global scrip for autoreply on create. I have steps 1 and 3.. what's step 2? 1 return 0 unless $self-TransactionObj-Type eq Create; 2 return 0 if #self-TicketObj- 3 return 1 thanks ram RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
Re: [rt-users] Filter by requestor email domain
Thanks Bart,
That looks good. I'm having an issue with it though - I need to match
against a regexp for the exception list.. I added an entry like '*@
example.com' to @exceptionlist and rt is still sending out create
confirmations. What am I missing?
thanks!
On Mon, Jan 30, 2012 at 2:41 AM, Bart b...@pleh.info wrote:
Hi,
We had a similar requirement for a bunch of e-mail addresses.
This can be achieved by editing the autoreply scrip to look something like
this:
- Condition: User Defined
- Action: Auto Reply To Requestors
- Template: Your AutoReply template
- Stage: TransactionCreate
- Custom Condition:
my @exceptionList = ('na...@example.com',
'na...@example.com',
'na...@example.com');
my $transactionType = $self-TransactionObj-Type;
my $ticketRequestor = lc($self-TicketObj-RequestorAddresses);
my $trans = $self-TransactionObj;
if ($transactionType eq 'Create') {
return if grep { $ticketRequestor eq lc($_) } @exceptionList;
my $msgattr = $trans-Message-First;
return 0 unless $msgattr;
return 1 if $msgattr-GetHeader('Received');
}
return 0;
In addition the above only sends an autoreply when someone sends an
e-mail, in our case we don't like the autoreply mails when we manually
create a ticket (e.g. via quick create).
Hope this helps.
-- Bart
Op 25 januari 2012 21:02 schreef Ram Moskovitz ram0...@gmail.com het
volgende:
Hey there,
I'm looking to not auto-reply on create to inbound emails from a certain
domain ( anyth...@example.com and even anyth...@sd.example.com). I
suppose the right way to go about this is via user defined condition in the
global scrip for autoreply on create. I have steps 1 and 3.. what's step 2?
1 return 0 unless $self-TransactionObj-Type eq Create;
2 return 0 if #self-TicketObj-
3 return 1
thanks
ram
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston — March 5 6, 2012
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 6, 2012
Re: [rt-users] Filter by requestor email domain
Yep changed the comparison from equality (eq) to match reg-exp (=~) and
was a bit more careful with my expression...
'.*?\@example\.com',
The ? makes the * 'non-greedy' and the back-slashes make the dots literal.
thanks Bart,
ram
On Fri, Feb 3, 2012 at 1:45 AM, Bart b...@pleh.info wrote:
I think your exception list is ok, but this line basically tells the if
statement that the content needs to exactly match your list:
return if grep { $ticketRequestor eq lc($_) } @exceptionList;
Instead of eq you could try using =~ instead, below a little info:
http://www.troubleshooters.com/codecorn/littperl/perlreg.htm#SymbolExplanations
You might also need to edit the exception list with /@example.com/, or
something like that.
Maybe someone with a little more programming skills can reply on this ^_^
I'm not sure if the above would work.
-- Bart
Op 2 februari 2012 21:56 schreef Ram Moskovitz ram0...@gmail.com het
volgende:
Thanks Bart,
That looks good. I'm having an issue with it though - I need to match
against a regexp for the exception list.. I added an entry like '*@
example.com' to @exceptionlist and rt is still sending out create
confirmations. What am I missing?
thanks!
On Mon, Jan 30, 2012 at 2:41 AM, Bart b...@pleh.info wrote:
Hi,
We had a similar requirement for a bunch of e-mail addresses.
This can be achieved by editing the autoreply scrip to look something
like this:
- Condition: User Defined
- Action: Auto Reply To Requestors
- Template: Your AutoReply template
- Stage: TransactionCreate
- Custom Condition:
my @exceptionList = ('na...@example.com',
'na...@example.com',
'na...@example.com');
my $transactionType = $self-TransactionObj-Type;
my $ticketRequestor = lc($self-TicketObj-RequestorAddresses);
my $trans = $self-TransactionObj;
if ($transactionType eq 'Create') {
return if grep { $ticketRequestor eq lc($_) } @exceptionList;
my $msgattr = $trans-Message-First;
return 0 unless $msgattr;
return 1 if $msgattr-GetHeader('Received');
}
return 0;
In addition the above only sends an autoreply when someone sends an
e-mail, in our case we don't like the autoreply mails when we manually
create a ticket (e.g. via quick create).
Hope this helps.
-- Bart
Op 25 januari 2012 21:02 schreef Ram Moskovitz ram0...@gmail.com het
volgende:
Hey there,
I'm looking to not auto-reply on create to inbound emails from a
certain domain ( anyth...@example.com and even anyth...@sd.example.com).
I suppose the right way to go about this is via user defined condition in
the global scrip for autoreply on create. I have steps 1 and 3.. what's
step 2?
1 return 0 unless $self-TransactionObj-Type eq Create;
2 return 0 if #self-TicketObj-
3 return 1
thanks
ram
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston — March 5 6, 2012
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 6, 2012
