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.
I would imagine then that many of these companies will not succeed since
CTO’s aren’t usually up for being painted in a corner. That method also
seems quite contradictory to the spirit of freeware / open source. That’s
just me.
Travis-----Original Message-----
From: Tim Pierce [mailto:twp@gamelogic.com]
Sent: Thursday, April 15, 2004 12:07 PM
To: Dave Dennis
Cc: Best Practical Users
Subject: Re: [Rt-users] Custom Statuses
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.
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.
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.
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.
Perhaps for you, but I’ve used RT for two years and have no idea what a
“configurable end-game condition name” is… can you explain this?
Configurable end-game just means, instead of locked into
“new/open/stalled/resolved/dead/deleted”
you get to put things like
“sold” or “sent brochure” or “check cleared” or whatever
as either subsets of or replacements for the ubiquitous
and not-detailed-enough “resolved” as a ticket end-condition.
Leaving tickets open / shuffling queues around is OK, but
launches into other issues, like queue growth or constantly
needing to mod one’s searches in order to screen out the
“resolved this way” versus “resolved that way” scenarios.
Am I barking uselessly with a bad workflow model or does
that help explain and there’s merit? I’ve looked at how
we use RT and have made some adjustments, but this one
just doesn’t seem to have a good solution. Custom fields
don’t show up on the resolve-ticket screens, and therein
lies a lot of the problem.
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.
Perhaps for you, but I’ve used RT for two years and have no idea what a
“configurable end-game condition name” is… can you explain this?
Configurable end-game just means, instead of locked into
“new/open/stalled/resolved/dead/deleted”
you get to put things like
“sold” or “sent brochure” or “check cleared” or whatever
as either subsets of or replacements for the ubiquitous
and not-detailed-enough “resolved” as a ticket end-condition.
Those don’t seem like trouble-ticket issues to me.
We have the same issue, support wants “pendingCustomer”,
“pendingQAVerification”, “pendingRelease”, etc (maybe not those names,
but those semantics). Yes, I can do that with different queues, but
then (for instance), I can’t dedicate a queue to a large customer.
Those are just some simple examples, it goes deeper than that.
Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc
952.345.8677 kfh@mqsoftware.com
The organization I work for make immediate use of the ability to configure
different types of resolved tickets. Instead we make due with slinging
things around in queues.
Now, to the point you eloquently raise:
I thought RT stood for REQUEST, not “trouble ticket.”
From Request Tracker site:
"RT manages key tasks such as the identification, prioritization, assignment,
resolution and notification required by enterprise-critical applications
including project management, help desk, NOC ticketing, CRM and software
development. "
CRM means “Customer Relationship Management,” which to my mind expands
beyond the simplistic adherence to the term you cite, “trouble ticket.”
This is the last mail I’ll post on the subject, don’t worry.
Configurable end-game just means, instead of locked into
“new/open/stalled/resolved/dead/deleted”
you get to put things like
“sold” or “sent brochure” or “check cleared” or whatever
as either subsets of or replacements for the ubiquitous
and not-detailed-enough “resolved” as a ticket end-condition.
Those don’t seem like trouble-ticket issues to me.
There’s a pair of arrays in RT/Queue_Overlay.pm that define the
statuses
supported by RT. The default scrips and user interface do assume that
you haven’t removed any of the shipping statuses.
Jesse, Do I understand you to be saying that I should be able to ADD
status values to the pair of arrays mentioned above (as long as I don’t
change the existing ones, or their relative position), and things should
“work”??? That would be “huge”…
Yes, you could do exactly that, if you choose to go that route.
You can create yourself a Queue_Local.pm file, and you can override
those arrays, like this:
I’ll just point out again, other people have this issue, and this is
certainly not the first time it’s been brought up.
I dimly remember Jesse saying that he knew about this, although it
wasn’t a simple thing to change, he sort of thought it might arrive in
some future version.
Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc
952.345.8677 kfh@mqsoftware.com
There’s a pair of arrays in RT/Queue_Overlay.pm that define the
statuses
supported by RT. The default scrips and user interface do assume
that
you haven’t removed any of the shipping statuses.
Jesse, Do I understand you to be saying that I should be able to
ADD
status values to the pair of arrays mentioned above (as long as I
don’t
Isn’t that an oxymoron? If it’s escalated, it’s not yer resolved…
I thought RT stood for REQUEST, not “trouble ticket.”
True. I’ve always thought its goals as a CRM solution were somewhat
overblown – that is, it handles a particular type of customer
relaitonship well, and others less so.
Now if the web interface would only be extended to allow those to be
filled into a box and have the file auto-generated, I believe the whole
issue would be addressed.
I would imagine then that many of these companies will not succeed since
CTO’s aren’t usually up for being painted in a corner. That method also
seems quite contradictory to the spirit of freeware / open source. That’s
just me.
Only time will tell. But I think we should all agree that at best it’s
a Mexican standoff. In one corner you have the CTO who balks at
purchasing a support contract with the promise that the desired feature
will be included in the next release. In the other corner is the CTO
who balks at implementing a feature based on the promise that someone
will buy a contract for it. Neither CTO wants to go out on a limb,
quite reasonably IMHO.
In general, features get implemented when companies see that it’s causing
a significant number of potential customers to choose another product.
That appears to be what’s happening here. It’s not specific to
open-source software and I don’t see any reason to believe that the
system is broken. I fully expect that if Best Practical sees reason to
believe that more than a handful of cranky might-be customers are
choosing which software to install based on this issue, it will become a
priority.
Only time will tell. But I think we should all agree that at best it’s
a Mexican standoff. In one corner you have the CTO who balks at
purchasing a support contract with the promise that the desired feature
will be included in the next release.
I’m not sure what support contracts have to do with anything
here. “Customer” in the context of customising RT generally
refers to a customer who underwrites the development of a
given feature, on a project basis. This is independent from
having an ongoing support contract.
I think it’s already been established that if such a customer
were to come forward, the feature could be implemented… however
in absence of such a customer, it’s not likely to be done at
the detriment of work that people are paying for (as you
already noted, Tim.)
Of course, if someone who actually wanted this were to sit
down and implement it and submit the patches, there’s a very
good chance they’d be considered for inclusion…
The custom fields can be edited after the ticket is created in the “Basics”
or “Jumbo” views.On Thu, 15 Apr 2004, Dave Dennis wrote:
Jesse,
I did create custom fields, but was unable to get those to appear
in any drop-down other than in the ticket creation window.
So custom fields are great, but here’s what I ended up with:
Enabled Custom Fields
Resolved Status
Flags to indicate final status Select multiple values
If thats not clear it is saying I created a custom field
called “Resolved Status” of “select multiple values” type.
Then when I create the ticket in this queue, yep, there they are.
But when I go to resolve – oops – no custom values.
So it looks a little strange, and this was probably my fault,
by naming my Custom Field “Resolved Status” it sets up the
expectation that it would be modifyable on the resolve ticket
screens. But I did, and it isn’t.
It would be possible to use my flags, if we alter the workflow
and say “when resolving a ticket, visit two pages – the
Custom Fields screen to set the resolved flag, and the
resolved screen, to actually resolve the ticket.” But that
is unacceptable, as we like to rip-n-read these tickets,
adding 5 clicks and a new screen’s worth of work was deemed
“too much hassle” and discarded as a solution. Seems odd,
I am sure, but having a ‘1 click’ resolve is important when
you’re slinging tickets all day.
On Thu, Apr 15, 2004 at 08:10:58AM -0700, Niedens, Travis wrote:
I guess my question would be then, why has it been chosen to be
unchangeable? Is this so hard to change that it would cause a full re-write
of RT? I would certainly hope that it was designed to eventually have all
fields customizable. In most environments the standard ticket statuses are
just a small set of what can be. I know I have been asked by my HelpDesk to
add 2 more ticket statuses.
There’s a pair of arrays in RT/Queue_Overlay.pm that define the statuses
supported by RT. The default scrips and user interface do assume that
you haven’t removed any of the shipping statuses.
But really, we recommend you create a custom field for your local status
needs. It’s much more flexible and means you never have to touch RT’s
source code.
Travis Niedens
Network Manager
University of Redlands
-----Original Message-----
From: Derek J. Balling [mailto:dredd@megacity.org]
Sent: Thursday, April 15, 2004 4:20 AM
To: Dave Dennis
Cc: Best Practical Users
Subject: Re: [Rt-users] Custom Statuses
“sold” or “sent brochure” or “check cleared” or whatever
as either subsets of or replacements for the ubiquitous
and not-detailed-enough “resolved” as a ticket end-condition.
That screams custom field to me. You need to separate the workflow status
(new, open, closed, etc.) from the business status (sold, returned,
exchanged, etc.). Most ticketing systems tend to use an exclusive selection
field (radio buttons) for the status and provide a text field for the
resolution. RT choses to provide that text field as yet another
correspondence transaction. That’s not to say you can’t provide your own
resolution field in a custom field of your choosing.
Am I barking uselessly with a bad workflow model or does
that help explain and there’s merit?
I think your on the right track but just need to adapt a little to how RT
works. To that end, I’m working on a patch to ticket/Update.html that will
display a custom field when the DefaultStatus is resolved. I think that
will go a long way to helping you based on your earlier messages.
Michael
Michael S. Liebman m-liebman@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”
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
Hi. Just my two cents.
We implemented just that feature (changing custom fields at update on
the same page) in our RT 2.0.15 installation about year ago. It took no
more than 4 hours to get things work. I think you’ve spent much more
time discussing this point
