Dealing with ex-employees

I’m pretty sure this has been broached a number of times on the list, but I
couldn’t find anything. Any pointers to previous threads would be
appreciated.

How are people dealing with ex-employees? We’ve tossed a number of ideas
around about how to deal with their account, and all their previous tickets
(customers have a tendancy to just reply to a long-since-resolved ticket
instead of opening a new one), but we haven’t fully come to a solution that
everybody’s happy with.

The best idea thus far is to revoke all rights to RT (user may not be
granted rights, user may not access), then set up a custom Scrip that will
check to make sure the owner of the ticket being corresponded on may be
granted rights. If not, autorespond with a, ‘Please send a new message to
blahblahblah@sentex.net for help.’ But I’m not even sure if we can do this
– I haven’t looked at custom Scrip actions yet.

The best idea thus far is to revoke all rights to RT (user may not be
granted rights, user may not access),

the privileged/non-privileged distinction might be useful here. Or
groups may provide a useful abstraction barrier.

then set up a custom Scrip that will check to make sure the owner of
the ticket being corresponded on may be granted rights.

If I were dealing with this, I’d either set closed tickets to being
owned by nobody or change an ex-employee’s tickets to nobody. And have
followup to tickets owned by nobody going to the group, or the
manager.

seph

Thus spake seph (seph@directionless.org) [07/01/04 14:01]:

The best idea thus far is to revoke all rights to RT (user may not be
granted rights, user may not access),

the privileged/non-privileged distinction might be useful here. Or
groups may provide a useful abstraction barrier.

Yes, but if we leave the account with access to RT, they can continue to
correspond via e-mail to older tickets that they owned. While this isn’t
likely, it’s something we’d like to avoid.

then set up a custom Scrip that will check to make sure the owner of
the ticket being corresponded on may be granted rights.

If I were dealing with this, I’d either set closed tickets to being
owned by nobody or change an ex-employee’s tickets to nobody. And have
followup to tickets owned by nobody going to the group, or the
manager.

That’s what we’re trying to figure out. Is setting to ‘Nobody’ enough?
Should we make the delegators the owners? How badly will this screw up RT
statistics (i.e. Bob leaves, Bob had two thousand resolved tickets, now
Sally, a delegator, has an extra two thousand resolved tickets)?

I definitely don’t want to change the owner of Resolved tickets to Nobody,
as there are valid reasons for opening a once-resolved ticket.

Thus spake seph (seph@directionless.org) [07/01/04 14:01]:

The best idea thus far is to revoke all rights to RT (user may not be
granted rights, user may not access),

the privileged/non-privileged distinction might be useful here. Or
groups may provide a useful abstraction barrier.

Yes, but if we leave the account with access to RT, they can continue to
correspond via e-mail to older tickets that they owned. While this isn’t
likely, it’s something we’d like to avoid.

Setting bob’s email address to “” should take care of that issue.

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

Thus spake seph (seph@directionless.org) [07/01/04 14:01]:

The best idea thus far is to revoke all rights to RT (user may
not be
granted rights, user may not access),

the privileged/non-privileged distinction might be useful here. Or
groups may provide a useful abstraction barrier.

Yes, but if we leave the account with access to RT, they can continue
to
correspond via e-mail to older tickets that they owned. While this
isn’t
likely, it’s something we’d like to avoid.

Setting bob’s email address to “” should take care of that issue.

… and for the SECOND person that needs to happen for?

To the best of my understanding, RT isn’t very forgiving on having
multiple users with the same e-mail address.

I mentioned this once before, but this is a really serious design flaw,
based on an unfounded assumption that an e-mail address will never be
re-used by a different person, that person having potentially
completely different responsibilities or levels of security.

D

smime.p7s (2.31 KB)

Setting bob’s email address to “” should take care of that issue.

… and for the SECOND person that needs to happen for?

To the best of my understanding, RT isn’t very forgiving on having
multiple users with the same e-mail address.

The empty email address is a special case and should work just fine for
multiple users.

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

Setting bob’s email address to “” should take care of that issue.

… and for the SECOND person that needs to happen for?

To the best of my understanding, RT isn’t very forgiving on having
multiple users with the same e-mail address.

