Re: [rt-users] FW: Query for custom fields using 'NOT LIKE' is no longer working

[Landon Stewart]

On Sep 7, 2016, at 2:57 PM, Keith Creasy 
> wrote:

Apologies. I keep forgetting that replies to this list go to the sender and not 
to the list…


From: Keith Creasy
Sent: Wednesday, September 7, 2016 5:55 PM
To: 'Hien Ly' >
Subject: RE: [rt-users] Query for custom fields using 'NOT LIKE' is no longer 
working

Hi. I think I now know the problem but haven’t confirmed it yet.

We just created a new queue for requests submitted by beta testors. It’s sort 
of an approval queue though we are not using the built-in __approval queue, 
it’s just a regular queue. A “Type” custom field was created in it with 
different values from the existing Type field. I suspect that RT is matching 
the first field with the name CF.{Type} it finds. The reason is that if you use 
the field id CF.{11} it works.

CF.{11} NOT LIKE ‘Epic’

If this is a solution I’ll let you know but it is equally strange that “LIKE” 
works while “NOT LIKE” does not.

Is this a bug in RT?

I try to apply a single CF to multiple queues if it has the same name so it is 
treated the same.  Apart from that though - do you need to use LIKE?  Can you 
use != instead?  eg. CF.{cfname} != 'EPIC'.  I wonder if you have the same 
problem using != instead but yeah it does sound like a bug to me.  I did notice 
that you had strange quotations again though but I trust you are just using 
regular single quotes in actuality.

CF.{11} NOT LIKE ‘Epic’

--
Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
 lstew...@internap.com
 www.internap.com

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] FW: Query for custom fields using 'NOT LIKE' is no longer working

[Keith Creasy]

Apologies. I keep forgetting that replies to this list go to the sender and not 
to the list…


From: Keith Creasy
Sent: Wednesday, September 7, 2016 5:55 PM
To: 'Hien Ly' 
Subject: RE: [rt-users] Query for custom fields using 'NOT LIKE' is no longer 
working

Hi. I think I now know the problem but haven’t confirmed it yet.


We just created a new queue for requests submitted by beta testors. It’s sort 
of an approval queue though we are not using the built-in __approval queue, 
it’s just a regular queue. A “Type” custom field was created in it with 
different values from the existing Type field. I suspect that RT is matching 
the first field with the name CF.{Type} it finds. The reason is that if you use 
the field id CF.{11} it works.

CF.{11} NOT LIKE ‘Epic’


If this is a solution I’ll let you know but it is equally strange that “LIKE” 
works while “NOT LIKE” does not.

Is this a bug in RT?


From: Hien Ly [mailto:hien.thai...@gmail.com]
Sent: Wednesday, September 7, 2016 5:24 PM
To: Keith Creasy >
Subject: Re: [rt-users] Query for custom fields using 'NOT LIKE' is no longer 
working


How about NOT (CF.{Type} LIKE 'Epic') ?
On Sep 7, 2016 7:07 AM, "Keith Creasy" 
> wrote:
Hi everyone.


We are using RT 4.2.7. I think this used to work but now it isn’t. In a query 
like this:

Queue = 'Nimas' AND Priority > 49 AND (  Status = 'new' OR Status = 'open' OR 
Status = 'development' ) AND Due > 0 AND CF.{Type} NOT LIKE ‘Epic’


The “NOT LIKE” operator doesn’t work. I’ve tried it using the Query Builder and 
using Advanced. The “LIKE” operator does work. Does anyone have an idea for 
solving this?

Thanks.

Keith Creasy, Programmer and Technical Lead
American Printing House f/t Blind
Phone: 502.895.2405
Skype: keith537


-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Emails causing duplicate tickets?

[Alex Hall]

That's the behavior I want. My problem is that the email then stays in the
inbox or imap subfolder without being deleted. This causes RT to make a new
ticket from that same email over and over again, since it always thinks
it's a new message, even though it already processed it.

On Wed, Sep 7, 2016 at 2:08 PM, Kenneth Crocker 
wrote:

