FW: [Rt-users] Custom Statuses

[Kastl, Rebecca E.]

We have the same requirements here regarding custom statuses above and
beyond what is provided via default in RT.

First off, I agree completely with what Dave writes below.

Our requirements for statuses that aren't included as part of RT's
default status settings are:

Pending
Resolved: Awaiting Approval
Resolved: Closed

"Pendng" is necessary because selecting "Stalled" has the effect of
removing it from view. "Pending" is more in the mind of "awaiting user
input" or something similar. We also have need for "Stalled" because of
the numerous projects that get initiated and/or preempted by other RT
tickets.

The differing "Resolved" statuses would operate in a much different
manner thant the current "Resolved" status. When a ticket's status is
changed to "Resolved" and a user replies to the resolution notification
e-mail, the ticket gets placed back into an "Open" status. We would like
to see a "Resolved: Closed" status that wouldn't allow a user to re-open
an existing ticket, but instead open a new ticket.

A ticket in a "Resolved: Awaiting Approval" status not necessarily close
the ticket, but user input would not reopen it, either. Additionally,
the default notification for resolution would go out on both resolution
statuses.

--
Rebecca Kastl
Network Administrator
480-926-1887
Varsity Gold, Inc.
 
 

> -----Original Message-----
> From: Dave Dennis [mailto:dmd at speakeasy.org]
> Sent: Thursday, April 15, 2004 12:46 PM
> To: Tim Pierce
> Cc: Best Practical Users
> Subject: Re: [Rt-users] Custom Statuses
> 
> Yes, that is absolutely true.
> 
> I am simply pointing out that other products out there in this space 
> let you set conditions on resolving, and that is a pretty primary 
> workflow adjustment if the RT system is going to be able to 
> accommodate diverse installations, and that finally while custom mods 
> are certainly a wonderful thing, try making the case to someone who 
> has seen small company after small company go belly up in the Windows 
> space particularly ... and that leaves us with an orphan product, 
> custom mods or not.  I am trying to make the case for wider 
> functionality over custom mods, because as one who has worked for 
> small software houses before, custom mods have a way of turning out to

> be alot of work later on, like when upgrades come, and even the best 
> CRM between Best Practical and customers with mods still runs the risk

> of a custom install requiring hand-holding every single time an 
> upgrade is released later on.  Then one gets into the adversarial 
> relationship of custom site and company, what is covered by the 
> contract and what is not, endless bickering over whether a mod was the

> fault of the next problem, on and on.
> 
> Better (in my view) to have basic functionality be a part of the 
> product, and in my opinion again, configurable end-game condition 
> names is not a custom mod, its a base functionality.
> 
> Your business model is your business, and more power to you.
> 
> Kind regards,
> 
> 
> +-------------------------
> + Dave Dennis
> + Seattle, WA
> + dmd at speakeasy.org
> + http://www.dmdennis.com
> +-------------------------
> 
> On Thu, 15 Apr 2004, Tim Pierce wrote:
> 
> > On Thu, Apr 15, 2004 at 09:49:37AM -0700, Dave Dennis wrote:
> > >
> > > Nor is it really a solution to say "if we buy support I
> believe the
> > > company would be quite amenable to adding this."  CTO's recoil in 
> > > fear at the thought of a development cycle just to
> implement a product. Rightly so.
> >
> > At the same time, it really isn't feasible for a small company to 
> > spend a lot of staff time on fixing a problem that hasn't been 
> > requested by any paying customers yet.  You could, after
> all, say that
> > you'd purchase an RT license if it had feature X, and then
> change your
> > mind and go buy something else while it was being
> implemented, leaving
> > Best Practical stuck with the development cost.
> >
> > The model of "if you're a paying customer then come talk to us; if 
> > you're a freeloader then we might get around to it someday" is 
> > becoming more and more common.  I think that CTOs are going
> to have to get used to it.
> >
> > --twp
> >
> >
> _______________________________________________
> RT-Users mailing list
> RT-Users at lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
>