[rt-users] Adding more status types
Bob Goldstein
bobg at uic.edu
Wed Jun 23 12:05:13 EDT 2004
I'm far from an RT expert, but I've certainly poked through
some of the code. My guess is that as long as the status-changing
workflow is controlled by code, then removing status types
is very risky, and adding them is possible but could involve
a fair amount of work. (Risky == _lots_ of work to adapt to
new releases.)
You could, however, "remove" some of the offending status
values by not displaying them in parts of the gui. That
ought to be fairly safe.
I don't know what Jesse's plans are, but 3.2.0rc1 clearly shows
he is adding flexibility. If more of the internal workflow
were to be put under control of scrips, there might come a time
when changing existing status values (and associated workflow)
would be safe, and maybe even gui-controlled to some extent.
I have to ask about your use of "mainstream". My guess is that
no matter what RT is or becomes, there will always be mainstream uses
where it is almost good enough. Bug reporting, inventory control,
calendar/to-do lists, archiving of work done, planning of workflow
for large projects, integration with other databases, generalized
document workflow, etc. Good as it is, it can't become everything :-)
bobg
>--===============1658785507==
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
><!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">
>Agreed. <br>
><br>
>Thanks for detailing the needs of many of us. I think if RT is to be an
>easy to use product for main stream, it needs to address this workflow
>issue.<br>
><br>
>I don't think that the 6 provided status types will ever fit each
>organization, and it needs to be customized for each organization.<br>
><br>
>Has anyone scoped out how much work this would require? What I'm asking
>for is the ability to add and remove status types that affect workflow.
>Or, as Dave just pointed out, put the custom fields on the resolve
>screens. Maybe this is more of a U/I issue than a workflow issue.....<br>
><br>
>Any other thoughts on it?<br>
><br>
>kdl<br>
><pre class="moz-signature" cols="72">K.D. Lucas
><a class="moz-txt-link-abbreviated" href="mailto:lucaskeli at fastmail.fm">lucask
>eli at fastmail.fm</a></pre>
><br>
><br>
>Dave Dennis wrote:
><blockquote
> cite="midPine.LNX.4.58.0406230811220.27144 at shell1.speakeasy.net"
> type="cite">
> <pre wrap="">Actually, not in our case. We've had several workflow discussi
>ons in house
>about this. What happens is a ticket can be stalled, but for what reason, and
>custom fields arent available at resolve time, so that workflow is convoluted.
>If we did it by custom statuses and expanded 'stalled' to mean stalled at the
>vendors end or stalled inhouse, or even more granular stalled in house because
>of shipping, or because of backorder, or what have you ... we'd have a way to
>split tickets out that exceeded our SLA, and be able to better explain why to
>senior mgt, other than just saying they're 'stalled.' We tried custom fields
>for this and that works fine, except for the huge gotcha that the resolve
>screens (Listing.html or Update.html) don't show custom fields!!!! So what goo
>d
>would be a custom field showing a resolve code if you cannot see it without
>chunking over to "Basics," updating that, then sauntering back to Update.html
>and resolving. Its a workflow headache I can't unleash on a busy staff, sound
>s
>like triviality there I am sure, but turning a 1-click resolve into a 3-4 clic
>k
>resolve detour is just not acceptable, the custom fields needs to be on the
>ticket resolve screens, imho.
>
>
>Kind regards,
>
>Dave D
>
>+-------------------------
>+ Dave Dennis
>+ Seattle, WA
>+ <a class="moz-txt-link-abbreviated" href="mailto:dmd at speakeasy.org">dmd at spea
>keasy.org</a>
>+ <a class="moz-txt-link-freetext" href="http://www.dmdennis.com">http://www.d
>mdennis.com</a>
>+-------------------------
>
>On Tue, 22 Jun 2004, Michael S. Liebman wrote:
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">Please don't send HTML only mails to the list.
>
>At 09:58 AM 6/22/2004, Kelly D. Lucas wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">My group has been evaluating RT for 2 weeks now, and the on
>ly 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?
> </pre>
> </blockquote>
> <pre wrap="">Pretty much. If you take a step back from the process you are
> working on,
>you will probably find the "status" of the process will fit into one of the
>broad categories of the ticket status.
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">After the custom defined fields are added, then have a U/I
> under
>configuration for scrips.
> </pre>
> </blockquote>
> <pre wrap="">You may want to have a look at Arturius's work flow based UI.
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">Any thoughts? I guess at a minimum, I want a way to add or
>remove
>statuses, and connect the logic flow to them.
> </pre>
> </blockquote>
> <pre wrap="">I would recommend leaving the statuses the way they are and a
>dd a custom
>field for the specifics you want. For example, if you are trying to use RT
>for a provisioning work flow, you would create the ticket with the "new"
>status. This might be the first contact with the customer with regard to
>the service you are going to provision for them. The status would change to
>"open" when sales started working out the details. Your custom field would
>be set to "sales." Once things get worked out from there, the custom field
>would get set to "field operations" so the could actually go out and do the
>work. But the ticket status stays at "open." Once the service is
>provisioned, you would set the custom field to "billing" and again leave
>the status as "open."
>
>It's not until billing sends out the invoice that you set the status to
>"stalled" to indicate you are waiting for a response from the customer.
>Your custom field is still set to "billing." That way you know that after x
>amount of time, billing needs to follow up to find out where their payment
>is. Additionally, you could set the status to "stalled" anywhere else in
>your work flow, say when your custom field is "sales," to indicate you are
>waiting on the customer. But this time you know it is sales that has to do
>the follow up. It shouldn't be too difficult to get scrip with custom
>conditions and actions and the cron tool to do what you need to based on
>the relation between the ticket status and your custom field.
>
>Hope that helps.
>
>Michael
>
>--
>Michael S. Liebman <a class="moz-txt-link-abbreviated" hr
>ef="mailto:m-liebman at northwestern.edu">m-liebman at northwestern.edu</a>
> <a class="moz-txt-link-freetext" href="http://msl521.freeshel
>l.org/">http://msl521.freeshell.org/</a>
>"I have vision and the rest of the world wears bifocals."
> -Paul Newman in "Butch Cassidy & the Sundance Kid"
>
>_______________________________________________
><a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/
>mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/list
>info/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/train
>ing.html">http://bestpractical.com/services/training.html</a>
>
>Sign up early, as class space is limited.
>
> </pre>
> </blockquote>
> <pre wrap=""><!---->_______________________________________________
><a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/
>mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/list
>info/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/train
>ing.html">http://bestpractical.com/services/training.html</a>
>
>Sign up early, as class space is limited.
> </pre>
></blockquote>
>
>!DSPAM:40d9a4c9161971405512111!
>
></body>
></html>
>
>--===============1658785507==
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>RT Developer and Administrator training is coming to LA, DC and Frankfurt this
> spring and summer.
>http://bestpractical.com/services/training.html
>
>Sign up early, as class space is limited.
>
>
>!DSPAM:40d9a4c9161971405512111!
>
>--===============1658785507==--
>
>
>
More information about the rt-users
mailing list