> Alex,
>
> In order for RT to know NOT to create a new email, there is supposed to be
> a reference to an existing ticket number in the subject or something like
> that. If people are just sending emails to RT with no referring ticket
> number, RT will think it is a new ticket request.
>
> Kenn
>
> On Wed, Sep 7, 2016 at 10:13 AM, Alex Hall  wrote:
>
>> Hi all,
>> I just ran into a very odd problem. I opened a ticket via email, which
>> worked. But I then saw three more tickets open from that same email, each
>> at the next mail polling. I haven't seen this problem before, and I don't
>> know where to look to tell RT what to do with fetched emails. As I said, I
>> only just started seeing this, which means I must have changed something.
>> All I did was add a few more queues to my fetchmailrc file, though. Are
>> there fetchmail options I should add, or is this an RT setting? If the
>> latter, is it in the web UI or somewhere in a configuration file? Thanks
>> for any help.
>>
>> --
>> Alex Hall
>> Automatic Distributors, IT department
>> ah...@autodist.com
>>
>> -
>> RT 4.4 and RTIR training sessions, and a new workshop day!
>> https://bestpractical.com/training
>> * Boston - October 24-26
>> * Los Angeles - Q1 2017
>>
>
>


-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Problems with RT::ExternalAuth::LDAP After Upgrading to 4.4

[Tim Gustafson]

> Which specific version of RT are you upgrading to? If you're upgrading
> to 4.4.0, you'll need to be aware that a new config setting is required,
> which doesn't appear in your config:
>
> Set($ExternalAuth, 1);
>
> In RT 4.4.1 we've removed the requirement to set this config.

I am upgrading to 4.4.0 right now.

Is it me, or is that configuration requirement missing from the
documentation page?

https://docs.bestpractical.com/rt/4.4.0/RT/Authen/ExternalAuth.html

-- 

Tim Gustafson
t...@ucsc.edu
831-459-5354
Baskin Engineering, Room 313A
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Emails causing duplicate tickets?

[Landon Stewart]

On Sep 7, 2016, at 10:13 AM, Alex Hall 
> wrote:

Hi all,
I just ran into a very odd problem. I opened a ticket via email, which worked. 
But I then saw three more tickets open from that same email, each at the next 
mail polling. I haven't seen this problem before, and I don't know where to 
look to tell RT what to do with fetched emails. As I said, I only just started 
seeing this, which means I must have changed something. All I did was add a few 
more queues to my fetchmailrc file, though. Are there fetchmail options I 
should add, or is this an RT setting? If the latter, is it in the web UI or 
somewhere in a configuration file? Thanks for any help.

Is fetchmail being told to delete mail from the mailbox after it has been 
fetched?  Deleting mail from the mailbox is the default behaviour AFAIK.  In 
any event, with or without deleting mail after it is fetched you'll probably 
want to use the 'uidl' keyword in your configuration to keep track of what 
messages are considered new on your side of things instead of relying on the 
server to decide what's new and what's not.

From 'man 1 fetchmailrc':

   -U | --uidl
  (Keyword: uidl)
  Force UIDL use (effective only with POP3).  Force client-side 
tracking of 'newness' of messages (UIDL stands for "unique ID listing"
  and  is  described  in RFC1939).  Use with 'keep' to use a 
mailbox as a baby news drop for a group of users. The fact that seen mes‐
  sages are skipped is logged, unless error logging is done through 
syslog while running in daemon  mode.   Note  that  fetchmail  may
  automatically  enable  this  option depending on upstream server 
capabilities.  Note also that this option may be removed and forced
  enabled in a future fetchmail version. See also: --idfile.

--
Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
 lstew...@internap.com
 www.internap.com

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Emails causing duplicate tickets?

[Alex Hall]

Hi all,
I just ran into a very odd problem. I opened a ticket via email, which
worked. But I then saw three more tickets open from that same email, each
at the next mail polling. I haven't seen this problem before, and I don't
know where to look to tell RT what to do with fetched emails. As I said, I
only just started seeing this, which means I must have changed something.
All I did was add a few more queues to my fetchmailrc file, though. Are
there fetchmail options I should add, or is this an RT setting? If the
latter, is it in the web UI or somewhere in a configuration file? Thanks
for any help.

-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Problems with RT::ExternalAuth::LDAP After Upgrading to 4.4

[Shawn M Moore]

> On Sep 7, 2016, at 12:13, Tim Gustafson  wrote:
> 
> Hi,

Hi Tim,

> I'm trying to upgrade my RT instance from 4.2 to 4.4.  I use
> RT::ExternalAuth::LDAP to authenticate users from my OpenLDAP server.
> This configuration has been working perfectly in RT 4.2 (and earlier
> versions) for years.  After upgrading to RT 4.4, I am not able to log
> in to RT at all.  My RT_SiteConfig.pm and rt-log.txt files are
> attached.

Sorry about the trouble.

Which specific version of RT are you upgrading to? If you're upgrading to 
4.4.0, you'll need to be aware that a new config setting is required, which 
doesn't appear in your config:

