[rt-users] Tickets created by email not picking up requestor after upgrade from 3.8.6 to 4.0.5
Hello all, I've run across an odd situation. Just upgraded our internal version of RT to 4.0.5 last night and now when tickets are created from the mail gateway, they don't get the requestor assigned. The ticket gets created just fine and I can see the from address in the ticket, but it never gets populated into the requestor field. Has anyone else experienced this? Dallas
Re: [rt-users] Tickets created by email not picking up requestor after upgrade from 3.8.6 to 4.0.5
On Thu, 22 Mar 2012, Kevin Falcone wrote: I've not encountered that behavior with rt-mailgate. We see it sometimes with misconfigured users and the SelfService interface. Can you show the history of a relevant ticket? You'll also want to review any custom Scrips or MailPlugins or other customizations. -kevin Thanks for the reply Kevin. This is getting interesting. I have tested with a few different queues and removed scrips and it looks like it may be associated with my user account. If I send email (via pine or even direct SMTP to port 25) it won't set me as the requestor. I have had a fellow user of same groups and permissions test and he gets set as the requestor when doing the same process. We are running a vanilla installation and have no additional plugins or customizations that would be getting in the way. Where should I be looking for oddities on my user account? Dallas
Re: [rt-users] Tickets created by email not picking up requestor after upgrade from 3.8.6 to 4.0.5
On Thu, 22 Mar 2012, Dallas Wisehaupt wrote: On Thu, 22 Mar 2012, Kevin Falcone wrote: I've not encountered that behavior with rt-mailgate. We see it sometimes with misconfigured users and the SelfService interface. Can you show the history of a relevant ticket? You'll also want to review any custom Scrips or MailPlugins or other customizations. -kevin [snip] Where should I be looking for oddities on my user account? Dallas Aha! I found it. I had a queue set up for testing that was disbled and it had my address in for the Reply Address. This caused an error that was reported on the web interface when I attempted to create a ticket through the web interface. Removing that address from the queue fixed it up. Dallas
Re: [rt-users] Communication between RT and other ticketing systems
The main way we have integrated RT with other ticket systems is using email between the systems. This can take some careful config of notifications, mainly to keep from creating loops that will keep spawning new tickets or reopening resolved ones. It has worked well with 3 different external vendors each running different systems. Dallas On Thu, 10 Mar 2011, bastien_ wrote: Hello, I'm interested in implementing RT and before starting I would like to know if someone would care to share some ideas or experiences in linking RT with some other ticketing systems. In this case I would need to be able to send some tickets from RT to a Mantis system. I was not able to find my answer online, any idea or link to documentation is welcome. Thanks -- View this message in context: http://old.nabble.com/Communication-between-RT-and-other-ticketing-systems-tp31113332p31113332.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Why I am recommending 3.6 over 3.8 to my boss
If you search for rt 3.8 spec file you will find some spec files that do work for fedora and other variants. It wasn't too difficult to take one of those and morph it for our custom use. Biggest issue I had was taking the time to package up perl dependencies as rpms to store in our repo long term. And after a few dot release upgrades the work has paid off. Dallas On Fri, 5 Nov 2010, Todd Chapman wrote: I bet Best Practical would produce RPMs for you if you paid them to. On Thu, Nov 4, 2010 at 5:01 PM, Wes Modes wmo...@ucsc.edu wrote: Dear Boss: I strongly recommend going with the 3.6 version of RT. The install takes a few minutes, and it otherwise meets all the requirements of our project. Migration of old queues is simple. There is cost savings in the near and long-term. There is no rpm of RT3.8 that works for RHEL (32 or 64 bit) and none seem to be forthcoming. Someday perhaps someone will put one together, but it doesn't look like anytime soon. I CAN do a manual install of RT3.8 using the Best Practical install scripts. It is not terribly hard. However, the long-term costs of this are large. The install scripts put all the binaries, configuration files, and libraries in the wrong places for RHEL/CentOS, and working outside the package manager means files could be clobbered at any time. On the other hand, the rpms for RT3.6 use the package manager and put all the config files in /etc, all the perl modules in the perl modules dir, and the various tools in /usr/bin and /usr/sbin. The non-standard install using the scripts creates recurring costs in the future as the system is significantly more difficult to update and harder to maintain, like by a factor of 50 (five minutes compared to 4 hours). Additionally, the cost of migration of old content from 3.6 to 3.8 is unknown. Again, I will install either RT3.6 or RT3.8 but I need you to understand and acknowledge the costs of the choice. Wes Thanks to Gary Greene for the info about his latest centos rpm build.
[rt-users] search and merged tickets
We have a set of tickets where data has been merged instead of replicated and duplicate tickets closed or deleted. Now I think we are running into an issue. When a ticket is merged, its subject and content lines are popped into the stream of the new ticket. However, it appears that they are no longer searchable. Whether attempting to search on subject or even content, I haven't been able to find a way to do this type of search successfully. Has anyone else seen this or have a workaround/fix? Dallas (running RT 3.8.6) Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RTFM and bulk update
On Wed, 23 Dec 2009, Kevin Falcone wrote: These missing messages are actually a bug whose fix was included in 3.8.7 Cool, we'll look at the update. This is most likely because you need to port the code from Update.html which stops ticket update on certain conditions (like adding attachments). RTFM even has a callback for stopping creation in Create.html Thanks for pointing this out. I needed to do two things: 1. Add a unique name='' element to the submit boxes in the BeforeMessageBox Element. 2. Add an or to the unless statement in Bulk.html (line 335) in my local version. Thanks for your help. Dallas ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] RTFM and bulk update
We are looking at trying to use RTFM to do bulk comments on a set of search results. I have been able to get the BeforeMessage Callback set and Bulk.html updated so that the article can be searched for and included on the bulk update page. The code is essentially ripped from share/html/Ticket/Update.html and inserted into a local version of Search/Bulk.html. However, I've run into a snag/oddity, if I choose an article to include and select the Go button, the ticket gets updated with the content of the article and returns to the bulk update screen. This has 2 main downsides, we get no Results div which shows that the Message was logged, and we get a comment/correspondence for each article that is included. If we try to add articles 1, 2, and 3 to a ticket we get the following logged in the ticket and sent out via scrips: comment: article 1 comment: article 2 article 1 comment: article 3 article 2 article 1 The behavior I would expect is that of Ticket/Update.html where multiple articles could be included and the ticket is only updated when the Update Ticket button is used. Has anyone successfully set up RTFM for use with the bulk update screens? Thanks. Dallas RT - 3.8.6 RTFM - 2.4.2 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
