Missing Status for Tickets that cannot be resolved

which status should I asign to tickets
that cannot be resolved. “Dead” seems
to be reserved for garbage tickets which
are ment to be deleted from the data base.

Thanks

which status should I asign to tickets
that cannot be resolved. “Dead” seems
to be reserved for garbage tickets which
are ment to be deleted from the data base.

Our installation has a keyword “Reason for closure” which contains such
options as “done”, “no longer required”, “somebody else’s problem”,
“can’t reproduce”, “insufficient resources”, etc.

K.

The keyword is much different than the status. We have the same concern
as Ruben with our installation. We have the similiar keywords at Kirrily.

A status that doesn’t display the tickets but allows searches to be
performed on them.

Kirrily Robert wrote:> On Tue, Oct 08, 2002 at 05:52:57PM +0200, Ruben Schattevoy wrote:

which status should I asign to tickets
that cannot be resolved. “Dead” seems
to be reserved for garbage tickets which
are ment to be deleted from the data base.

Our installation has a keyword “Reason for closure” which contains such
options as “done”, “no longer required”, “somebody else’s problem”,
“can’t reproduce”, “insufficient resources”, etc.

K.


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

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

mhershey.vcf (237 Bytes)

Michele Hershey writes:

The keyword is [very] different [from] the status. We have the same
concern as Ruben with our installation. We have … similar keywords
a[s] Kirrily.
A status that doesn’t display the tickets but allows searches to be
performed on them.

The “stalled” status generally doesn’t display (unless you explicitly
add it to your search). This is also true of “resolved”. And of course
it is possible to search on keywords.

Perhaps you need to explain in more detail why using keywords to
indicate whether a fix was found, or it was just decided that it wasn’t
worth the effort, or somebody else’s bug, etc. isn’t good enough?

In our case, we are also using keywords to indicate that problems aren’t
fixed (even when the ticket is resolved), and I think the only quibble I
have with this solution is that RT can’t require a keyword (or use a
default value) in the way it does for status. And perhaps, the ability
to associate different default/allowed values of a keyword with each
different status.

@alex
mailto:dupuy@sysd.com

Alexander Dupuy wrote:

Michele Hershey writes:

The keyword is [very] different [from] the status. We have the same
concern as Ruben with our installation. We have … similar keywords
a[s] Kirrily.
A status that doesn’t display the tickets but allows searches to be
performed on them.

In our case, we are also using keywords to indicate that problems aren’t
fixed (even when the ticket is resolved), and I think the only quibble I
have with this solution is that RT can’t require a keyword (or use a
default value) in the way it does for status. And perhaps, the ability
to associate different default/allowed values of a keyword with each
different status.

I understand that your solution works perfectly. Nevertheless I
have problems in asigning the attribuite “resolved” to a ticket
which is actually “dead” because it’s somebody else’s problem
and still not resolved. I would prefere a solution with one
more status, say, “garbage”. Then I could assign status "garbage"
to tickets which where entered accidentally and assign "dead"
to thouse which can’t be fixed by us. Having an extra keyword
indicating the reason for this ticket ending in status "dead"
whould be nice, either!

Ruben

Ruben Schattevoy writes:

I understand that your solution works perfectly. Nevertheless I
have problems in assigning the attribute “resolved” to a ticket
which is actually “dead” because it’s somebody else’s problem
and still not resolved. I would prefer a solution with one
more status, say, “garbage”. Then I could assign status "garbage"
to tickets which where entered accidentally and assign "dead"
to thouse which can’t be fixed by us. Having an extra keyword
indicating the reason for this ticket ending in status "dead"
whould be nice, either!

These kinds of problems are one of the best reasons for
internationalizing software, even if it is never localized into any
language other than English.

It seems to me that replacing the string “resolved” in the Web and
e-mail interfaces with “closed” would eliminate most of your objection;
the only quibble would be that you would have to look at the keywords to
determine if a closed ticket was closed because the problem was
resolved, or because it couldn’t be fixed by you.

If RT were internationalized, you could probably do this yourself.
Heck, you could localize it into German, and then you would see
"beendet" or something like that.

@alex
mailto:dupuy@sysd.com

I understand that your solution works perfectly. Nevertheless I
have problems in asigning the attribuite “resolved” to a ticket
which is actually “dead” because it’s somebody else’s problem
and still not resolved. I would prefere a solution with one
more status, say, “garbage”. Then I could assign status "garbage"
to tickets which where entered accidentally and assign "dead"
to thouse which can’t be fixed by us. Having an extra keyword
indicating the reason for this ticket ending in status "dead"
whould be nice, either!

I don’t see it as “dead” if it is a problem that someone has brought to
me to take care of. I mean, if my customer has come to me to fix it,
and it is on a third party’s plate, I still want the ticket to be open,
but “waiting on somebody else”. That way, when they get to it, and fix
their problem, I can move it out of “waiting on somebody else” and back
to “waiting on me”.

At one point, ciscoSystems TAC had the idea of “CE-pending”,
“DE-pending”, “Cust-pending”, which were all valid states for an Open
ticket. As a CE, we didn’t get it counted against us as much for
Cust-pending tickets as much as for CE-pending. Of course, grouping by
each option was done as needed, so that we knew if we needed to ping the
customer, ping the developer, or get something done ourselves.

Maybe another queue is in order, to hold all of these things which other
people need to get done for you?

rob

I understand that your solution works perfectly. Nevertheless I
have problems in asigning the attribuite “resolved” to a ticket
which is actually “dead” because it’s somebody else’s problem
and still not resolved.

Then you’ll have to write a patch that does that, because that’s Not
How It Works.

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html
rich@lafferty.ca -----------±----------------------------------------------