Dealing with ex-employees

RT Users
21

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

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.

The team is comprised of individuals. The individuals deal with the
individual tickets, not the team. The team works /together/ to resolve all
the tickets.

When Marsha is hired because Matthew left, we don’t want to give Marsha all
of Steve’s tickets – there might be a valid reason for keeping Steve as the
owner.

22

The team is comprised of individuals. The individuals deal with the
individual tickets, not the team. The team works /together/
to resolve all
the tickets.

Yes…

When Marsha is hired because Matthew left, we don’t want to
give Marsha all
of Steve’s tickets – there might be a valid reason for
keeping Steve as the
owner.

Why would you want to keep Matthew as the owner?!

Wouldn’t you want to make the team the collective owner, until someone
actually has to work on it? And make the person actually working on it the
owner?

23

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

When Marsha is hired because Matthew left, we don’t want to
give Marsha all
of Steve’s tickets – there might be a valid reason for
keeping Steve as the
owner.

Why would you want to keep Matthew as the owner?!

Why wouldn’t I?

Wouldn’t you want to make the team the collective owner, until someone
actually has to work on it? And make the person actually working on it the
owner?

Why would I want to shift all the tickets so the team is the collective
owner? Our workflow dictates that this is much more complicated than just
having individual owners, who take the ticket from ‘Nobody’ (or have it
assigned to them). I gain nothing by re-assigning all of Matthew’s tickets
to someone(s) else, but lose the time it takes to update all these tickets.
I also lose the ability to look at past performance of CSR’s, to look at
current performance, and to be able to find past tickets easier (customer
says he was talking to Matthew six months ago, doesn’t remember what e-mail
address he used – try finding that ticket, if all of Matt’s tickets have
been re-assigned).

24

Why would I want to shift all the tickets so the team is
the collective
owner?

For the closed tickets, in case they reopen? Why would you want to have a
terminated employee associated with anything?

Our workflow dictates that this is much more
complicated than just
having individual owners, who take the ticket from ‘Nobody’
(or have it
assigned to them).

“Nobody” is just an uglier name for “the team.”

25

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

For the closed tickets, in case they reopen? Why would you want to have a
terminated employee associated with anything?

The whole point was that any re-opening of about 99% of these closed
tickets, /should not happen/.

“Nobody” is just an uglier name for “the team.”

“Nobody”, for us, actually means “Nobody”. “The team” only includes about
40% of our company. We have other queues that handle other types of work,
that don’t involve our CSR’s.

This is actually pretty pointless. This might be the best idea for you and
a number of other RT users, but it’s not for us, simply because of the way
our company and RT installation works.

26

Not sure if you got the answer you were looking for but perhaps this would
work…

It’s a lot simpler than changing your processes

Script 1: Create a script that sends a reply if the ticket is already closed
Custom condition:
return 1 if ($self->TicketObj->Status=~/Closed/);

And a template that tells them that the ticket is closed and they must
submit a new one.

In the OnCorrespond scrip:
Change the condition to “User Defined” and use:
if ($self->TransactionObj->Type=~/Correspond/) {
if (!$self->TicketObj->Status=~/Closed/) {
return 1;
}
}

The first one will only process the template if the ticket is closed.

The second one replaces the existing OnCorrespond condition with one that
will only process the ticket if it is not closed. If it is closed, the
OnCorrespond script simply won’t be executed.

Hope this helps
A.J. Fasano
Network Solutions IncFrom: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Roger B.A.
Klorese
Sent: Wednesday, January 07, 2004 5:58 PM
To: ‘Damian Gerow’; rt-users@lists.bestpractical.com
Subject: RE: [rt-users] Re: Dealing with ex-employees

Why would I want to shift all the tickets so the team is
the collective
owner?

For the closed tickets, in case they reopen? Why would you want to have a
terminated employee associated with anything?

Our workflow dictates that this is much more
complicated than just
having individual owners, who take the ticket from ‘Nobody’
(or have it
assigned to them).

“Nobody” is just an uglier name for “the team.”

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

27

Thus spake AJ (rt@musefoundry.com) [08/01/04 14:24]:

Not sure if you got the answer you were looking for but perhaps this would
work…

It’s a lot simpler than changing your processes

Script 1: Create a script that sends a reply if the ticket is already closed
Custom condition:
return 1 if ($self->TicketObj->Status=~/Closed/);

Sometimes, there are valid reasons for re-opening a Resolved ticket, so this
won’t work.

28

I you require some kind of management approval prior to re-opening an issue:

Ax the global OnCorrespond and create two scrips:

One:
if ($self->TransactionObj->Type=~/Correspond/) {
if (!$self->TicketObj->Status=~/Closed/) {
return 1;
}
}
And the usual correspondence

And the other:
if ($self->TransactionObj->Type=~/Correspond/) {
if ($self->TicketObj->Status=~/Closed/) {
return 1;
}
}
Notify Requestors, CCs, and Admin CCs with a template that says this issue
is closed, if this is a new issue please open a new ticket.

Then even if the original CSR is no longer with the company, at least
management will be notified of a request to re-open.

The other way you could do it would require making the ex-employee
unprivileged and then just leave the correspond the way it is and add
another one (this is off the cuff and the actual instantiation of the
objects is a bit iffy but you’ll get the idea):
if ($self->TransactionObj->Type=~/Correspond/) {
if (!$self->TicketObj->Owner->HasRight(‘Object’ => $self->TicketObj,
‘Right’ => ‘ModifyTicket’)) {
return 1;
}

The Action to notify cc or admincc or both with a template that says that
the owner of the ticket does not have any privs.

The second way would actually handle ex-employees whether the ticket is
closed or not.From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Damian Gerow
Sent: Thursday, January 08, 2004 2:32 PM
To: rt-users@lists.fsck.com
Subject: Re: [rt-users] Re: Dealing with ex-employees

Thus spake AJ (rt@musefoundry.com) [08/01/04 14:24]:

Not sure if you got the answer you were looking for but perhaps this would
work…

It’s a lot simpler than changing your processes

Script 1: Create a script that sends a reply if the ticket is already
closed
Custom condition:
return 1 if ($self->TicketObj->Status=~/Closed/);

Sometimes, there are valid reasons for re-opening a Resolved ticket, so this
won’t work.
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