[rt-users] Adding more status types

[Ruslan U. Zakirov]

Dave Dennis wrote:
> Actually, not in our case.  We've had several workflow discussions 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.
We've solve this problem with patch to RT WebUI which allow set CFs on 
update page. Jesse said that this aproach has some hidden problems, but 
we still use it :) because we need it.

Jesse, could you please comment on patch, what problem could happen with it?

> 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 good
> would be a custom field showing a resolve code if you cannot see it without
This also solvable and folks here sent patches that add CF values in 
ticket listings.

> 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, sounds
> like triviality there I am sure, but turning a 1-click resolve into a 3-4 click
> resolve detour is just not acceptable, the custom fields needs to be on the
> ticket resolve screens, imho.
> 
> 
> Kind regards,
> 
> Dave D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rt3.custom_fields_on_reply.patch
Type: application/aegis-patch
Size: 1338 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20040623/df09e155/attachment.bin>