One more patch for custom statuses follows.
Sergey.
diff -u --recursive -ba Update.html new/Update.html >Update.html.patch
— Update.html Fri Apr 05 19:24:57 2002
+++ new/Update.html Fri Apr 16 15:22:44 2004
@@ -58,7 +58,12 @@
<& /Elements/MessageBox, Name=>“UpdateContent”,
QuoteTransaction=>$ARGS{QuoteTransaction} &>
+% if ($DefaultStatus eq ‘resolved’) {
+
+<& /Elements/TitleBoxStart, title => ‘Select Keywords’, width=>‘50%’,
color =>"#993333"&>
+<& Elements/EditKeywordSelects, TicketObj=>$Ticket &>
+<& /Elements/TitleBoxEnd &>
+% }
<& /Elements/TitleBoxEnd &>
As stated previously, custom fields are absent from Update.html (when resolving
ticket).
If I go to resolve a ticket, there is no place to change the custom status I
created.
So that prevents a custom field from being of use as an extension to
a ‘resolved’ status, because it cannot be touched from the screen
where the user resolves the ticket.
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.
Thanks for your prompt response,
Kind regards,
±------------------------
On Thu, 15 Apr 2004, Jesse Vincent wrote:
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
RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives
RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives
–
RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives
RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives
Is adding custom statuses like this really work this easily? Has anyone
had any trouble with this procedure?
http://wiki.bestpractical.com/index.cgi?CustomStatuses
Brad Pinkston
Senior Systems Administrator
New Media Gateway
O: 214.206.3485
M: 469.682.6487
F: 303.496.2712
I noticed that the link you reference says you can’t have a status
longer than 10 characters. Does anyone know why this is? That explains
why I got the error it describes for a status of “resolved_notdone”. I
thought it may have been the underscore, but I never looked into it.From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Brad
Pinkston
Sent: Wednesday, April 12, 2006 10:25 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Custom Statuses
Is adding custom statuses like this really work this easily?
Has anyone had any trouble with this procedure?
http://wiki.bestpractical.com/index.cgi?CustomStatuses
Brad Pinkston
Senior Systems Administrator
New Media Gateway
O: 214.206.3485
M: 469.682.6487
F: 303.496.2712
I noticed that the link you reference says you can’t have a status
longer than 10 characters. Does anyone know why this is? That explains
why I got the error it describes for a status of “resolved_notdone”. I
thought it may have been the underscore, but I never looked into it.
Because the field in the database is defined as ‘Status VARCHAR(10)’.
Which means that the database will not accept a value of Status longer
than 10 characters.
HTH
Joshua Colson
-----Original Message-----
From: Joshua Colson [mailto:jcolson@realm.ination.cc]
Sent: Wednesday, April 12, 2006 11:33 AM
To: rt-users@lists.bestpractical.com
Cc: Schultz, Eric
Subject: RE: [rt-users] Custom Statuses
I noticed that the link you reference says you can’t have a status
longer than 10 characters. Does anyone know why this is?
That explains
why I got the error it describes for a status of
“resolved_notdone”. I
thought it may have been the underscore, but I never looked into it.
Because the field in the database is defined as ‘Status VARCHAR(10)’.
Which means that the database will not accept a value of Status longer
than 10 characters.
HTH
Joshua Colson
Oh, DUH Guess I could have checked this myself. In that case,
issue this command to increase the upper limit on Status in MySQL:
ALTER TABLE Tickets CHANGE Status Status varchar(32);
Yes, “Status” should be there twice. I chose 32 because I like powers
of 2 in my schema Of course, the smarter thing would be to make all
the columns char rather than varchar so you don’t have to worry about
irregular length records, and don’t make the fixed-length field much
larger than you need. If you can get by with 16 or 24 above, then do
it. Once they are all fixed length, you get speedier queries. Other
changes I would make include making Disabled and all of the Priority
columns a tinyint (this puts a hard limit of 255 for the largest value,
and uses half as much storage), and using timestamp rather than datetime
for the date fields (since we don’t extract the time separately and the
former uses half the storage). When you get into the realm of 100,000
tickets, you can save a few megabytes in doing this.
So is this a yes? Is everything working 100% with this setup? Does the
HTML automatically give you the new statuses as the option, or is that
hardcoded?
Brad Pinkston
Senior Systems Administrator
New Media Gateway
O: 214.206.3485
M: 469.682.6487
F: 303.496.2712-----Original Message-----
From: Schultz, Eric [mailto:ESchultz@corp.untd.com]
Sent: Wednesday, April 12, 2006 1:17 PM
To: Brad Pinkston; rt-users@lists.bestpractical.com
Subject: RE: [rt-users] Custom Statuses
I noticed that the link you reference says you can’t have a status
longer than 10 characters. Does anyone know why this is? That explains
why I got the error it describes for a status of “resolved_notdone”. I
thought it may have been the underscore, but I never looked into it.
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Brad
Pinkston
Sent: Wednesday, April 12, 2006 10:25 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Custom Statuses
Is adding custom statuses like this really work this easily?
Has anyone had any trouble with this procedure?
http://wiki.bestpractical.com/index.cgi?CustomStatuses
Brad Pinkston
Senior Systems Administrator
New Media Gateway
O: 214.206.3485
M: 469.682.6487
F: 303.496.2712
Yes, it should all work automatically. You don’t have a dev/test
instance to test this on?
Eric Schultz
United Online