The empty email address is a special case and should work just fine for
multiple users.

Is that a recent change?

D

smime.p7s (2.31 KB)

Thus spake Jesse Vincent (jesse@bestpractical.com) [07/01/04 14:24]:

The empty email address is a special case and should work just fine for
multiple users.

What does this ‘special case’ do? Does the e-mail get rejected? Does all
correspondance on the ticket go through the normal queue Scrips (i.e.
messages sent to AdminCc:'s and Cc:'s), or just sit there in the empty
ticket?

Thus spake Jesse Vincent (jesse@bestpractical.com) [07/01/04 14:24]:

The empty email address is a special case and should work just fine for
multiple users.

What does this ‘special case’ do? Does the e-mail get rejected? Does all
correspondance on the ticket go through the normal queue Scrips (i.e.
messages sent to AdminCc:'s and Cc:'s), or just sit there in the empty
ticket?

That RT user will no longer have an email address. If you’ve removed
them as a privileged user, they’ll won’t be able to log in, send mail
through RT or have RT send them mail. It doesn’t solve the problem of
local configuration not notifying anyone other than the owner of a
ticket.


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

Thus spake Jesse Vincent (jesse@bestpractical.com) [07/01/04 14:48]:

What does this ‘special case’ do? Does the e-mail get rejected? Does all
correspondance on the ticket go through the normal queue Scrips (i.e.
messages sent to AdminCc:'s and Cc:'s), or just sit there in the empty
ticket?

That RT user will no longer have an email address. If you’ve removed
them as a privileged user, they’ll won’t be able to log in, send mail
through RT or have RT send them mail. It doesn’t solve the problem of
local configuration not notifying anyone other than the owner of a
ticket.

That’s the problem we’re trying to solve – what happens with all their old
tickets? We don’t want the notifications going to them (the blanked e-mail
address works for that, and also avoids some problems with just fully
disabling access to RT for that user), but re-assigning tickets is something
we’d like to avoid. It and the custom Scrip action are the best options so
far, just wondering if there’s anything else we can do.

That’s the problem we’re trying to solve – what happens with all their old
tickets? We don’t want the notifications going to them (the blanked e-mail
address works for that, and also avoids some problems with just fully
disabling access to RT for that user), but re-assigning tickets is something
we’d like to avoid. It and the custom Scrip action are the best options so
far, just wondering if there’s anything else we can do.

I think a custom scrip-action to Notify the owner if they’re a
privileged user with an email address, otherwise flip the owner to
nobody and notify all adminccs is the “Right” answer.


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

Whip up a quick script to change all tickets owned by this particular user
to another owner, possibly an admin?From: Damian Gerow [mailto:damian@sentex.net]
Sent: Wednesday, January 07, 2004 2:54 PM
To: Jesse Vincent
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Re: Dealing with ex-employees

Thus spake Jesse Vincent (jesse@bestpractical.com) [07/01/04 14:48]:

What does this ‘special case’ do? Does the e-mail get rejected? Does
all
correspondance on the ticket go through the normal queue Scrips (i.e.
messages sent to AdminCc:'s and Cc:'s), or just sit there in the empty
ticket?

That RT user will no longer have an email address. If you’ve removed
them as a privileged user, they’ll won’t be able to log in, send mail
through RT or have RT send them mail. It doesn’t solve the problem of
local configuration not notifying anyone other than the owner of a
ticket.

That’s the problem we’re trying to solve – what happens with all their old
tickets? We don’t want the notifications going to them (the blanked e-mail
address works for that, and also avoids some problems with just fully
disabling access to RT for that user), but re-assigning tickets is something
we’d like to avoid. It and the custom Scrip action are the best options so
far, just wondering if there’s anything else we can do.
rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

When someone leaves, you could set their address to “”, and also do an
appropriate blanket “add admincc” on all their tickets. That way
someone will get notified and you still show the ticket owned by them.

Thus spake Mike Frazer (Michael.Frazer@InterCept.Net) [07/01/04 15:00]:

Whip up a quick script to change all tickets owned by this particular user
to another owner, possibly an admin?

That screws up statistics, and I’d rather not.

