Users with multiple email addresses using mergeusers

Hello,

Some of my users have two or more email addresses they can use to submit
requests to RT. To allow for this, I currently allow RT to create
accounts for unknown email addresses, and have installed MergeUsers.

I’d like to add the email addresses to the accounts prior to requests
coming from them, so that I could restrict usage, and avoid spam ticket
requests. I did a little searching to see if I could find where the
merged email addresses are stored, then decided maybe a kind
knowledgeable member of the list would help me out. Is this stored in
the database? I did a little digging, but didn’t see anything promising.

Any help would be appreciated.

Regards,

Sandra

Some of my users have two or more email addresses they can use to submit
requests to RT. To allow for this, I currently allow RT to create
accounts for unknown email addresses, and have installed MergeUsers.

I’d like to add the email addresses to the accounts prior to requests
coming from them, so that I could restrict usage, and avoid spam ticket
requests. I did a little searching to see if I could find where the
merged email addresses are stored, then decided maybe a kind
knowledgeable member of the list would help me out. Is this stored in
the database? I did a little digging, but didn’t see anything promising.

They’re stored in a second User account, so create a new user with the
secondary email address and merge them. There are command line tools
for merging users, so if you can script the user creation with perl or
an initialdata file, you can then use the command line tool to
automate the merging.

-kevin

They’re stored in a second User account, so create a new user with the
secondary email address and merge them. There are command line tools for
merging users, so if you can script the user creation with perl or an
initialdata file, you can then use the command line tool to automate the
merging. -kevin

Here’s a related question that perhaps you or someone else can shed some
light on. We have some code in procmail that wants to verify senders
against tickets in advance, so part of the query includes
‘(Requestor.EmailAddress = ‘$from’ OR Cc.EmailAddress = ‘$from’)’,
passed to the rt script. The way MergeUsers functions, the TicketSQL
does not select tickets that are owned by the primary user when a merged
user sends the message. That is, if I send from a merged address, the
ticket is created with the canonical account, and the above query
fails. I’m trying to see what would be needed to be added to MergeUsers
to allow that to work as intended, which would be that all addresses in
the merge set should be valid for that query condition. I think it may
be stretching the purpose of MergeUsers, but at the same time, that
TicketSQL condition really should evaluate to true if $from is any of
the merged user addresses. In fact, it looks like the redefined ‘Next’
method may be the root cause, but I assume that not doing this would
cause problems elsewhere. If so, any ideas on alternate queries that
would accomplish the desired result?

Thanks,
MarkMark D. Nagel, CCIE #3177 mnagel@willingminds.com
Principal Consultant, Willing Minds LLC (http://www.willingminds.com)
cell: 949-279-5817, desk: 714-495-4001, fax: 714-646-8277

** For faster support response time, please
** email support@willingminds.com or call 714-495-4000

Here’s a related question that perhaps you or someone else can shed some
light on. We have some code in procmail that wants to verify senders
against tickets in advance, so part of the query includes
‘(Requestor.EmailAddress = ‘$from’ OR Cc.EmailAddress = ‘$from’)’,
passed to the rt script.

Why are you doing this type of access control at the procmail level
instead of just configuring rights appropriately within RT? If you only
hand out ReplyToTicket and CommentOnTicket to the appropriate watcher
roles (Requestor + Cc here), then RT will do this check for you (and
merged users might even Just Work the way you expect).

Why are you doing this type of access control at the procmail level
instead of just configuring rights appropriately within RT? If you only
hand out ReplyToTicket and CommentOnTicket to the appropriate watcher
roles (Requestor + Cc here), then RT will do this check for you (and
merged users might even Just Work the way you expect).

Well, I didn’t want to get into the deep details unnecessarily, but
since you insist :). The check is performed as part of an automerge
mechanism we developed to avoid ticket Cc storms. You know, the storms
that develop when someone Cc’s the original message to 20 people
including RT, and they all start emailing back and forth, each message
creating a brand new ticket? The solution we worked out, which has been
very successful, is to pass the original message through a filter that
rewrites the subject. A number of conditions must match:

* subject must match (fuzzy matching, allows for Re:, Fwd:, etc.)
* sender must be a requestor or cc (this is the condition I reported)
* last update must be recent (within 24 hours)
* exactly one ticket must match

It is a heuristic, and there are some other exceptions to avoid
accidental merging, but that is the jist of it. This is not merging in
the traditional RT sense – we are taking a subject that has no ticket
ID and prepending one so that the message is placed into the correct
ticket. This is why we take such care to avoid accidental merging – it
is virtually impossible to unmerge, unlike an RT-level merge. I suppose
I could translate the logic into a Scrip that does an RT-level merge,
but I think the same problem with the sender match would be there.

I’ve sort of decided that the problem I uncovered is not really a big
problem, because the requesters that would need this behavior will not
generally end up being merged. I was testing a new RT instance today
discovered this behavior.

Thanks,
MarkMark D. Nagel, CCIE #3177 mnagel@willingminds.com
Principal Consultant, Willing Minds LLC (http://www.willingminds.com)
cell: 949-279-5817, desk: 714-495-4001, fax: 714-646-8277

** For faster support response time, please
** email support@willingminds.com or call 714-495-4000