Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Users

User autocreation

 

 

Request Tracker users RSS feed   Index | Next | Previous | View Threaded


lists at akphs

May 3, 2006, 11:17 AM

Post #1 of 7 (1210 views)
Permalink
User autocreation

We don't think we dare enable auto-user creation due to spam issues.

But the usual flow is like this:

1) User emails support [at] ourdomai with an issue.
2) One of us creates an RT ticket, then replies, CCing RT, putting the [ourdomain #nnn] in the Subject.
3) Occasionally a customer is well-behaved enough to do a REPLY ALL, but that fails to update RT because the user isn't in RT.

Is there an easy way (presumably a scrip) to say "Any user that's ever been on a TO or CC list gets auto-added as an unprivileged user"?

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


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


elg at bu

May 3, 2006, 11:47 AM

Post #2 of 7 (1160 views)
Permalink
RE: User autocreation [In reply to]

Phil,

We're really new to RT and encountered a different but similar problem
of email mapping. Though this probably won't solve your problem, it
might give you a hint on where to go. What we wanted for inbound email
was the following logic:

1) If the email is from an account in our domain (i.e. X [at] bu), then
set the requestor to X (i.e. elg instead of elg [at] bu) and create the
account if necessary.

2) If the email comes from somewhere else but the email address is known
to the system (i.e. someone updated their profile), set the requestor to
that account.

3) For all other mail, set the requestor to a fixed account. In our
case, the account is called "external_user".

We're still checking to see if/how we could do this with a Scrip but, in
the mean time, we created our own mail authentication module to handle
the logic. We created a new file in "rt/lib/RT/Interface/Email/Auth"
called "BUMailFrom.pm" which is a copy of the MailFrom.pm authentication
file and added a line to RT_SiteConfig.pm with:

@RT::MailPlugins = ( "Auth::BUMailFrom" );

The differences between BUMailFrom.pm and MailFrom.pm are:

$ diff BUMailFrom.pm MailFrom.pm
46c46
< package RT::Interface::Email::Auth::BUMailFrom;
---
> package RT::Interface::Email::Auth::MailFrom;
48a49,50
> # This is what the ordinary, non-enhanced gateway does at the moment.
>
60d61
<
63,76c64
< my $username;
<
< if ( $Address =~ m/.*\@bu.edu$/i ) {
< $username = $Address;
< $username =~ s/\@bu.edu$//;
< if ( $Name == $Address ) {
< $name = $username;
< }
< $CurrentUser->LoadByName($username);
< }
<
< unless ( $CurrentUser->Id ) {
< $CurrentUser->LoadByEmail($Address);
< }
---
> $CurrentUser->LoadByEmail($Address);
82,87d69
< unless ( $CurrentUser->Id ) {
< if ( !( $Address =~ m/.*\@bu.edu$/i )) {
< $CurrentUser->LoadByName("external_user");
< }
< }
<
90a73
>
97c80
< $RT::Logger->crit( "Auth::BUMailFrom couldn't find the
'Unprivileged' internal group" );
---
> $RT::Logger->crit( "Auth::MailFrom couldn't find the
'Unprivileged' internal group" );
104c87
< $RT::Logger->crit( "Auth::BUMailFrom couldn't find the
'Everyone' internal group");
---
> $RT::Logger->crit( "Auth::MailFrom couldn't find the
'Everyone' internal group");
189,194c172
< if ( $Address =~ m/.*\@bu.edu$/i ) {
< $CurrentUser = CreateUser( $username, $Address, $Name, $Address,
$args{'Message'} );
< }
< else {
< $CurrentUser = CreateUser( undef, $Address, $Name, $Address,
$args{'Message'} );
< }
---
> $CurrentUser = CreateUser( undef, $Address, $Name, $Address,
$args{'Message'} );


This seems to work in our testbed but, as we haven't put the system into
production yet, I can't yet tell you if there are any oddities.


Eric Gauthier
Network Engineer
617-353-8218 ~^~ elg [at] nsegc
Boston University - Office of IT




-----Original Message-----
From: rt-users-bounces [at] lists
[mailto:rt-users-bounces [at] lists] On Behalf Of Phil
Smith III
Sent: Wednesday, May 03, 2006 2:18 PM
To: rt-users [at] lists
Subject: [rt-users] User autocreation

We don't think we dare enable auto-user creation due to spam issues.

But the usual flow is like this:

1) User emails support [at] ourdomai with an issue.
2) One of us creates an RT ticket, then replies, CCing RT, putting the
[ourdomain #nnn] in the Subject.
3) Occasionally a customer is well-behaved enough to do a REPLY ALL, but
that fails to update RT because the user isn't in RT.

Is there an easy way (presumably a scrip) to say "Any user that's ever
been on a TO or CC list gets auto-added as an unprivileged user"?

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com Commercial support:
sales [at] bestpractical


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
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


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


sturner at MIT

May 3, 2006, 11:56 AM

Post #3 of 7 (1161 views)
Permalink
Re: User autocreation [In reply to]

At Wednesday 5/3/2006 02:17 PM, Phil Smith III wrote:
>We don't think we dare enable auto-user creation due to spam issues.
>
>But the usual flow is like this:
>
>1) User emails support [at] ourdomai with an issue.
>2) One of us creates an RT ticket, then replies, CCing RT, putting
>the [ourdomain #nnn] in the Subject.
>3) Occasionally a customer is well-behaved enough to do a REPLY ALL,
>but that fails to update RT because the user isn't in RT.
>
>Is there an easy way (presumably a scrip) to say "Any user that's
>ever been on a TO or CC list gets auto-added as an unprivileged user"?

