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!
(Restarting httpd again cleared that up.)