<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I agree completely.<br>
<br>
My group has been evaluating RT for 2 weeks now, and the only thing
we've found that will cause us implementation headaches is the rigid
definitions of the status field. I suspect that the status field is
this way, because alot of the logic flow of a ticket must be based on
the status. Is this assumption correct? If so, the solution is probably
not easy. However, one thing that comes to mind, is make status a user
defined field., like other useful user-defined fields such as
[priority, category, and as Ann has used, phases]. I haven't thought
this through, so right now I'm just brain storming with some of you
that have been using this for some time.... but I wonder how difficult
it would be to create a front-end to customizing scrips... for example:<br>
<br>
After the custom defined fields are added, then have a U/I under
configuration for scrips. And in there, link the logic flow between the
field that have been defined. Maybe this would unnecessarily complicate
the entire system. Maybe there is an easier path and I'm not familiar
enough with the system to see it. I don't want to get in the situation
where an upgrade breaks everything, or where we could not upgrade down
the road.<br>
<br>
Any thoughts? I guess at a minimum, I want a way to add or remove
statuses, and connect the logic flow to them.<br>
<br>
kdl<br>
<pre class="moz-signature" cols="72">K.D. Lucas
<a class="moz-txt-link-abbreviated" href="mailto:lucaskeli@fastmail.fm">lucaskeli@fastmail.fm</a></pre>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ann@drop.2organize.com">ann@drop.2organize.com</a> wrote:
<blockquote cite="midPine.LNX.4.58.0406221047550.642@drop.2organize.com"
type="cite">
<pre wrap="">Michael wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I know I've said this before, but if you feel a need to change the
statuses, I would strongly suggest reconsidering a more RT like way of
solving your work flow. There are no API guarantees for statuses which
means that your custom statuses can break at any point with an upgrade.
</pre>
</blockquote>
<pre wrap=""><!---->
I agree with Michael here, for what it's worth. We needed slightly
more fine-grained control, to indicate whether a ticket was waiting
for client input, in testing, ready to put live, etc--all of which
fall under the 'open' status.
I actually did go to the code and add the additional states, but
decided not to apply the patch to the live server because it looked
as if it had the potential to make upgrades painful.
In the end, our solution was to add a custom field, 'phase', which
holds the additional values. I then modified the template so that you
always see the phase in addition to the status, if it is present.
It actually turned out that this model more accurately represents
how we think about the tickets than additional status entries would,
because for status it is always a progression from new to resolved,
whereas the phase can bounce between different states.
Anyhow, this is just another suggestion on how the different states
could be handled.
- Ann
_______________________________________________
<a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a>
RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
<a class="moz-txt-link-freetext" href="http://bestpractical.com/services/training.html">http://bestpractical.com/services/training.html</a>
Sign up early, as class space is limited.
</pre>
</blockquote>
</body>
</html>