I can't think of one - this info is hidden away in transactions and
it would seem costly to trawl through all transactions each time a
reply came in.

The whole flow described seems prone to mistakes - for example, I'll
guess people occasionally make typos when putting [ourdomain #nnn] in
the Subject. The issue of customers doing reply or reply all isn't a
question of good behavior - why should the customer be expected to
know what your workflow is and that you need them to "reply all"?

A good spam filter and a more conventional use of RT might work out better -

Steve

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


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


lists at akphs

May 3, 2006, 12:44 PM

Post #4 of 7 (1176 views)
Permalink
RE: User autocreation [In reply to]

Well...ok. I'm not clear on a few things:

- How do typos in the Subject: affect this? Typos mean extra tickets if it doesn't recognize the "magic string"; what else will they affect?

- I was being semi-facetious about "well-behaved", but your point is well taken. I guess I could just remember to forward every note they send me back to RT, but that's also error-prone.

- What do you mean by "a more conventional use of RT"?

...phsiii
-----Original Message-----
From: Stephen Turner [mailto:sturner [at] MIT]
Sent: Wednesday, May 03, 2006 2:57 PM
To: Phil Smith III; rt-users [at] lists
Subject: Re: [rt-users] User autocreation

At Wednesday 5/3/2006 02:17 PM, Phil Smith III wrote:
>We don't think we dare enable auto-user creation due to spam issues.
>
>But the usual flow is like this:
>
>1) User emails support [at] ourdomai with an issue.
>2) One of us creates an RT ticket, then replies, CCing RT, putting
>the [ourdomain #nnn] in the Subject.
>3) Occasionally a customer is well-behaved enough to do a REPLY ALL,
>but that fails to update RT because the user isn't in RT.
>
>Is there an easy way (presumably a scrip) to say "Any user that's
>ever been on a TO or CC list gets auto-added as an unprivileged user"?

I can't think of one - this info is hidden away in transactions and
it would seem costly to trawl through all transactions each time a
reply came in.

The whole flow described seems prone to mistakes - for example, I'll
guess people occasionally make typos when putting [ourdomain #nnn] in
the Subject. The issue of customers doing reply or reply all isn't a
question of good behavior - why should the customer be expected to
know what your workflow is and that you need them to "reply all"?

A good spam filter and a more conventional use of RT might work out better -

Steve

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


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


sturner at MIT

May 3, 2006, 1:11 PM

Post #5 of 7 (1168 views)
Permalink
RE: User autocreation [In reply to]

At Wednesday 5/3/2006 03:44 PM, Phil Smith III wrote:
>Well...ok. I'm not clear on a few things:
>
>- How do typos in the Subject: affect this? Typos mean extra
>tickets if it doesn't recognize the "magic string"; what else will they affect?

I just meant what you describe - typos will mean that replies don't
get appended to the correct ticket, they will generate new tickets.

>- I was being semi-facetious about "well-behaved", but your point is
>well taken. I guess I could just remember to forward every note
>they send me back to RT, but that's also error-prone.
>
>- What do you mean by "a more conventional use of RT"?

Hello Phil,

I was thinking that the support [at] ourdomai address would be a feed
into RT and that autocreation would be turned on (assuming you solve
the spam problem outside of RT). The scrips would take care of
notifying your staff and directing mail to the customer. Then, any
reply would automatically come back to RT and be added to the right ticket.

It sounds like you're using your email list as the primary means of
communication, and that RT is just a back-end archive. Trouble is,
it's impossible to ensure that all the email correspondence gets into
RT attached to the right ticket. I'm even wondering if using RT is
overkill in this situation - perhaps an archive of mail sent to your
email list would work as well?

Steve

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


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


ruslan.zakirov at gmail

May 3, 2006, 2:06 PM

Post #6 of 7 (1162 views)
Permalink
Re: User autocreation [In reply to]

I agree with Stephen, but if you're going to use current scheme then:
* you staff should fill requestor field with customer's email and RT
would autocreate user
* look into ParseTicketForCc option in the config, but I don't
remember if it works replis/comments
* this discussion a bit of off-topic for rt-devel@

On 5/3/06, Phil Smith III <lists [at] akphs> wrote:
> We don't think we dare enable auto-user creation due to spam issues.
>
> But the usual flow is like this:
>
> 1) User emails support [at] ourdomai with an issue.
> 2) One of us creates an RT ticket, then replies, CCing RT, putting the [ourdomain #nnn] in the Subject.
> 3) Occasionally a customer is well-behaved enough to do a REPLY ALL, but that fails to update RT because the user isn't in RT.
>
> Is there an easy way (presumably a scrip) to say "Any user that's ever been on a TO or CC list gets auto-added as an unprivileged user"?
>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales [at] bestpractical
>
>
> 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
>


--
Best regards, Ruslan.


lists at akphs

May 3, 2006, 5:20 PM

Post #7 of 7 (1170 views)
Permalink
RE: User autocreation [In reply to]

Thanks. Re your list point: that's why I posted it on rt-users ;-)

-----Original Message-----
From: Ruslan Zakirov [mailto:ruslan.zakirov [at] gmail]
Sent: Wednesday, May 03, 2006 5:07 PM
To: Phil Smith III
Cc: rt-users [at] lists
Subject: Re: [rt-users] User autocreation

I agree with Stephen, but if you're going to use current scheme then:
* you staff should fill requestor field with customer's email and RT
would autocreate user
* look into ParseTicketForCc option in the config, but I don't
remember if it works replis/comments
* this discussion a bit of off-topic for rt-devel@

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


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

Request Tracker users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.