LookupSenderInExternalDatabase ?

RT Users
1

The flag LookupSenderInExternalDatabase is mentioned
in RT_SiteConfig.pm in the comments, but not actually
set or explained. (RT 3.0.6)

Can I somehow integrate an external database of users,
without just copying the data to RT? Of course, not
all users will be in the external db, so I’d have to
have some fallback to internal RT and to creating
users on the fly.

Alternatively (but not quite as cool) would be
to create users on the fly. Yes, I know RT does this,
but it always sets the Name = Email when doing so.
For me, the login name (we use an external auth method)
is related to, but not identical, to the email address
for most of my users. So I’d need to modify
either User_Overlay.pm::LoadOrCreateByEmail()
or User_Overlay.pm::Create() in order to cannonicallize
the Name. Which I would do, presumably in User_Local.pm,
except that I only want to make a tiny change, and not
have to override a large subroutine.

Well, any suggestions would be welcome.

  bobg
2

There are some changes needed for external lookup.
But I want to work on it…

3

“Bob Goldstein” bobg@uic.edu writes:

Alternatively (but not quite as cool) would be
to create users on the fly. Yes, I know RT does this,
but it always sets the Name = Email when doing so.
For me, the login name (we use an external auth method)
is related to, but not identical, to the email address
for most of my users. So I’d need to modify
either User_Overlay.pm::LoadOrCreateByEmail()
or User_Overlay.pm::Create() in order to cannonicallize
the Name. Which I would do, presumably in User_Local.pm,
except that I only want to make a tiny change, and not
have to override a large subroutine.

If I went this route, I’d patch Create() to include a canonicalize
function similar to the WebAuth ones. Though you could just have
people’s account names be their email addresses, and canonicalize the
external auth to match.

seph

4

There are some changes needed for external lookup.
But I want to work on it…

From which external source do you want to do the lookup? LDAP?

LDAP would work fine.  I was imagining that a subroutine
for ldap would be supplied, or I'd override that with
my own for special cases.

   bobg
5

“Bob Goldstein” bobg@uic.edu writes:

…

If I went this route, I’d patch Create() to include a canonicalize
function similar to the WebAuth ones. Though you could just have
people’s account names be their email addresses, and canonicalize the
external auth to match.

No, I can’t can’t have people’s account names be their
email addresses. We already have a web auth system in
use for many years with many apps, and was so trivially
easy to hook into RT. (Sure, I could do a translate
somewhere internally, but I want to display our normal
names in RT as well, so that’s the wrong solution.)

You’re right about Create() being a good place for this.
But my problem is really a question of RT style:
Create() is a big routine, and if I override it in
User_Local.pm, I have to copy over the entire routine
and change 2 lines. What happens if, in the next release,
Create() itself changes? Then I have to notice and
repatch my system.

I’d prefer that Create(), itself, natively called
some cannocicalize_email_to_name() funtion, which by default
just returned its argument. Then I could override that,
and be future-safe.

Is there a third way? I don’t see it, but I’m very new
to RT (only in the demo stage, about to pitch my boss that
we ought to take a serious look), so maybe I’m overlooking
something.

  bobg
6

If I went this route, I’d patch Create() to include a canonicalize
function similar to the WebAuth ones. Though you could just have
people’s account names be their email addresses, and canonicalize the
external auth to match.

I’d prefer that Create(), itself, natively called
some cannocicalize_email_to_name() funtion, which by default
just returned its argument. Then I could override that,
and be future-safe.

Make it a clean patch, and submit it. maybe it’ll get picked up.

seph