Re: [rt-users] Upgrading to 3.8.0: schema.mysql, column_info selection problem
Your local version of DBD::mysql is out of date. The relevant notes from my
rt3.8 upgrade on Debian Etch are below. Hope that helps.
Kris Boutilier
Information Services Coordinator
Sunshine Coast Regional District
-
'column_info failed: column_info doesn't support column selection' means
DBD::mysql is probably out of date, so check installed version of DBD::mysql
# perl -MCPAN -e 'print CPAN::Shell->r '
Package namespace installedlatest in CPAN file
...
DBD::mysql 3.0008 4.007 CAPTTOFU/DBD-mysql-4.007.tar.gz
...
What does Debian provide as a package and are we up to date?
rt38:/# apt-cache search DBD::mysql
libdbd-mysql-perl - A Perl5 database interface to the MySQL database
rt38:/# apt-get install libdbd-mysql-perl
Reading package lists... Done
Building dependency tree... Done
libdbd-mysql-perl is already the newest version.
Hmmm http://packages.debian.org tells us that 4.007-1 is available in
Testing. Can we easily install the package from Testing on this Stable machine?
[don't bother trying this route, it fails miserably...] rt38:/usr/src# wget
http://http.us.debian.org/debian/pool/main/libd/libdbd-mysql-perl/libdbd-mysql-perl_4.007-1_amd64.deb
[clip]
... So, no. How about installing from sources, via CPAN?
rt38:/usr/src# wget
http://search.cpan.org/CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.007.tar.gz
{clip}
12:12:57 (444.49 KB/s) - `DBD-mysql-4.007.tar.gz' saved [123516/123516]
rt38:/usr/src# tar -xvzf DBD-mysql-4.007.tar.gz
rt38:/usr/src/DBD-mysql-4.007# perl Makefile.PL
H... it needs access to the mysql_client binary to build, so:
rt38:/# apt-get install libmysqlclient15-dev
rt38:/usr/src/DBD-mysql-4.007# perl Makefile.PL
rt38:/usr/src/DBD-mysql-4.007# make
rt38:/usr/src/DBD-mysql-4.007# make install
And, try again:
rt38:/usr/src/rt-3.8.0rc3# perl etc/upgrade/schema.mysql-4.0-4.1.pl rt3 root ''
> sql.queries
rt3.Groups.Instance has type VARCHAR however mapping is missing.
Odd message, but everything seems to work now.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of web master
Sent: Wednesday, July 16, 2008 3:00 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Upgrading to 3.8.0: schema.mysql, column_info selection
problem
Hi there
I am having schema.mysql-4.0-4.1.pl problems upgrading to version 3.8.0 from
3.6.6.
make upgrade worked well.
{clip}
[EMAIL PROTECTED] etc/upgrade/schema.mysql-4.0-4.1.pl DB USER PASS >
sql.queries
but
DBD::mysql::db column_info failed: column_info doesn't support column selection
at etc/upgrade/schema.mysql-4.0-4.1.pl line 227.
DBD::mysql::db column_info failed: column_info doesn't support column selection
at etc/upgrade/schema.mysql-4.0-4.1.pl line 227.
{clip}
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
RE: [rt-users] Problem accessing RT located behind an apache proxy
Most likely you'll need to use something like mod_proxy_html to manipulate occurances of the private address within the body of the http stream. You could confirm this by using Wireshark to look at the contents of the http replies on both sides of the Apache server and see exactly where the offending addresses are being embedded. mod_proxy_html is a perfect tool for doing in-line rewrites of javascript, css and other complexities generated by proxied web apps. See http://apache.webthing.com/mod_proxy_html/ Kris Boutilier Information Services Coordinator Sunshine Coast Regional District From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schincke, Keith D. (JSC-IT)[MEI] Sent: Sunday, October 28, 2007 8:33 AM To: rt-users@lists.bestpractical.com Subject: [rt-users] Problem accessing RT located behind an apache proxy Hey Guys, I am having issues accessing parts of my RT installation while it is located behind an apache proxy. My configuration is: RT is installed on a server on a private network. Apache is installed on a server on the public network that will proxy with mod_rewrite access to the RT server. This configuration works great for most parts of the RT system. Tickets can be looked at. Users can be added. The problem occurs when a ticket or user is updated. When a ticket is updated, Update.html is called, the ticket is update and the browser is redirected to Display.html. The redirect is what is causing my problems. The application is tries to send the browser to the private IP address to load Display.html. Here is my configuration: Front end apache server: Centos 4.5 httpd 2.0.52 Here are the rewrite rules: RewriteEngine on RewriteLog /var/log/httpd/rewrite.log RewriteLogLevel 2 RewriteRule ^/$ http://10.0.0.1/rt [P,L] RewriteRule ^/(.*)$ http://10.0.0.1/$1 [P,L] ProxyPass / http://rt.example.com/ ProxyPassReverse / http://rt.example.com/ Backend server: Debian etch Aapche 2 RT 3.6 My $WebBaseURL is http://rt.example.com Any suggestions on what may be causing the rewrite to not work correctly? Thanks for any help, Keith ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users SAVE THOUSANDS OF DOLLARS ON RT SUPPORT: If you sign up for a new RT support contract before December 31, we'll take up to 20 percent off the price. This sale won't last long, so get in touch today. Email us at [EMAIL PROTECTED] or call us at +1 617 812 0745. Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
RE: [rt-users] 3rd party reply on a ticket creates a new ticket
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Joe Casadonte
> Sent: Thursday, August 02, 2007 12:22 PM
> To: rt-users
> Subject: [rt-users] 3rd party reply on a ticket creates a new ticket
>
> Using RT 3.6.3
>
> I have the following situation:
>
> * user A creates a ticket copying list B
> * user C (a member of B) replies to the ticket with more information
> * a second ticket is created, even though user C's email was tagged
>correctly in the subject line
>
> If user C is directly CC'd (instead of through an email list,
> which RT obviously has no way of knowing about), then the
> reply goes into the original ticket as desired. Is there a
> way to prevent RT from creating a new ticket when anyone
> replies to a ticket?
>
{clip}
Are you certain that User C is replying to the email generated by RT and
not to the message that User A cc:ed to the list? We have experienced
the same behavior where User A sends a new request directly to RT and
CC's many additional users. One or more of those users enter into a
debate using 'Reply All' and each and every reply to that exchange of
emails lacks the RT subject line prefix and so spawns a raft of new
tickets. As a I understand it it's only the lack of a valid subject line
prefix that will cause RT to spawn a new ticket.
We're looking for a way to have RT just reject messages that it's cc:ed
into, period, to avoid this situation. I suspect that would have to
occur at the MTA level but I'm not certain how we'd do that as we're
using the Sendmail aliases table.
Kris Boutilier
Information Services Coordinator
Sunshine Coast Regional District
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
RE: [rt-users] Google Summer of Code
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Jesse Vincent
> Sent: Wednesday, February 28, 2007 11:30 AM
> To: rt-Users Users
> Subject: [rt-users] Google Summer of Code
>
{clip}
>
> What would you like to do/see done as part of a RT summer of
> code project?
>
SOAP/REST interfaces have already been mentioned. I'd really like to see
whatever comes out of that decision leveraged to build a decent, tightly
integrated framework for an IVR interface using Asterisk (a-la the now
obsolete http://www.voip-info.org/wiki/view/Asterisk+Request+Tracker).
Given the wide audience acceptance both the RT and Asterisk projects
have already developed in their particular fields it would seem to be
really good fusion - imagine unpacking an RT installation, unpacking an
Asterisk installation, stirring in some basic configuration and voila! a
telephony user interface to go along with the already great email and
web UIs - all without needing to add expensive, telephony-specific
hardware.
A dash of Sphinx (http://www.voip-info.org/wiki/view/Sphinx), a pinch of
Festival (http://www.voip-info.org/wiki/view/Festival) all rolled up in
a nice VoiceXML wrapper (http://www.voip-info.org/wiki/view/VoiceXML)
and it starts to sound like a pretty flexible toolset for doing large
scale customer relationship management projects outside of the IT
domain.
Hmmm, perhaps I'm dreaming... ;-)
Kris Boutilier
Information Services Coordinator
Sunshine Coast Regional District
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
RE: Using Asterisk voicemail to generate tkt (was Re: [rt-users] RT SOAPSERVER)
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Asif Iqbal > Sent: Monday, April 10, 2006 1:38 PM > To: rt-users@lists.bestpractical.com > Subject: Using Asterisk voicemail to generate tkt (was Re: > [rt-users] RT SOAPSERVER) > > On Mon, Apr 10, 2006 at 12:52:28PM, Mustafa Badawi wrote: > > Hello all > > > > I have used asterisk voice mail to create tickets in rt but > have not > > been > > Care to share on the steps to have voicemail/voice to create > a ticket? I am in the process of tetsing out asterisk so even > if it is just for asterisk I like to see how it is done. > Essentially, just set Asterisk to deliver the voicemail message as an attachment and then point it at the email submission address for RT. Ideally use a special submission address into RT and a separate queue that an operator reviews and transcribes the salient points of into the body of the ticket. There was glue in the past to use the SOAP interface, but that went away with the enhanced security architecture that came as part of RT3. Hopefully SOAP, or a suitable replacement, will come back soon. See http://www.voip-info.org/wiki/view/Asterisk+Request+Tracker The possibilities afforded by bolting a fully customizable IVR platform to RT would make it a _killer_ package. Consider that you don't even need physical lines to plumb Asterisk into the world - Vonage, SIP from an existing corporate PBX etc... roll in some Sphinx glue: http://www.voip-info.org/wiki/view/Sphinx... :-) Kris Boutilier Information Services Coordinator Sunshine Coast Regional District ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