Set($ExternalAuth, 1);

In RT 4.4.1 we've removed the requirement to set this config.

> Tim Gustafson
> t...@ucsc.edu
> 831-459-5354
> Baskin Engineering, Room 313A

Best,
Shawn



signature.asc
Description: Message signed with OpenPGP using GPGMail
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Problems with RT::ExternalAuth::LDAP After Upgrading to 4.4

[Tim Gustafson]

Hi,

I'm trying to upgrade my RT instance from 4.2 to 4.4.  I use
RT::ExternalAuth::LDAP to authenticate users from my OpenLDAP server.
This configuration has been working perfectly in RT 4.2 (and earlier
versions) for years.  After upgrading to RT 4.4, I am not able to log
in to RT at all.  My RT_SiteConfig.pm and rt-log.txt files are
attached.

The interesting thing to note is that the log file says *nothing*
about attempting to connect to any LDAP servers, and a tcpdump shows
no traffic from the RT server to the LDAP server, so I'm pretty sure
something is broken in my configuration file, but after staring at it
for hours and comparing it to the RT documentation, I can't find what
I'm doing wrong or what's changed between RT 4.2 and RT 4.4.

I am positive that the configuration file attached is the one being
used, because if I change the OwnerEmail setting, the login screen
shows the new value.

Any help at all is greatly appreciated.  Thanks!

-- 

