Question about requestors - using something other than e-mail address?

The current ticketing system I am dealing with is pretty awful, but it does
have one useful feature - it allows tracking tickets by customer #.

Our billing system is pretty much the canonical datasource for customer
info, so it would be very helpful to be able to link tickets to a specific
customer number. (We also allow creation of tickets from the billing system
and then display any tickets there too, but that’s a separate issue.)

Just as an example, there might be several e-mail addresses that are valid
for contacts at ABC Co. ABC has a leased line from us, as well as other
services. We need some way to be able to track tickets associated with the
customer, and prehaps even with specific services (which get a unique
number in the billing system).

The master account might be 12345. The leased line is 12345A. Their web
site is 12345B and so on.

If their web site goes down, we’d want tickets to be opened on 12345B.

Does anyone have suggestions on the best way to handle this type of thing?
I have this feeling that there’s any easy answer. :slight_smile:

TIA

Stuart

Contact Jesse (owner/maintainer of RT) at sales@bestpractical.com. I’m sure
he’d be able to whip something up for you… :slight_smile:

Greg Smythe
SysAdmin
Intellstat Communications
WA State Resident-----Original Message-----
From: Stuart Krivis [mailto:ipswitch@apk.net]
Sent: Monday, February 25, 2002 12:21 PM
To: rt-users@lists.fsck.com
Subject: [rt-users] question about requestors - using something other than
e-mail address?

The current ticketing system I am dealing with is pretty awful, but it does
have one useful feature - it allows tracking tickets by customer #.

Our billing system is pretty much the canonical datasource for customer
info, so it would be very helpful to be able to link tickets to a specific
customer number. (We also allow creation of tickets from the billing system
and then display any tickets there too, but that’s a separate issue.)

Just as an example, there might be several e-mail addresses that are valid
for contacts at ABC Co. ABC has a leased line from us, as well as other
services. We need some way to be able to track tickets associated with the
customer, and prehaps even with specific services (which get a unique
number in the billing system).

The master account might be 12345. The leased line is 12345A. Their web
site is 12345B and so on.

If their web site goes down, we’d want tickets to be opened on 12345B.

Does anyone have suggestions on the best way to handle this type of thing?
I have this feeling that there’s any easy answer. :slight_smile:

TIA

Stuart

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Yesterday Stuart Krivis wrote:

… it would be very helpful to be able to link tickets to a specific
customer number. Just as an example, there might be several e-mail
addresses that are valid for contacts at ABC Co. … We need some way
to be able to track tickets associated with the customer

Does anyone have suggestions on the best way to handle this type of
thing?

I haven’t tried this myself (yet?), but I noticed that config.pm can
have functions CanonicalizeAddress() and LookupExternalUserInfo()
defined.

Could you use these to link together the different e-mail addresses, so
that RT treats them as the same user whichever address is used?

Smylers

Yesterday Stuart Krivis wrote:

… it would be very helpful to be able to link tickets to a specific
customer number. Just as an example, there might be several e-mail
addresses that are valid for contacts at ABC Co. … We need some way
to be able to track tickets associated with the customer

Does anyone have suggestions on the best way to handle this type of
thing?

I haven’t tried this myself (yet?), but I noticed that config.pm can
have functions CanonicalizeAddress() and LookupExternalUserInfo()
defined.

Could you use these to link together the different e-mail addresses, so
that RT treats them as the same user whichever address is used?

LookupExternalUserInfo() might be useful. I could use ‘Name’ to handle
customer #s - I think. :slight_smile: It looks like it depends upon having an LDAP
directory with all this info neatly stored away.

LDAP is one of those projects that we know we need to do, but haven’t
gotten to yet. It goes along with really normalizing the data in the
billing system so it’s useful.