Re: [rt-users] Name in Use
Hello, Recently had a chance to hack on the extension. In the latest available version you can only update users' info from external source only by Name. This has been fixed in multiple-emails branch along with more fixes and new features. On Fri, May 13, 2011 at 5:34 PM, Giuseppe Sollazzo gsoll...@sgul.ac.uk wrote: Ok - there's a problem with this solution. If I limit the match to the EmailAddress, ldap data are not imported. Is the only solution possible that of using two different definition of the ldap, one for auth and one for info? Cheers, G On 12/05/11 16:27, Giuseppe Sollazzo wrote: Ah, right. I suppose I need to change 'attr_match_list' = [ 'Name', 'EmailAddress', 'RealName', ], to 'attr_match_list' = [ 'EmailAddress', ], ? Thanks, G On 12/05/11 16:17, Thomas Sibley wrote: On 05/12/2011 11:11 AM, Giuseppe Sollazzo wrote: Hi, I've noticed this behaviour that I'm not sure how to explain. I'm experimenting with our externally facing queue. There seems to be a problem about people with same name creating tickets as external users. I've got this relevant bits of configuration: Set( @Plugins, qw(RT::Authen::ExternalAuth)); Set($ExternalAuthPriority, [ 'My_LDAP' ] ); Set($ExternalInfoPriority, [ 'My_LDAP' ] ); Set($AutoCreateNonExternalUsers, 1); Show us the actual config that matters, please. Your ldap settings for My_LDAP. The likely problem is that you're matching on Realname, which is almost never what you want (as you've found out). Thomas -- Giuseppe Sollazzo Senior Systems Analyst Computing Services Information Services St. George's, University Of London Cranmer Terrace London SW17 0RE Email: gsoll...@sgul.ac.uk Direct Dial: +44 20 8725 5160 Fax: +44 20 8725 3583 -- Best regards, Ruslan.
[rt-users] How you manage cc.
Hi all. I would like to known how you manage your ticket when some user send a message to our-rt-alias and put in cc: lot of users. so when the «lot of users» answer the first mail (not the second one) rt create lots of tickets (each answer). Regards. -- Albert SHIH DIO batiment 15 Observatoire de Paris Meudon 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 Heure local/Local time: lun 16 mai 2011 11:45:39 CEST
Re: [rt-users] Re move RT
Hello Thomas I solved the problem i had make the command with an letter ... now it works : make make install best regards john s. -- View this message in context: http://old.nabble.com/Remove-RT-tp31503916p31628189.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Request Tracker web UI logs out after Respond, Resolve and Take actions
Kevin, I solved the issue. The problem was the fact that I set the URL in the config file to: '192.168.1.2/rt/' The final '/' was the problem, causing RT to request 192.168.1.2/rt//subdirectories (notice the // ) when I perform actions. Anyways, issue solved. Thanks for the response ( sorry for the delay) 2011/4/26, Kevin Falcone falc...@bestpractical.com: On Mon, Apr 25, 2011 at 11:04:35PM +0100, Brahim Sakka wrote: The RT web interface logs out whenever I hit the update ticket button when responding; commenting, resolving , etc. Is this normal behavior? And if not how can I fix it? Sounds like you have some of your urls set up wrong (those actions redirect). Are you accessing RT through one host name and being sent to a different host after responding or resolving -kevin
[rt-users] Load Saved charts
Hi: Rt-3.8.8 Mysql5 and apache2 with mod_perl2 Loading saved charts seems not to be working, Created a search, charted it , saved the chart , ran a second search , charted it, but when trying to load the first saved chart, all I get is the second chart refreshed?? I am not sure if the Saved chart function is not saving the query, or if the current search is over ridding the chart query? Did anyone come across this ? and is there a known fix? Regards; Roy
Re: [rt-users] How you manage cc.
Albert,
We put instructions in our template that says to NOT use Reply All because
RT will take care of all other correspondence.
Another way would be to make sure the ticket number is in the subject line.
If there is a reference to the ticket number in the subject line [ie.
Subject: Request Titled: {$Ticket-Subject} has been created], then RT
puts the correspondence with that ticket and doesn't create a new one. If RT
doesn't have a ticket number to refer to, it creates a new one. So . if
they hit Reply All and there* is a reference *to the ticket number
(url+ticket) in the subject line, RT will NOT create a new ticket.
Hope this helps.
Kenn
LBNL
On Mon, May 16, 2011 at 2:46 AM, Albert Shih albert.s...@obspm.fr wrote:
Hi all.
I would like to known how you manage your ticket when some user send a
message to
our-rt-alias
and put in
cc: lot of users.
so when the «lot of users» answer the first mail (not the second one) rt
create lots of tickets (each answer).
Regards.
--
Albert SHIH
DIO batiment 15
Observatoire de Paris Meudon
5 Place Jules Janssen
92195 Meudon Cedex
Téléphone : 01 45 07 76 26/06 86 69 95 71
Heure local/Local time:
lun 16 mai 2011 11:45:39 CEST
[rt-users] [RT] Message Threading
Unfortunately, email systems have evolved in such a way that the standard headers `References' and `In-Reply-To' are horribly [ab]used; the result is that interfaces for navigating threads invariably mangle threading (in my opinion, the main problem is caused by the fact that nobody cares what `In-Reply-To' says and everybody makes naive assumptions about what `References' supplies). In any case, I dare you to go here: http://www.nntp.perl.org/group/perl.perl5.porters/2011/05/msg172431.html and play around with `Thread Previous' and `Thread Next', and then provide an explanation for WTF is going on (note dates too). Now, admittedly, this isn't necessarily a problem with perlbug or rt.perl.org's software, but I would add that the request tracker exacerbates this situation by flinging copies of emails all over the place with various Message-Ids and semi-spoofed `From' headers. Surely something can be done to make working via email more seamless; the request tracker should just be a third-party recording the discussion (and only spoofing messages sent explicitly via its interface). Sincerely, Michael Witten
Re: [rt-users] [RT] Message Threading
Surely something can be done to make working via email more seamless; the request tracker should just be a third-party recording the discussion (and only spoofing messages sent explicitly via its interface). A couple things to note: perlbug is running an RT that's two major releases out of date. perlbug has a custom layer of extra magic to integrate with perl5-porters that's entirely unrelated to what RT does out of the box. All that is to say, I'd love to discuss how RT 4.0 does threading and how we can make it better. How perlbug does it is wildly off-topic here. ;) Best, Jesse
Re: [rt-users] [RT] Message Threading
On Mon, May 16, 2011 at 11:48, Jesse Vincent je...@bestpractical.com wrote: perlbug is running an RT that's two major releases out of date. perlbug has a custom layer of extra magic to integrate with perl5-porters that's entirely unrelated to what RT does out of the box. Well, then, there's not much point in discussion the current RT at all, as it will have no useful effect for me.
Re: [rt-users] Load Saved charts
On Mon, May 16, 2011 at 04:18:21PM +, Raed El-Hames wrote: Rt-3.8.8 Mysql5 and apache2 with mod_perl2 Loading saved charts seems not to be working, Created a search, charted it , saved the chart , ran a second search , charted it, but when trying to load the first saved chart, all I get is the second chart refreshed?? I am not sure if the Saved chart function is not saving the query, or if the current search is over ridding the chart query? Did anyone come across this ? and is there a known fix? This sounds like a bug Emmanuel reported and fixed, but it was against 3.8.6 and should be fixed in 3.8.8. It was bug 14002 -kevin pgpMtyNzDmFLV.pgp Description: PGP signature
Re: [rt-users] [RT] Message Threading
On 05/16/2011 9:43 AM, Michael Witten wrote: Unfortunately, email systems have evolved in such a way that the standard headers `References' and `In-Reply-To' are horribly [ab]used; the result is that interfaces for navigating threads invariably mangle threading (in my opinion, the main problem is caused by the fact that nobody cares what `In-Reply-To' says and everybody makes naive assumptions about what `References' supplies). In any case, I dare you to go here: http://www.nntp.perl.org/group/perl.perl5.porters/2011/05/msg172431.html and play around with `Thread Previous' and `Thread Next', and then provide an explanation for WTF is going on (note dates too). Now, admittedly, this isn't necessarily a problem with perlbug or rt.perl.org's software, but I would add that the request tracker exacerbates this situation by flinging copies of emails all over the place with various Message-Ids and semi-spoofed `From' headers. Surely something can be done to make working via email more seamless; the request tracker should just be a third-party recording the discussion (and only spoofing messages sent explicitly via its interface). Sincerely, Michael Witten Looks like whatever software is threading the messages is not compensating for time zones and/or is running on utc. If you wanted a guess.
Re: [rt-users] [RT] Message Threading
On Mon, May 16, 2011 at 12:45, 20/20 Lab l...@pacbell.net wrote: On 05/16/2011 9:43 AM, Michael Witten wrote: Unfortunately, email systems have evolved in such a way that the standard headers `References' and `In-Reply-To' are horribly [ab]used; the result is that interfaces for navigating threads invariably mangle threading (in my opinion, the main problem is caused by the fact that nobody cares what `In-Reply-To' says and everybody makes naive assumptions about what `References' supplies). In any case, I dare you to go here: http://www.nntp.perl.org/group/perl.perl5.porters/2011/05/msg172431.html and play around with `Thread Previous' and `Thread Next', and then provide an explanation for WTF is going on (note dates too). Now, admittedly, this isn't necessarily a problem with perlbug or rt.perl.org's software, but I would add that the request tracker exacerbates this situation by flinging copies of emails all over the place with various Message-Ids and semi-spoofed `From' headers. Surely something can be done to make working via email more seamless; the request tracker should just be a third-party recording the discussion (and only spoofing messages sent explicitly via its interface). Sincerely, Michael Witten Looks like whatever software is threading the messages is not compensating for time zones and/or is running on utc. If you wanted a guess. Well, it's worse than that: You'll notice that following `Thread Previous' lands you on the top message from which no other message in the thread is accessible; the link in my original email to the rt-users list was found by running through the URL message ID numbers by hand because it is otherwise completely impossible to retrieve. Also, the latest message from Thomas Sibley, which can be seen here: http://rt.perl.org/rt3//Public/Bug/Display.html?id=90632 does not appear to have even been sent out to the perl5-porters list (at least yet). However, as Jesse has pointed out, this is perhaps a bit of a digression from the affairs of the rt-users list.
[rt-users] ExternalAuth And Numeric LDAP/AD ID problem
Hello,
Our AD usernames are numeric.
I noticed that during login, if the username is numeric, it runs the following
query:
SELECT * FROM Users WHERE id = 'ID'
if it's not numeric, it does a lookup on the 'Name' field.
I took over a 3.6 install which had a small customization in
'share/html/autohandler' which seems simple enough:
if ($user =~ /^\d+$/) {
$user = rt$user;
}
So it would authenticate with numeric ID to AD, but prefix it with 'rt' on the
RT side when populating the 'Name' field.
I am trying to replicate this in the 4.0 install.
Seems like it would be an easy change in
'local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm', but I
haven't been able to find the right spot to prefix $username. But then again,
I'm not that good at figuring out other people's code.
Any thoughts / Pointers?
AD is out of my control, and would involve a lot of red[ish] tape to change, so
I would prefer to avoid that.
Thanks!
-Roman
