[rt-users] RT stops sending mails to ticket requestors
Hi, we have been running RT for several years now with great results (around 60K tickets so far). However, our RT installation recently started to display a weird behavior: If a new requestor (has never before opened a ticket with their mail address, thus unknown to RT) starts a new ticket, they get the usual auto-reply and the ticket is forwarded to the watchers. If one of them answers via e-mail, the reply is sent to the other watchers and shows in the web-based ticket view, but it is not sent to the requestor. If one of the watchers answers via the web-based ticket view, the answer is forwarded to the other watchers AND the requestor. For each additional ticket that the (then no longer unknown) requestor opens with our RT, they do not even receive the auto-reply that is supposed to be sent. They also don't receive any replies sent via e-mail. I looked into the mail server logs and it can't be a transport problem since the mails aren't even queued - RT just doesn't send them. There are no recent changes on either RT, the local Perl version or OS that coincide with this odd behavior. Any pointers? Regards, --ck -- http://www.de-punkt.de [ [EMAIL PROTECTED] ]http://www.stormix.de PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe, CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich PHP-Sicherheit direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/ ___ 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
[rt-users] RT stops sending mails to ticket requestors
Hi, we have been running RT for several years now with great results (around 60K tickets so far). However, our RT installation recently started to display a weird behavior: If a new requestor (has never before opened a ticket with their mail address, thus unknown to RT) starts a new ticket, they get the usual auto-reply and the ticket is forwarded to the watchers. If one of them answers via e-mail, the reply is sent to the other watchers and shows in the web-based ticket view, but it is not sent to the requestor. If one of the watchers answers via the web-based ticket view, the answer is forwarded to the other watchers AND the requestor. For each additional ticket that the (then no longer unknown) requestor opens with our RT, they do not even receive the auto-reply that is supposed to be sent. They also don't receive any replies sent via e-mail. I looked into the mail server logs and it can't be a transport problem since the mails aren't even queued - RT just doesn't send them. There are no recent changes on either RT, the local Perl version or OS that coincide with this odd behavior. Any pointers? Regards, --ck -- http://www.de-punkt.de [ [EMAIL PROTECTED] ]http://www.stormix.de PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe, CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich PHP-Sicherheit direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/ ___ 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] RT stops sending mails to ticket requestors
Hi, System groups: Everyone: CreateTicket Unprivileged: CreateTicket, ReplyToTicket, ShowOutgoingEmail, Watch Requestor: CreateTicket, ModifyTicket, ReplyToTicket, ShowOutgoingEmail, Watch No user-defined groups with special privileges exist. For the problematic queue: Everyone: CommentOnTicket, CreateTicket, ReplyToTicket I really can't see any more privileges that might collide with the reply to the ticket requestor, however the fact that only new requestors receive a reply points into that direction I think... Any idea on how to debug that? The debug log just says no recipient found, not sending on one of the problematic cases, but it doesn't say why... Regards, --ck PS: And sorry for the resend. -- http://www.de-punkt.de [ [EMAIL PROTECTED] ]http://www.stormix.de PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe, CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich PHP-Sicherheit direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/ ___ 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] RT stops sending mails to ticket requestors
Kenneth Crocker schrieb: Christopher, Did you happen to modify the scrip to do a notify instead of an autoreply? A notify will not send an E_mail to the requestor if the requestor is the creator of the ticket, an autoreply will. No - the following scrips are active for that queue: Scrips which apply to all queues * Open Blank On Correspond Open Tickets with template Blank * OwnerChangeNotify On Owner Change Notify Owner with template Transaction * CreateNotifyAdminCC On Create Notify AdminCcs with template Transaction * CorrespondNotifyAdminCC On Correspond Notify AdminCcs with template Admin Correspondence * CorrespondNotifyReq On Correspond Notify Requestors and Ccs with template Correspondence * CorrespondNotify On Correspond Notify Other Recipients with template Correspondence * CommentNotifyAdminCC On Comment Notify AdminCcs as Comment with template Admin Comment * CommentNotify On Comment Notify Other Recipients as Comment with template Correspondence Current Scrips Autoreply On Create Autoreply To Requestors with template Autoreply de-punkt AFAICT, they are all untouched. I'm really at a loss as to where the problem might be... Regards, --ck -- http://www.de-punkt.de [ [EMAIL PROTECTED] ]http://www.stormix.de PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe, CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich PHP-Sicherheit direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/ ___ 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] RT stops sending mails to ticket requestors
Peer Michael schrieb: It's seems, that your Autoreply script isn't a global script, but a script, that runs only in a specific queue. So? Of course it's a local scrip, I need a different autoreply template for each of my queues. Regards, --ck -- http://www.de-punkt.de [ [EMAIL PROTECTED] ]http://www.stormix.de PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe, CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich PHP-Sicherheit direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/ ___ 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] RT stops sending mails to ticket requestors
Hi, I really need a solution to this problem ASAP, our complete ticketing has ground to a halt. How can it happen that only a completely new requestor (not known to RT before) receives the initial autoreply and all correspondence via e-mail, but all known requestors don't receive anything *at all*? Without RT sending responses to requestors, it has no use for our organization at all, I really need this fixed... Thanks, --ck -- http://www.de-punkt.de [ [EMAIL PROTECTED] ]http://www.stormix.de PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe, CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich PHP-Sicherheit direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/ ___ 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] RT stops sending mails to ticket requestors
Hi, the rt debug log looks like this during one of the broken transactions: [Fri Aug 31 14:26:21 2007] [debug]: About to commit scrips for transaction #324709 (/usr/local/rt/lib/RT/Transaction_Overlay.pm:173) [Fri Aug 31 14:26:21 2007] [info]: [EMAIL PROTECTED] #59902/324709 - Scrip 7 CorrespondNotify (/usr/local/rt/lib/RT/Action/SendEmail.pm:237) [Fri Aug 31 14:26:21 2007] [info]: [EMAIL PROTECTED] No recipients found. Not sending. (/usr/local/rt/lib/RT/Action/SendEmail.pm:249) [Fri Aug 31 14:26:21 2007] [info]: [EMAIL PROTECTED] #59902/324709 - Scrip 5 CorrespondNotifyAdminCC (/usr/local/rt/lib/RT/Action/SendEmail.pm:237) [Fri Aug 31 14:26:21 2007] [debug]: Converting 'ISO-8859-1' to 'utf-8' for text/plain - Re: AW: AW: [Filoo GmbH #59902] testmail (/usr/local/rt/lib/RT/I18N.pm:226) [Fri Aug 31 14:26:21 2007] [debug]: About to think about scrips for transaction #324710 (/usr/local/rt/lib/RT/Transaction_Overlay.pm:160) [Fri Aug 31 14:26:21 2007] [info]: [EMAIL PROTECTED] sent To: AdminCc of Filoo GmbH Ticket #59902:; Bcc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (/usr/local/rt/lib/RT/Action/SendEmail.pm:312) [Fri Aug 31 14:26:21 2007] [info]: [EMAIL PROTECTED] #59902/324709 - Scrip 6 CorrespondNotifyReq (/usr/local/rt/lib/RT/Action/SendEmail.pm:237) [Fri Aug 31 14:26:21 2007] [info]: [EMAIL PROTECTED] No recipients found. Not sending. (/usr/local/rt/lib/RT/Action/SendEmail.pm:249) [Fri Aug 31 14:26:21 2007] [warning]: Use of uninitialized value in concatenation (.) or string at /usr/local/rt/share/html/REST/1.0/NoAuth/mail-gateway line 66. (/usr/local/rt/share/html/REST/1.0/NoAuth/mail-gateway:66) The scrip is actually executed, but no recipient is found... how could that happen? --ck ___ 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
[rt-users] Autoreply to requestor not working
Hi, Our RT 3.8.8 installation does not send autoreplies to requestors if the ticket is opened via E-Mail. If it is opened via the web interface, the autoreply is sent. The debug log shows the following behavior: (Only the autoreply part contained) [Mon Aug 23 15:05:21 2010] [debug]: Converting 'ISO-8859-15' to 'utf-8' for text/plain - hfg (/usr/local/rt/bin/../lib/RT/I18N.pm:249) [Mon Aug 23 15:05:21 2010] [debug]: Mail from user #347309 (k...@requestor-domain.com) (/usr/local/rt/bin/../lib/RT/Interface/Email/Auth/MailFrom.pm:75) [Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for transaction #714762 (/usr/local/rt/bin/../lib/RT/Transaction_Overlay.pm:163) [Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for transaction #714763 (/usr/local/rt/bin/../lib/RT/Transaction_Overlay.pm:163) [Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for transaction #714764 (/usr/local/rt/bin/../lib/RT/Transaction_Overlay.pm:163) [Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for transaction #714765 (/usr/local/rt/bin/../lib/RT/Transaction_Overlay.pm:163) [Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for transaction #714766 (/usr/local/rt/bin/../lib/RT/Transaction_Overlay.pm:163) [Mon Aug 23 15:05:22 2010] [debug]: About to prepare scrips for transaction #714766 (/usr/local/rt/bin/../lib/RT/Transaction_Overlay.pm:167) [Mon Aug 23 15:05:22 2010] [debug]: Found 3 scrips for TransactionCreate stage with applicable type(s) Create (/usr/local/rt/bin/../lib/RT/Scrips_Overlay.pm:370) [Mon Aug 23 15:05:24 2010] [debug]: About to commit scrips for transaction #714766 (/usr/local/rt/bin/../lib/RT/Transaction_Overlay.pm:187) [Mon Aug 23 15:05:24 2010] [debug]: Committing scrip #68 on txn #714766 of ticket #99050 (/usr/local/rt/bin/../lib/RT/Scrips_Overlay.pm:190) [Mon Aug 23 15:05:24 2010] [debug]: Calling SetRecipientDigests for transaction RT::Transaction=HASH(0x911cc68), id 714766 (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:635) [Mon Aug 23 15:05:24 2010] [debug]: Working on mailfield To; recipients are (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:651) [Mon Aug 23 15:05:24 2010] [debug]: Subject: [Filoo GmbH #99050] Ihre Anfrage hfg From: Christopher Kunz via RT i...@our-2nd-domain.com Reply-To: i...@our-2nd-domain.com In-Reply-To: 4c728e2c.2080...@requestor-domain.com References: rt-ticket-99...@our-domain.com 4c728e2c.2080...@requestor-domain.com Message-ID: rt-3.8.8-2326-1282575923-597.99050-6...@our-domain.com Precedence: bulk X-RT-Loop-Prevention: Filoo GmbH RT-Ticket: Filoo GmbH #99050 Managed-by: RT 3.8.8 (http://www.bestpractical.com/rt/) RT-Originator: k...@requestor-domain.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-RT-Original-Encoding: utf-8 (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:658) [Mon Aug 23 15:05:24 2010] [debug]: Removing deferred recipients from To: line (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:681) [Mon Aug 23 15:05:24 2010] [debug]: Setting deferred recipients for attribute creation (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:690) [Mon Aug 23 15:05:24 2010] [debug]: Working on mailfield Cc; recipients are (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:651) [Mon Aug 23 15:05:24 2010] [debug]: Subject: [Filoo GmbH #99050] Ihre Anfrage hfg From: Christopher Kunz via RT i...@our-2nd-domain.com Reply-To: i...@our-2nd-domain.com In-Reply-To: 4c728e2c.2080...@requestor-domain.com References: rt-ticket-99...@our-domain.com 4c728e2c.2080...@requestor-domain.com Message-ID: rt-3.8.8-2326-1282575923-597.99050-6...@our-domain.com Precedence: bulk X-RT-Loop-Prevention: Filoo GmbH RT-Ticket: Filoo GmbH #99050 Managed-by: RT 3.8.8 (http://www.bestpractical.com/rt/) RT-Originator: k...@requestor-domain.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-RT-Original-Encoding: utf-8 (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:658) [Mon Aug 23 15:05:24 2010] [debug]: Removing deferred recipients from Cc: line (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:681) [Mon Aug 23 15:05:24 2010] [debug]: Setting deferred recipients for attribute creation (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:690) [Mon Aug 23 15:05:24 2010] [debug]: Working on mailfield Bcc; recipients are (/usr/local/rt/bin/../lib/RT/Action/SendEmail.pm:651) [Mon Aug 23 15:05:24 2010] [debug]: Subject: [Filoo GmbH #99050] Ihre Anfrage hfg From: Christopher Kunz via RT i...@our-2nd-domain.com Reply-To: i...@our-2nd-domain.com In-Reply-To: 4c728e2c.2080...@requestor-domain.com References: rt-ticket-99...@our-domain.com 4c728e2c.2080...@requestor-domain.com Message-ID: rt-3.8.8-2326-1282575923-597.99050-6...@our-domain.com Precedence: bulk X-RT-Loop-Prevention: Filoo GmbH RT-Ticket: Filoo GmbH #99050 Managed-by: RT 3.8.8 (http://www.bestpractical.com/rt/) RT-Originator: k...@requestor-domain.com MIME-Version: 1.0 Content-Transfer-Encoding
Re: [rt-users] Autoreply to requestor not working
On 23.08.2010 21:43, Kevin Falcone wrote: This implies that RT isn't seeing Requestors for that ticket. You may want to show a sample of the email being injected into RT and look at the user record for the user assigned as a Requestor for the ticket. You're also using a custom Autoreply template, and we don't know what you've changed there. I solved the problem by taking up your idea of dumping the raw mails and by remembering I had this problem before. The mail is delivered using a forwarding (i...@mydomain goes to infomydom...@rt-host.mydomain and from there is piped into the mailgate). It seems that when sending the ticket directly to infomydom...@rt-host.mydomain, the autoreply is triggered. When sending it to i...@mydomain, it's not. So i checked the mail contents. There is a valid From: header pointing to the requestor. The To: header points to the ticket system address. So it looks good to me, seeing that the From: header is (as far as rt--mailgate doc is concerned) is relevant for user authentication. The only difference between the working and the not working mail is that there is an empty Return-Path header in the broken one. And now it dawned to me. In lib/RT/Interface/Email.pm, RT checks for Return-Path =~ // to determine a bounce. I had patched this to make our old installation work (return(0)), but naturally forgot about the patch. Now, basically everything works again, but I have 2 questions: 1. does effectively disabling the routine CheckForBounce actually break something? In over 98000 tickets, I have not experienced a problem with double bounces or the likes. 2. Why does qmail forward a mail with an empty Return-path? But that's probably a whole other cup of tea. Regards, --ck RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] Autoreply to requestor not working
Am 24.08.2010 15:37, schrieb Kevin Falcone: My approach would be fixing qmail, rather than removing RT's bounce handling. True - I analyzed the underlying problem and it turned out that our mail server cluster was using 2 different versions of maildrop: - 1.5.2 did not modify the Return-Path in any way - 2.0.4 changed the Return-Path of filtered mails to / Envelope-From to MAILER-DAEMON A weird behavior indeed. I'll have to investigate this further. Regards, --ck RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
[rt-users] Highest known ticket count?
Hi, I was wondering what the highest known ticket count for any single (as in: one server, no balancing/federation) RT installation is so far... Is there any official info on this? Regards, --ck RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
[rt-users] GnuPG key management issues
Hello all, we are using the RT::Crypt::GnuPG module and have run into an issue that I'm afraid we cannot solve. Recently, some german mail providers, most notably GMX (one of the biggest free webmail providers in Europe) have enabled end-to-end encryption for their users. This is implemented using OpenPGP keys and a browser plug-in (modified version of Mailvelope). However, GMX does not publish the generated keys to a keyserver. Instead, users can send a so-called "invitation to encrypted communication" which is essentially an auto-generated mail that has the public key attached in an .asc attachment. [I am told by some customers that this is the way some commercial mail servers/appliances seem to handle key management, too.] This is where the problems start. With our current setup (and a local keyring on the RT server), RT will try handling the .asc attachment as encrypted data (which it isn't), fail and not handle the rest of the ticket. The requestor will receive a mail saying RT found invalid PGP data in their request. To remedy this (and add the key to RT's keyring), we currently have to manually extract the pubkey, scp it to the RT, add the key to the keyring and then re-set permissions (since gpg seems to modify ownership to the user who last modified a keyring file) to the web server. This is clumsy, error-prone and a security issue (since ssh access to our RT box is restricted with good reason). Also, it's unfortunately not possible to make GMX or our other customers with similar behavior change their mail format - this is clearly out of scope. We are using RT 4.0.8. Is there any configuration setting that I might have missed, or any other possibility to get RT to automatically import keys that come into the system as a .asc attachment? I am aware of the security implications of this (and, in fact, have set the trust settings to "always", as authentication of user requests is always performed separately). Best regards, --ck
Re: [rt-users] GnuPG key management issues
> We are using RT 4.0.8. Is there any configuration setting that I might I'm sorry, it's actually RT 4.2.8. Regards, --ck
Re: [rt-users] GnuPG key management issues
Hi, > I believe the 4.2/skip-asc-keys branch[1] addresses this particular > issue, of interpreting .asc as encrypted data. I'm sure that BPS > would appreciate the feedback if it resolves the issue for you. Thanks for the pointer! I think it does solve the painful part of the issue, indeed. I manually patched our 4.2.8 installation and now the .asc attachments still cause a warning in the log, but no other undesired effects. > The security implications of such a flag almost certainly preclude its > inclusion in core RT -- though you understand the security > implications, many sites might not, and might enable it regardless of > any warnings placed on it. Operating in such configurations is far > worse than operating without GPG at all. I agree. I'd like to point out, though, that a veiled hint at the "always trust" option is already in the doc for RT::Crypt::GnuPG. Quote: "Encrypting to untrusted keys Due to limitations of GnuPG, it's impossible to encrypt to an untrusted key, unless 'always trust' mode is enabled." Maybe there should be a notice after that sentence to the effect of "this is in most cases a very bad idea". > If you wish to implement this yourself, there are a couple options for > where to implement the behavior. The first two of them will require > that the web user have write access to the keyring. > I'm not a Perl guy, so developing our own solution is not in scope at the moment. In addition, I really don't think it does solve the actual issue, which is that GMX is spewing out potentially hundreds of thousands of unverifiable OpenPGP keys. It would be FAR better if they (semi-automatically) uploaded them to a keyserver and maybe added some trust level via their own management keys. After all, the owners of gmx.net can certify that a key belongs to randommem...@gmx.net and therefore authenticate that relation. Anyway, I'm sure since there actually are a lot of very smart people working there, they will roll out some of that eventually. > If this is central to your workflow, you may wish to consider > contacting sa...@bestpractical.com to see if they can help you > implement one of the above solutions. I might just do that, after asking my customer if he'll pay for it. First, however, I will try to educate them on the advantages of using keyservers. Thanks for your help, my biggest pain is solved! :) Best regards, --ck
Re: [rt-users] Upgrade-database from 4.0.8 to 4.4.0rc2 fails
Hi again, > Now populating database schema. > [11815] [Wed Nov 25 10:44:40 2015] [critical]: DBD::mysql::st execute > failed: Duplicate column name 'Disabled' at > /usr/local/src/rt-4.4/sbin/../lib/RT/Handle.pm line 552. > (/usr/local/src/rt-4.4/sbin/../lib/RT.pm:390) > DBD::mysql::st execute failed: Duplicate column name 'Disabled' at > /usr/local/src/rt-4.4/sbin/../lib/RT/Handle.pm line 552. > Makefile:391: recipe for target 'upgrade-database' failed > make: *** [upgrade-database] Error 255 > FWIW, I manually fixed about a dozen errors (non-existant columns, double columns and the likes) in the various database schemas and ran make upgrade-database multiple times until it finally completed successfully. Took me about an hour (and I'm not sure what caused it, since my 4.0.8 installation is vanilla, database-wise). --ck
[rt-users] Upgrade-database from 4.0.8 to 4.4.0rc2 fails
Hi,
I'm trying to upgrade an RT 4.0.8 instance (only lightly modified in
RT_SiteConfig.pm, no fancy stuff) to 4.4.0RC2. The 'make
upgrade-database' target fails at the following points:
== 4.0.8 => 4.0.9 ==
Processing 4.0.9
Now inserting data.
[11815] [Wed Nov 25 10:44:34 2015] [warning]: DBD::mysql::st execute
failed: Unknown column 'main.SortOrder' in 'order clause' at
/usr/local/share/perl/5.20.2/DBIx/SearchBuilder/Handle.pm line 586, <>
line 1. (/usr/local/share/perl/5.20.2/DBIx/SearchBuilder/Handle.pm:586)
[11815] [Wed Nov 25 10:44:34 2015] [warning]: RT::Handle=HASH(0x4878b28)
couldn't execute the query 'SELECT main.* FROM Queues main WHERE
(main.Lifecycle IS NULL OR main.Lifecycle = '' OR main.Lifecycle = '0')
ORDER BY main.SortOrder ASC, main.Name ASC ' at
/usr/local/share/perl/5.20.2/DBIx/SearchBuilder/Handle.pm line 599, <>
line 1.
DBIx::SearchBuilder::Handle::SimpleQuery(RT::Handle=HASH(0x4878b28),
"SELECT main.* FROM Queues main WHERE (main.Lifecycle IS NULL"...)
called at /usr/local/share/perl/5.20.2/DBIx/SearchBuilder.pm line 239
DBIx::SearchBuilder::_DoSearch(RT::Queues=HASH(0x996a060)) called at
/usr/local/src/rt-4.4/sbin/../lib/RT/SearchBuilder.pm line 982
RT::SearchBuilder::_DoSearch(RT::Queues=HASH(0x996a060)) called at
/usr/local/share/perl/5.20.2/DBIx/SearchBuilder.pm line 507
DBIx::SearchBuilder::Next(RT::Queues=HASH(0x996a060)) called at
./etc/upgrade/4.0.9/content line 29
RT::Handle::__ANON__() called at
/usr/local/src/rt-4.4/sbin/../lib/RT/Handle.pm line 866
eval {...} called at /usr/local/src/rt-4.4/sbin/../lib/RT/Handle.pm
line 866
RT::Handle::InsertData(RT::Handle=HASH(0x4878b28),
"./etc/upgrade/4.0.9/content", undef) called at sbin/rt-setup-database
line 390
main::__ANON__() called at ./etc/upgrade/4.1.13/backcompat line 34
main::__ANON__(CODE(0x98e2f50)) called at sbin/rt-setup-database line
400
main::__ANON__() called at sbin/rt-setup-database line 403
main::action_insert("backcompat", ARRAY(0xe413f0), "action", "upgrade",
"prompt-for-dba-password", 1, "datafile", undef, "datadir", ...) called
at sbin/rt-setup-database line 571
main::action_upgrade("action", "upgrade", "prompt-for-dba-password", 1,
"package", "RT") called at sbin/rt-setup-database line 210
(/usr/share/perl/5.20/Carp.pm:169)
Then the upgrades to 4.0.12 through 4.1.0 run through without issue, but
after that:
Processing 4.1.1
Now populating database schema.
[11815] [Wed Nov 25 10:44:40 2015] [critical]: DBD::mysql::st execute
failed: Duplicate column name 'Disabled' at
/usr/local/src/rt-4.4/sbin/../lib/RT/Handle.pm line 552.
(/usr/local/src/rt-4.4/sbin/../lib/RT.pm:390)
DBD::mysql::st execute failed: Duplicate column name 'Disabled' at
/usr/local/src/rt-4.4/sbin/../lib/RT/Handle.pm line 552.
Makefile:391: recipe for target 'upgrade-database' failed
make: *** [upgrade-database] Error 255
How can I fix this issue? Can't find anything in the upgrade docs, let
alone UPGRADING.mysql, that points to a possible cause for these errors.
Thanks for any pointers!
Regards,
--ck
[rt-users] "Ticketmaster of the day" functionality
Hi all, what's the easiest way to implement a functionality where - one person per day is made "Ticket master" and receives all incoming new tickets as well as replies to unowned tickets - Nobody else receives these mails - Across several queues (3-5) Can this be accomplished using a scrip? Would I be better off just forwarding all mail to a specific mail alias (a CC or AdminCC with a role contact like ticketmas...@mycompany.com), and then updating that mail alias daily? Thanks for some pointers! Regards, --ck - RT 4.4 and RTIR Training Sessions https://bestpractical.com/training * Los Angeles - September, 2016
[rt-users] Automatted parsing of mails entering an RT queue
Hi all, we've been using RT for almost 15 years now with great success, but our growing company needs a little more automation now. As we are a hosting company /carrier, we frequently receive abuse reports and security advisories (for example, automatted scans for UDP amplifiers by the German national CERT). These enter our abuse queue. I would like to parse these mails automatically, and write a parsing toolkit for each different type of abuse mail (either by sender, or by specific content signature, or something like that), in order to extract the affected URIs / IP addresses from the mails and pass them on to an abuse handling script for further action. How would I do that? Are there any articles in the RT wiki that might be a good starting point? Unfortunately, the "automating RT" page is more about crontool than about the kind of automation I'm looking for. Thanks a lot, --ck - RT 4.4 and RTIR Training Sessions https://bestpractical.com/training * Paris - April 24-26, 2017
Re: [rt-users] Automatted parsing of mails entering an RT queue
Am 02.03.17 um 15:43 schrieb Matt Zagrabelny: > What version are you using CK? > > -m > Hi, we're using 4.2.8. Regards, --ck - RT 4.4 and RTIR Training Sessions https://bestpractical.com/training * Paris - April 24-26, 2017
Re: [rt-users] RT 3.6.4, user list too long when resolving multiple tickets
Emmanuel Lacour schrieb: On queue with Id 33, you gave right OwnTicket to Group 5 and Group 5 is usually the Unprivileged group! I removed that privilege from the respective queue (it is a test queue that was never actually used), and double-checked all other queues. However, I found a couple other queues in our installation that have Rights like CreateTicket, CommentOnTicket, ReplyTicket, ModifyTicket or others (*not* OwnTicket) set. Is this a problem, too? The issue persists (I have tested it with Elements/SelectOwner). Regards, --ck -- Christopher Kunz | Geschäftsführung | ch...@filoo.de Filoo GmbH | Tilsiter Str. 1 | 33449 Langenberg | HRB4355 AG Gütersloh Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz Hotline: 07000-3378658 | Fax: 01805-963951172 (jew. 14 ct./Min.) ___ 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
Re: [rt-users] RT 3.6.4, user list too long when resolving multiple tickets
Emmanuel Lacour schrieb: On Mon, Feb 02, 2009 at 05:03:26PM +0100, Christopher Kunz (Filoo GmbH) wrote: Emmanuel Lacour schrieb: On queue with Id 33, you gave right OwnTicket to Group 5 and Group 5 is usually the Unprivileged group! I removed that privilege from the respective queue (it is a test queue that was never actually used), and double-checked all other queues. THere was also OwnTicket granted to Everyone on this queue, did you removed it? That did the trick. Thanks so much! Regards, --ck -- Christopher Kunz | Geschäftsführung | ch...@filoo.de Filoo GmbH | Tilsiter Str. 1 | 33449 Langenberg | HRB4355 AG Gütersloh Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz Hotline: 07000-3378658 | Fax: 01805-963951172 (jew. 14 ct./Min.) ___ 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
Re: [rt-users] RT 3.6.4, user list too long when resolving multiple tickets
Emmanuel Lacour schrieb: On Mon, Feb 02, 2009 at 01:33:19PM +0100, Christopher Kunz (Filoo GmbH) wrote: Emmanuel Lacour schrieb: you seems to gave OwnTicket right to everyone or unprivileged users, check your permissions. Any other ideas? Is DBIx::SearchBuilder up to date? Yes, it's current: cpan[12] r DBIx::SearchBuilder All modules are up to date for DBIx::SearchBuilder Regards, --ck -- Christopher Kunz | Geschäftsführung | ch...@filoo.de Filoo GmbH | Tilsiter Str. 1 | 33449 Langenberg | HRB4355 AG Gütersloh Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz Hotline: 07000-3378658 | Fax: 01805-963951172 (jew. 14 ct./Min.) ___ 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
Re: [rt-users] RT 3.6.4, user list too long when resolving multiple tickets
| OwnTicket | RT::Queue | 29 | 0 | 0 | | 881 | Group | 53747 | OwnTicket | RT::Queue | 29 | 0 | 0 | | 923 | Group | 268168 | OwnTicket | RT::Queue | 29 | 0 | 0 | | 1139 | Group |3508 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 1000 | Group |4054 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 954 | Group |5054 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 1116 | Group |7086 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 1069 | Group |7462 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 977 | Group |7616 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 1093 | Group | 225814 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 1046 | Group | 289503 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 1023 | Group | 312162 | OwnTicket | RT::Queue | 30 | 0 | 0 | | 1268 | Group |1642 | OwnTicket | RT::Queue | 32 | 0 | 0 | | 1245 | Group |4054 | OwnTicket | RT::Queue | 32 | 0 | 0 | | 1222 | Group |7086 | OwnTicket | RT::Queue | 32 | 0 | 0 | | 1163 | Group |7616 | OwnTicket | RT::Queue | 32 | 0 | 0 | | 1176 | Group | 3 | OwnTicket | RT::Queue | 33 | 0 | 0 | | 1179 | Group | 5 | OwnTicket | RT::Queue | 33 | 0 | 0 | | 1177 | Requestor | 349496 | OwnTicket | RT::Queue | 33 | 0 | 0 | | 1186 | Group | 4 | OwnTicket | RT::Queue | 34 | 0 | 0 | | 1183 | Owner | 349523 | OwnTicket | RT::Queue | 34 | 0 | 0 | | 1191 | Group | 4 | OwnTicket | RT::Queue | 35 | 0 | 0 | |2 | Group | 11 | OwnTicket | RT::System |1 | 0 | 0 | +--+---+-+---++--+-+---+ 66 rows in set (0.00 sec) Regards, --ck -- Christopher Kunz | Geschäftsführung | ch...@filoo.de Filoo GmbH | Tilsiter Str. 1 | 33449 Langenberg | HRB4355 AG Gütersloh Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz Hotline: 07000-3378658 | Fax: 01805-963951172 (jew. 14 ct./Min.) ___ 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
Re: [rt-users] RT 3.6.4, user list too long when resolving multiple tickets
kem cho schrieb: Check this out: http://www.gossamer-threads.com/lists/rt/users/81858#81858 Nice workaround, works fine for me. Owner change is very rarely used in our setup, anyway. Regards, --ck -- Christopher Kunz | Geschäftsführung | ch...@filoo.de Filoo GmbH | Tilsiter Str. 1 | 33449 Langenberg | HRB4355 AG Gütersloh Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz Hotline: 07000-3378658 | Fax: 01805-963951172 (jew. 14 ct./Min.) ___ 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
Re: [rt-users] RT 3.6.4, user list too long when resolving multiple tickets
Emmanuel Lacour schrieb: you seems to gave OwnTicket right to everyone or unprivileged users, check your permissions. Currently, global Group Rights are as follows: Everyone: CreateTicket Privileged: ShowOutgoingEmail Unprivileged: CreateTicket, ReplyToTicket, ShowOutgoingEmail, Watch Requestor: CreateTicket, ModifyTicket, ReplyToTicket All other relevant groups: No rights granted. For testing, I have now removed ShowOutgoingEmail and Watch from the Unprivileged group and the behavior does not seem to have changed. I have checked queue-specific groups and there are no additional default privileges. Any other ideas? Regards, --ck -- Christopher Kunz | Geschäftsführung | ch...@filoo.de Filoo GmbH | Tilsiter Str. 1 | 33449 Langenberg | HRB4355 AG Gütersloh Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz Hotline: 07000-3378658 | Fax: 01805-963951172 (jew. 14 ct./Min.) ___ 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] RT 3.6.4, user list too long when resolving multiple tickets
Hi all, since our upgrade to RT 3.6.4, the resolve multiple tickets functionality shows erratic behavior in my installation. When before, it only showed the privileged users (which are in the ballpark of 3-10 per queue), it then started to show *all* users who ever submitted tickets, including obvious spam and bogus users. This leads to inacceptable long loading times (the resolve multiple tickets page takes about 3 minutes to load). We're currently around ticket #74000 in our installation, so there are quite some ticket owners in the database... Unfortunately, I am not completely sure if the update to 3.6.4 is the actual reason for this change in behavior, since I have also made some minor changes in the configuration (which, of course, I don't remember now). Is there a switch in the config files that might have caused this behavior? Thanks for pointers, --ck -- Christopher Kunz | Geschäftsführung | ch...@filoo.de Filoo GmbH | Tilsiter Str. 1 | 33449 Langenberg | HRB4355 AG Gütersloh Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz Hotline: 07000-3378658 | Fax: 01805-963951172 (jew. 14 ct./Min.) ___ 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
