If you can upgrade to the latest version of CentOS 7, you'll get perl 5.16. Joseph D. Wagner On 2016-03-15 03:06, Boris Epstein wrote: > Hi Peter, > > Thanks, I saw that. > > I was wondering what the benefits and general experience was of those who > used later versions of Perl 5 or Perl 6 vs 5.10.1. Just trying to see if it > was a worthwhile exercize trying to upgrade - which on Centos did not seem to > be trivial. > > Cheers, > > Boris. > > On Tue, Mar 15, 2016 at 4:27 AM, Peter Viskup <skupko...@gmail.com> wrote: > >> Hello Boris, >> from readme  on github it is obvious the RT needs Perl as of >> version 5.10.1 and above. Readme file from 4.4 version has the same >> list of requirements. >> Some RT modules may have their own dependencies. You need to check them. >> >>  https://github.com/bestpractical/rt >> >> -- >> Peter Viskup >> >> On Mon, Mar 14, 2016 at 4:33 PM, Boris Epstein <borepst...@gmail.com> wrote: >>> Hello all, >>> >>> I am about to upgrade my RT 4.2 to v4.4 on a CentOS 6 machine. It appears >>> that Perl 5.1 is barely adequate. What is the recommended version of Perl >>> for this setup? >>> >>> Thanks. >>> >>> Cheers, >>> >>> Boris. >>> >> >>> - >>> RT 4.4 and RTIR Training Sessions https://bestpractical.com/training >>> * Washington DC - May 23 & 24, 2016 >>> > > - > RT 4.4 and RTIR Training Sessions https://bestpractical.com/training > * Washington DC - May 23 & 24, 2016 - RT 4.4 and RTIR Training Sessions https://bestpractical.com/training * Washington DC - May 23 & 24, 2016
Ok, I'm inching closer. I found out that it works if I run it from the command line, but not when sendmail fires it off. (This probably gave me the false sense that it worked by switching to HTTP.) I turned on debug level logging in RT. It logged a bunch of stuff when run from the command line, but it didn't log anything when sendmail did it. Joseph D. Wagner
Figured it out. I created a catch-all address in virtusertable. Unknown to me, virtusertable gets processed before aliases, so it was hitting the catch-all and never made it to aliases. Joseph D. Wagner On 09/06/2015 12:13 PM, Alex Vandiver wrote: On Sun, Sep 06, 2015 at 12:31:28AM -0700, Joseph D. Wagner wrote: Here it is. I left everything intact except the url. [snip] Those look fine. Double-check that you have not multiply-defined prc-staff elsewhere in aliases, and that you've run `newaliases`. Short of that, my only suggestion is to turn on bug logging in your MTA -- I can say with certainty that rt-mailgate doesn't deal differently with correspond vs comment and http/https connections. - Alex
Here it is. I left everything intact except the url. prc:"|/usr/bin/rt-mailgate --queue 'Performance Review' --action correspond --url https://./rt; prc-staff: "|/usr/bin/rt-mailgate --queue 'Performance Review' --action comment--url https://./rt; Joe On 09/05/2015 11:32 PM, Alex Vandiver wrote: On Sat, Sep 05, 2015 at 11:22:48PM -0700, Joseph D. Wagner wrote: I had apache set to allow rt over https only. Trying over http would fail. rt-mailgate was working perfectly fine over https when using "--action correspond". However, when using "--action comment", it fails saying it is unable to connect. When I changed my apache configuration to allow http on local connections, it started working. I suspect there is some code in the comment path of rt-mailgate that is forcing it over the http connection, rather than properly deriving the connection from the url parameter. Being new to rt, I am open to the possibility I misconfigured something. Is anyone else able to reproduce this? I strongly suspect misconfiguration in your /etc/aliases. The only difference between correspond and comment paths is the value of a query parameter that they POST: https://github.com/bestpractical/rt/blob/stable/bin/rt-mailgate.in#L168-L170 Check to make sure that you have https:// on all of your aliases, and that you've run newaliases (or equivalent) after updating them. - Alex
I got it working by doing a complete gut and replacement with the Perl packages from Fedora 21. From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Tom Misilo Sent: Wednesday, September 02, 2015 10:24 AM To: 'firstname.lastname@example.org' Subject: [rt-users] RT 4.2.12 and CentOS 7 Hi, I was wondering if anyone has successfully used "make fixdeps" with Request Tracker on CentOS 7? As it seems like cpan only installs to the local users home directory in a ~/perl5 folder and not systemwide. Which when using Request Tracker and mod_fcgid apache does not find any of the modules. Thank you, Tom
I think your solution is going to come from postgres, rather than RT. I believe Ticket ID's come from tickets_id_seq. You could set them to increment by 2, with one starting at an even number and another starting at an odd number. See: http://www.postgresql.org/docs/9.4/static/sql-createsequence.html However, I don't have enough experience with clustering to know if that's a good idea. Here's some info on postgres that could be useful to your situation: https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling Joseph Wagner On 08/28/2015 03:35 PM, Jeff Mundine wrote: I had an idea to cluster RT, using postgres to synchronize the different RT servers. The only issue I have, is if the DB's stop talking to eachother, then there would be a problem with the ticket sequencing. (you would get duplicate tickets for the same id). I've tried to look around for something like modifying the ticket id. I know it's numeric only, but haven't found much to do something like have one server do odd numbers, the other even or some such.. Any ideas of a way to do this, or is it simply not possible at this time. Also, any other reasons or possible problems anyone could see with this? My secondary step, is just to run 1 instance, but use the postgres replication and probably rsync for a hot standby.
What do you mean by without logins? The email address needs to correspond to a user that already exists on the system? Yes. Here's what happened. A privileged user entered an external email address into the CC field, which did not have an account. RT autocreated an account for that person, and it accepted that external email address on the CC field. I need to prevent that. How can I limit CC and AdminCC to email addresses that already have accounts? Either rejecting the ticket or silently failing to add the CC/AdminCC email address would be acceptable. Joseph D. Wagner
I need to limit what users can enter into CC and AdminCC. I cannot have them entering email addresses for those without logins. How can I limit or secure this? Joseph D. Wagner
I don't think the solution is to have Microsoft, Apple, IBM, Gmail, Yahoo, Hotmail, AOL, etc rewrite their MUA's. I think the solution is a new feature to RT. RT is already parsing and filtering quoted text on the website. It should be only a moderate amount of development effort to do the same thing before sending out emails. I would recommend contacting the developers about this as a new feature request. Joseph Wagner From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Guadagnino Cristiano Sent: Tuesday, August 11, 2015 3:28 AM To: email@example.com Subject: Re: [rt-users] Eliminating quoted text in email web replies Hi Josiah, we have the same problem. I don't think RT can do anything about this problem, as MUAs used several different ways to indicate quoted text. The worst of all is Outlook, and in fact RT very often cannot correctly identify quoted text when coming from it. So I have been thinking (since a long time) that there should be a way to tell MUAs not to quote. I don't know why nobody thought this before. I am thinking about a new mail header that tells the MUA not to quote text when replying to a message. This header could be used by all kinds of automated softwares that use email to communicate bi-directionally, like RT. MUAs could then decide what to do: blindly obey the header or ask the user or use some pre-configured parameter or... any of a number of possibilities. I was thinking about sending an RFC to request implementation of this new header, but finally I decided otherwise for a number of reasons. First, sending an RFC seems a complicated issue. Second, I have very little time to understand how this is done and then to do it. Third, it would be a very slow process before the RFC is approved (*if* it is approved) and implemented by a good number of MUAs. I am sharing these thought because maybe someone will find it a worthwhile idea and decide to go on and present an RFC to the IETF. Who knows? TIA Cris On 10/08/2015 22:55, Josiah Philipsen wrote: I have been trying to watch this ticket to see if someone has a solution, but there have not been any replies. Does anyone know how to remove the quoted text in an email sent to RT, so the tickets don't get as flooded. Thanks, Josiah On Mon, Jul 27, 2015 at 6:08 PM, Subjected subjec...@subjectedtochange.com wrote: Is there any way to remove or delete quoted text in email replies or replies from the self-service web interface? Whenever a user replies to a ticket notification, usually their email client quotes the original text. When the reply is received by RT and notifications sent to ticket owners, it includes the quoted text. This ends up making a real mess of replies and becomes difficult to see the new information. I can see in the web interface how RT tries to hide the quoted text. This helps with the web interface and self-service, but email updates are still are polluted with unnecessary quoted text from previous replies. We include this text in the top of our email templates: ## For best results, when replying to this email, first DELETE the quoted message body before entering your reply ## But most users ignore those instructions. Is there any way to force RT to delete any quoted text for an update from a prior RT email notification?
I would like for unprivileged users to be able to enter and view custom fields on the tickets they enter. I setup the custom field for Ticket and added it to a specific Queue. I figured out how unprivileged users can enter custom fields for tickets they file -- SeeCustomField and ModifyCustomField. However, after the ticket is entered, unprivileged users cannot see the custom field data they just entered on the SelfService/Display.html page. Only privileged users can see this. How can I set this up so unprivileged users can see the custom field data they just entered? Any help would be appreciated. Thanks. Joseph D. Wagner
I would like to pre-populate the description of a new ticket. For example, if I filed a bug on Red Hat's Bugzilla, a new bug description already contains the text: Component: Version: Problem: Expected Results: Actual Results: Additional Info: A feature like this would be very helpful to guiding users with what data they should enter. Can this be done in RT? If so, how? Thanks. Joseph D. Wagner