Tim Gustafson
t...@ucsc.edu
831-459-5354
Baskin Engineering, Room 313A
[87694] [Wed Sep  7 16:08:52 2016] [debug]: Using lynx for HTML -> text 
conversion (/usr/local/lib/perl5/site_perl/RT/Interface/Email.pm:1490)
[87694] [Wed Sep  7 16:08:52 2016] [error]: FAILED LOGIN for tjg from x.x.x.x 
(/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm:826)
Trace begun at /usr/local/lib/perl5/site_perl/RT.pm line 304
Log::Dispatch::__ANON__('Log::Dispatch=HASH(0x807762180)', 'FAILED LOGIN for 
tjg from x.x.x.x') called at /usr/local/lib/perl5/site_perl/RT/Interface/Web.pm 
line 826
RT::Interface::Web::AttemptPasswordAuthentication('HASH(0x80fdfc168)') called 
at /usr/local/share/rt44/html/NoAuth/Login.html line 49
HTML::Mason::Commands::__ANON__('pass', 'pa$$w0rd', 'next', 
'90639347336f150cb529fe5c5b4ee3ff', 'user', 'tjg') called at 
/usr/local/lib/perl5/site_perl/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run('HTML::Mason::Component::FileBased=HASH(0x80ff1f8a0)',
 'pass', 'pa$$w0rd', 'next', '90639347336f150cb529fe5c5b4ee3ff', 'user', 'tjg') 
called at /usr/local/lib/perl5/site_perl/HTML/Mason/Request.pm line 1302
eval {...} at /usr/local/lib/perl5/site_perl/HTML/Mason/Request.pm line 1292
HTML::Mason::Request::comp(undef, undef, undef, 'pass', 'pa$$w0rd', 'next', 
'90639347336f150cb529fe5c5b4ee3ff', 'user', 'tjg') called at 
/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm line 605
RT::Interface::Web::MaybeShowNoAuthPage('HASH(0x80ff29180)') called at 
/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm line 316
RT::Interface::Web::HandleRequest('HASH(0x80ff29180)') called at 
/usr/local/share/rt44/html/autohandler line 53
HTML::Mason::Commands::__ANON__('user', 'tjg', 'next', 
'90639347336f150cb529fe5c5b4ee3ff', 'pass', 'pa$$w0rd') called at 
/usr/local/lib/perl5/site_perl/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run('HTML::Mason::Component::FileBased=HASH(0x80fdd9d08)',
 'user', 'tjg', 'next', '90639347336f150cb529fe5c5b4ee3ff', 'pass', 'pa$$w0rd') 
called at /usr/local/lib/perl5/site_perl/HTML/Mason/Request.pm line 1300
eval {...} at /usr/local/lib/perl5/site_perl/HTML/Mason/Request.pm line 1292
HTML::Mason::Request::comp(undef, undef, undef, 'user', 'tjg', 'next', 
'90639347336f150cb529fe5c5b4ee3ff', 'pass', 'pa$$w0rd') called at 
/usr/local/lib/perl5/site_perl/HTML/Mason/Request.pm line 481
eval {...} at /usr/local/lib/perl5/site_perl/HTML/Mason/Request.pm line 481
eval {...} at /usr/local/lib/perl5/site_perl/HTML/Mason/Request.pm line 433
HTML::Mason::Request::exec('RT::Interface::Web::Request=HASH(0x80fede7c8)') 
called at /usr/local/lib/perl5/site_perl/HTML/Mason/PSGIHandler.pm line 96
eval {...} at /usr/local/lib/perl5/site_perl/HTML/Mason/PSGIHandler.pm line 96
HTML::Mason::Request::PSGI::exec('RT::Interface::Web::Request=HASH(0x80fede7c8)')
 called at /usr/local/lib/perl5/site_perl/HTML/Mason/Interp.pm line 342
HTML::Mason::Interp::exec(undef, undef, 'user', 'tjg', 'next', 
'90639347336f150cb529fe5c5b4ee3ff', 'pass', 'pa$$w0rd') called at 
/usr/local/lib/perl5/site_perl/HTML/Mason/PSGIHandler.pm line 59
eval {...} at /usr/local/lib/perl5/site_perl/HTML/Mason/PSGIHandler.pm line 59
HTML::Mason::PSGIHandler::invoke_mason('HTML::Mason::PSGIHandler::Streamy=HASH(0x808c10600)',
 'HASH(0x80ff19c60)', 'HASH(0x80f3aa5d0)') called at 
/usr/local/lib/perl5/site_perl/HTML/Mason/PSGIHandler/Streamy.pm line 52
HTML::Mason::PSGIHandler::Streamy::__ANON__('CODE(0x80ffe5a98)') called at 
/usr/local/lib/perl5/site_perl/Plack/Util.pm line 339
Plack::Util::__ANON__('CODE(0x8064f9480)') called at 
/usr/local/lib/perl5/site_perl/Plack/Handler/Apache2.pm line 89
Plack::Handler::Apache2::call_app('Plack::Handler::Apache2', 
'Apache2::RequestRec=SCALAR(0x8029e4be8)', 'CODE(0x80fe850f0)') called at 
/usr/local/lib/perl5/site_perl/Plack/Handler/Apache2.pm line 126
Plack::Handler::Apache2::handler('Apache2::RequestRec=SCALAR(0x8029e4be8)') 
called at -e line 0
eval {...} at -e line 0

use utf8;

Set($rtname, 'RTDEV');

Set($DatabaseHost, 

Re: [rt-users] Moving entire RT instance between two servers?

[Parish, Brent]

Hi Alex

I recently shifted from physical server to VM.
First I downloaded the RT source and ran the configure and make fixdeps to get 
all the required Perl modules on the target machine.
(I also had some other modules I needed outside of core for extensions and 
custom code, had to get those by hand)

Then (like you said) I simply tar’ed up /opt/rt4 and moved it over, and copied 
over the mail config (/etc/aliases, /etc/postfix/main.cf, etc), as well as 
Apache config files.

I used mysqldump to copy the database over

I recommend removing var/mason_data/obj/*  (clear Mason Cache) after the move, 
and for cleanliness I generally reset all the logs too (apache, rt, etc).
If you are concerned, you could also increase verbosity on Apache logs for a 
bit to keep an eye on things.

Just double check all your config files (mail, RT, and Apache) for things like 
hostname or something else specific to new machine)


-  Brent



From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Alex Hall
Sent: Wednesday, September 07, 2016 8:05 AM
To: rt-users 
Subject: [rt-users] Moving entire RT instance between two servers?

Hi all,
I'm waiting for my work to set up a Debian server locally. In the meantime I 
continue to expand and use my test instance, which is on my own Digital Ocean 
server. When we have the local Debian server ready, is there any way for me to 
move the entire database from my server to the new one at work, along with the 
other configuration, fetchmailrc, and any other files? Or is overriding files 
and databases a recipe for disaster, and I'd be better off re-doing everything 
on the new server?

--
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Query for custom fields using 'NOT LIKE' is no longer working

[Keith Creasy]

Hi everyone.


We are using RT 4.2.7. I think this used to work but now it isn't. In a query 
like this:

Queue = 'Nimas' AND Priority > 49 AND (  Status = 'new' OR Status = 'open' OR 
Status = 'development' ) AND Due > 0 AND CF.{Type} NOT LIKE 'Epic'


The "NOT LIKE" operator doesn't work. I've tried it using the Query Builder and 
using Advanced. The "LIKE" operator does work. Does anyone have an idea for 
solving this?

Thanks.

Keith Creasy, Programmer and Technical Lead
American Printing House f/t Blind
Phone: 502.895.2405
Skype: keith537

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017