I think a custom scrip-action to Notify the owner if they’re a
privileged user with an email address, otherwise flip the owner to
nobody and notify all adminccs is the “Right” answer.

Seems to me that this might be the correct default behavior for a
notify owner scrip… at least it doesn’t violate POLA.

Vivek Khera, Ph.D.
+1-301-869-4449 x806

When someone leaves, you could set their address to “”, and also do an
appropriate blanket “add admincc” on all their tickets. That way
someone will get notified and you still show the ticket owned by them.

I don’t get it – wouldn’t you requeue all tickets to whoever takes on their
responsibilities? Given that old tickets can be reopened by mail, that
seems the only foolproof way to assure they get handled.

Thus spake Jesse Vincent (jesse@bestpractical.com) [07/01/04 14:58]:

That’s the problem we’re trying to solve – what happens with all their old
tickets? We don’t want the notifications going to them (the blanked e-mail
address works for that, and also avoids some problems with just fully
disabling access to RT for that user), but re-assigning tickets is something
we’d like to avoid. It and the custom Scrip action are the best options so
far, just wondering if there’s anything else we can do.

I think a custom scrip-action to Notify the owner if they’re a
privileged user with an email address, otherwise flip the owner to
nobody and notify all adminccs is the “Right” answer.

Okay, those were the two we were thinking of. We’ll figure out what to do
internally now. Thanks for the tip on the blank e-mail address!

Well then, how about setting up a mail alias to point to someone else’s
address, use that alias for the departed user’s address, and then you will
receive notification. Will that do any damage to statistics?From: Damian Gerow [mailto:damian@sentex.net]
Sent: Wednesday, January 07, 2004 3:05 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Re: Dealing with ex-employees

Thus spake Mike Frazer (Michael.Frazer@InterCept.Net) [07/01/04 15:00]:

Whip up a quick script to change all tickets owned by this particular user
to another owner, possibly an admin?

That screws up statistics, and I’d rather not.
rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Thus spake Roger B.A. Klorese (rogerk@queernet.org) [07/01/04 15:09]:

I don’t get it – wouldn’t you requeue all tickets to whoever takes on their
responsibilities? Given that old tickets can be reopened by mail, that
seems the only foolproof way to assure they get handled.

What if no one specific person takes on their responsibilities? We have a
team of about ten CSR’s here who answer the phone (we’re a small ISP) –
when a CSR leaves, we don’t hire another one on to fill his shoes, they’re
just another member of the team. All of them/us work together to resolve
all the tickets and answer all the calls, no one person is delegated a
specific subset of customers.

I think what we’ll wind up doing is a custom Scrip action. The reason
is…

Bob works here. Bob, over the course of his employment, takes and resolves
two thousand tickets. Bob leaves.

If we re-assign all of Bob’s tickets, that works. But then for every
employee who leaves (remember, CSR’s have an average turnaround of 6-8
months), we have to:

- change their e-mail address
- remove all rights
- possibly change their password
- search for and re-assign all their tickets

However, if we set up a custom Scrip action that makes sure the owner of the
ticket being corresponded on is allowed to be granted rights, then we don’t
need to re-assign anything, and we can look back and say, ‘Hey, Bob resolved
2000 tickets in two years, Sally resolved 1000 tickets in six months, and
Steve resolved sixty tickets in one month.’ Not sure what we’d do with
this information, but it’d still be there. :slight_smile:

(No, those numbers aren’t even close to accurate.)

So with the custom Scrip action, we just have to:

- change their e-mail address
- remove all rights
- possibly change their password

That saves a little bit o’ time, and is one less thing to forget.

From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
Of Damian Gerow
Sent: Wednesday, January 07, 2004 12:22 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Re: Dealing with ex-employees

What if no one specific person takes on their
responsibilities? We have a
team of about ten CSR’s here who answer the phone (we’re a
small ISP) –
when a CSR leaves, we don’t hire another one on to fill his
shoes, they’re
just another member of the team. All of them/us work
together to resolve
all the tickets and answer all the calls, no one person is delegated a
specific subset of customers.

Then the team does, and you have an alias that the whole team’s on. When a
ticket reawakens, everyone’s notified, and somebody steals it.