K.D. Lucas
>lucask
>eli at fastmail.fm
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
>+ dmd at spea
>keasy.org
>+ http://www.d
>mdennis.com
>+-------------------------
>
>On Tue, 22 Jun 2004, Michael S. Liebman wrote:
>
>  
Please don't send HTML only mails to the list.
>
>At 09:58 AM 6/22/2004, Kelly D. Lucas wrote:
>    
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?
>      
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.
>
>    
After the custom defined fields are added, then have a  U/I
> under
>configuration for scrips.
>      
You may want to have a look at Arturius's work flow based UI.
>
>    
Any thoughts? I guess at a minimum, I want a way to add or 
>remove
>statuses, and connect the logic flow to them.
>      
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                      ef="mailto:m-liebman at northwestern.edu">m-liebman at northwestern.edu
>                 http://msl521.freeshell.org/
>"I have vision and the rest of the world wears bifocals."
>        -Paul Newman in "Butch Cassidy & the Sundance Kid"
>
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/list
>info/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.
>
>    
_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/list
>info/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. 
>


tags, it ends up floating to the top of the table. When clicking on the link in the dates field it does not take you to last transaction, just takes you to the top of the table. I am assuming that this is not was intended, rather it should take you to the last transaction entered. I modified the line to $m->out('
#