Custom statuses

OK, I’ve read the discussion about custom statuses before, and tried to use them, and have concluded that they are, indeed, not a good idea with the current RT implementation.

What I’d like to do is to explore how hard/reasonable it would be to support them. I know there’s a lot of theological inertia against doing so, but from what I see, there’s also a lot of interest. So to me it’s worth at least considering.

The product already sort of supports custom statuses, via the @ActiveStatus and @InactiveStatus records in the config file. The problem in using them (at least, the problem WE hit; there may be more!) is that tickets in custom statuses don’t show up on the RT homepage lists, so they get “lost” easily.

My thinking is that if the default queries for the “highest priority” (and under “Queue” in “Quick Search”, and, I suppose, “unowned”) tickets on the homepage were to be “find tickets NOT in any of the @InactiveStatus statuses” rather than “Find tickets in new/open/stalled”, then using custom statuses would mostly work.

Also, I notice that in 3.6.0pre1, the “Quick Search” has a new column for “Stalled”. If that third column were renamed from “Stalled” to “other”, and that count/link were “tickets in any of the @ActiveStatus statuses and NOT in new/open”, then the entire homepage would “work”, I think. For sites without any other custom statuses, that “other” would BE the stalled tickets; I suppose one could get fancy and make the code look at @ActiveStatus and see if it just contains “new open stalled” and use the word “stalled” in the header if so.

I’ll tackle this (once I get some other stuff out of the way) if it makes sense, but wanted to know what other pitfalls anyone can think of that I’m overlooking. And if there’s such strong theological objection to this that a patch would be rejected, I guess I’d like to know that before embarking.

By the way, the ability to customize pages is WAY cool!

OK, I’ve read the discussion about custom statuses before, and
tried to use them, and have concluded that they are, indeed, not a
good idea with the current RT implementation.

I wouldn’t say that they’re a bad idea, but they seem to be like the
red headed stepchild of RT customizations.

What I’d like to do is to explore how hard/reasonable it would be
to support them. I know there’s a lot of theological inertia
against doing so, but from what I see, there’s also a lot of
interest. So to me it’s worth at least considering.

I don’t think it’s much to do with theology. I would prefer custom
fileds in most cases, since it’s easier to fill them with more
meaningful things than just single words.

The product already sort of supports custom statuses, via the
@ActiveStatus and @InactiveStatus records in the config file. The
problem in using them (at least, the problem WE hit; there may be
more!) is that tickets in custom statuses don’t show up on the RT
homepage lists, so they get “lost” easily.

They don’t show up in SelfService as well.

My thinking is that if the default queries for the “highest
priority” (and under “Queue” in “Quick Search”, and, I suppose,
“unowned”) tickets on the homepage were to be “find tickets NOT in
any of the @InactiveStatus statuses” rather than “Find tickets in
new/open/stalled”, then using custom statuses would mostly work.

You can easily implement that change in a local overlay. It should be
in RT proper, but I have been too lazy to produce and post a patch. I
am fairly sure Jesse would accept a clean patch, but possibly not for
3.4.x anymore.

Regards,
Harald

harald wagener
technischer leiter

fcb wilkens
an der alster 42
20099 hamburg
germany

t. +49 (0)40 2881-1252
f. +49 (0)40 2881-1217
m. +49 (0)172 4030-964
hwagener@hamburg.fcb.com
http://www.footeconebelding.de

I’m fatally confused about whether I can customize ticket statuses or not. Various mailing list items seem to indicate yes, no, and maybe.

RT_Config.pm contains:

You can define new statuses and even reorder existing statuses here.

WARNING. DO NOT DELETE ANY OF THE DEFAULT STATUSES. If you do, RT

will break horribly.

@ActiveStatus = qw(new open stalled) unless @ActiveStatus;
@InactiveStatus = qw(resolved rejected deleted) unless @InactiveStatus;

OK, that seems pretty straightforward. So I added two lines to RT_SiteConfig.pm:

@ActiveStatus = qw(new open stalled pricepending customerwait externalwait escalated) unless @ActiveStatus;
@InactiveStatus = qw(resolved rejected deleted) unless @InactiveStatus;

and restarted httpd. Nothing complained, and the new statuses showed up in the dropdown. But when I tried to actually SET one, I got “Illegal value for Status”.

Looking at the mailing list archives some more, I find suggestion of using Queue_Local.pm. I assume this needs to be in lib/RT, along with Queue.pm and friends (the suggestions never actually said where), and I think I proved that by forgetting the trailing “1” in the file and hanging RT :wink: (Restarting httpd again cleared that up.)

So, what’s the real story? Should this work or not? Am I doing something dumb (probably)?

Thanks,

…phsiii

As Emily Litella would have said, “Never mind”. On looking at it ONE MORE TIME, I realized I’d copied the lines from RT_SiteConfig.pm to Queue_Local.pm, and the case is different. Fixing the case in Queue_Local.pm made it work.

Updating the Wiki now.

…phsiii-----Original Message-----
From: Phil Smith III [mailto:lists@akphs.com]
Sent: Tuesday, November 01, 2005 3:17 PM
To: rt-users@lists.bestpractical.com
Subject: Custom statuses

I’m fatally confused about whether I can customize ticket statuses or not. Various mailing list items seem to indicate yes, no, and maybe.

RT_Config.pm contains:

You can define new statuses and even reorder existing statuses here.

WARNING. DO NOT DELETE ANY OF THE DEFAULT STATUSES. If you do, RT

will break horribly.

@ActiveStatus = qw(new open stalled) unless @ActiveStatus;
@InactiveStatus = qw(resolved rejected deleted) unless @InactiveStatus;

OK, that seems pretty straightforward. So I added two lines to RT_SiteConfig.pm:

@ActiveStatus = qw(new open stalled pricepending customerwait externalwait escalated) unless @ActiveStatus;
@InactiveStatus = qw(resolved rejected deleted) unless @InactiveStatus;

and restarted httpd. Nothing complained, and the new statuses showed up in the dropdown. But when I tried to actually SET one, I got “Illegal value for Status”.

Looking at the mailing list archives some more, I find suggestion of using Queue_Local.pm. I assume this needs to be in lib/RT, along with Queue.pm and friends (the suggestions never actually said where), and I think I proved that by forgetting the trailing “1” in the file and hanging RT :wink: (Restarting httpd again cleared that up.)

So, what’s the real story? Should this work or not? Am I doing something dumb (probably)?

Thanks,

…phsiii

Now I feel like an idiot: it’s not working after all.

Queue_Local.pm contains:

@ACTIVE_STATUS = qw(new open stalled pricepending customerwait externalwait escalated);
@INACTIVE_STATUS = qw(resolved rejected deleted);
@STATUS = (@ACTIVE_STATUS, @INACTIVE_STATUS);

1; # the file needs to end with this

and I’ve looked at it and looked at it. What am I missing???

…phsiii

Put next to the RT_SiteConfig and drop customization of the Queue.pm:
@ActiveStatus = qw(new open stalled pricepending customerwait
externalwait escalated);
@InactiveStatus = qw(resolved rejected deleted);

stop and start server, restart doesn’t help.

It’s not recommended way to change status values. Use custom fields instead.On 11/1/05, Phil Smith III lists@akphs.com wrote:

Now I feel like an idiot: it’s not working after all.

Queue_Local.pm contains:

@ACTIVE_STATUS = qw(new open stalled pricepending customerwait externalwait escalated);
@INACTIVE_STATUS = qw(resolved rejected deleted);
@STATUS = (@ACTIVE_STATUS, @INACTIVE_STATUS);

1; # the file needs to end with this

and I’ve looked at it and looked at it. What am I missing???

…phsiii


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Buy your copy of our new book, RT Essentials, today!

Download a free sample chapter from http://rtbook.bestpractical.com

Best regards, Ruslan.

You know, I did read the discussion about using custom fields instead, and I don’t see any real reasoning that says why adding custom statuses should be deprecated. The only reason cited seemed to be:

“You need to separate the workflow status (new, open, closed, etc.) from the business status (sold, returned, exchanged, etc.).”

The ones I want to add are workflow, it seems to me.

I’m not interested in starting a flamewar, but I’d like to understand the reasoning that says “Use custom fields”. If it’s “Custom statuses don’t work”, that’s one thing; if it’s some theological reason, I’d like to understand it.

Thanks,

…phsiiiFrom: Ruslan Zakirov [mailto:ruslan.zakirov@gmail.com]
Sent: Tuesday, November 01, 2005 11:27 PM
To: Phil Smith III
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Re: Custom statuses

Put next to the RT_SiteConfig and drop customization of the Queue.pm:
@ActiveStatus = qw(new open stalled pricepending customerwait
externalwait escalated);
@InactiveStatus = qw(resolved rejected deleted);

stop and start server, restart doesn’t help.

It’s not recommended way to change status values. Use custom fields instead.

The good news: I figured it out.
The bad news: I feel like an idiot.

My custom statuses weren’t working because “pricepending”, “customerwait”, and “externalwait” are all longer than 10 characters. I was trying it One More Time and tried changing it to “escalated” (my other new status) and lo! it worked. And then suddenly it all made sense – I’d seen that 10-character limit discussed somewhere, but had assumed it would complain. Well, it did, just not in a way I understood!

So, the question is still on the table: what’s theologically wrong with adding statuses?

Thanks to all who tried to help me find my *** from my elbow! (Or something like that)

…phsiii