I’ve been looking at how to change the list of what statuses constitute Active and Inactive in the homepage and I’m stumped. (Yes, we have done The Evil Thing and defined custom statuses; let’s not rehash that, it wasn’t my decision.)
Are these saved queries somehow in PostgreSQL? Or is it hiding in the Perl somewhere? I’ve spent time grepping and thought it was in Queue_Overlay.pm but that doesn’t seem to be it.
If someone can give me a hint, I’d appreciate ite…
…phsiii
I’ve been looking at how to change the list of what statuses
constitute Active and Inactive in the homepage and I’m stumped.
You want etc/RT_SiteConfig.pm As described in etc/RT_Config.pm:
# 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.
Set(@ActiveStatus, qw(new open stalled));
Set(@InactiveStatus, qw(resolved rejected deleted));
Thanks, but that doesn’t do it: it adds those statuses, but if we’ve added, say, an ActiveStatus of “escalated”, the RT homepage doesn’t list any tickets in that status. That’s what I’m trying to fix; I apologize for being unclear.
…phsiii-----Original Message-----
From: chmrr@zoq-fot-pik.mit.edu [mailto:chmrr@zoq-fot-pik.mit.edu] On Behalf Of Alex Vandiver
Sent: Monday, March 27, 2006 8:41 PM
To: Phil Smith III
Cc: rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] ActiveStatus and InactiveActiveStatus
On Mon, 2006-03-27 at 20:14 -0500, Phil Smith III wrote:
I’ve been looking at how to change the list of what statuses
constitute Active and Inactive in the homepage and I’m stumped.
You want etc/RT_SiteConfig.pm As described in etc/RT_Config.pm:
# 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.
Set(@ActiveStatus, qw(new open stalled));
Set(@InactiveStatus, qw(resolved rejected deleted));
Heya!On Mon, 2006-03-27 at 20:44 -0500, Phil Smith III wrote:
Thanks, but that doesn’t do it: it adds those statuses, but if we’ve added,
say, an ActiveStatus of “escalated”, the RT homepage doesn’t list any tickets
in that status. That’s what I’m trying to fix; I apologize for being unclear.
I’m working to understand what you mean by “…the RT homepage doesn’t
list any tickets in that status” … I think you mean that none of the
ticket lists like “10 highest priority tickets I own”. You also didn’t
mention what version of RT you’re using, and that makes a big
difference.
If you’re using 3.5.x or greater, log in as a SuperUser and click the
Edit button by the offending list of tickets. You should see a link
which will allow you to edit the underlying query; most of those queries
are looking for new and/or open, so just add your statuses and save it
again.
If you’re in 3.4.x, it’s tougher and I’m not qualified to guide you
blind. I think you’re going to end up editing the underlying HTML files
for several elements on the page, but there may be smarter ways to get
what you want.
BTW, if you’re on pre-3.5.x, you really owe it to yourself to install a
dev instance of 3.6.0pre0 (or even just 3.5.5) and see what you’re
missing. It’s night and day. =]
Cheers!
–j
Jim Meyer, Geek at Large purp@acm.org
Yeah, I’m sounding like an amateur here – I do know better. This is 3.4.4. Sounds like it’s time to upgrade!
I mean both the “10 highest priority” list and if I click through on a queue name in the “Quick Search” list at the right.
…phsiiiFrom: Jim Meyer [mailto:purp@acm.org]
Sent: Monday, March 27, 2006 8:55 PM
To: Phil Smith III
Cc: ‘Alex Vandiver’; rt-devel@lists.bestpractical.com
Subject: RE: [Rt-devel] ActiveStatus and InactiveActiveStatus
Heya!
In 3.4.4 you 'll need to edit your Element
(/opt/rt3/local/html/Element/MyTickets) and add the line
$MyTickets->LimitStatus(VALUE => “escalated”); in your query …(within
the <%INIT>)
Roy
Phil Smith III wrote:
Thanks to the various helpful advice from y’all, I’ve got it working. I had to change 4 files:
./share/html/index.html
./share/html/Elements/MyRequests
./share/html/Elements/MyTickets
./share/html/Elements/Quicksearch
In all but the last, it was a matter of changing:
"Status = ‘new’ OR Status = ‘open’"
in lines such as:
my $status = “Status = ‘new’ OR Status = ‘open’”;
to:
“Status != ‘resolved’ AND Status != ‘rejected’ AND Status != ‘deleted’”;
The change to Quicksearch was a teeny bit more involved. The line:
my $open_q = “Queue = ‘$name’ AND Status = ‘open’”;
became:
my $open_q = “Queue = ‘$name’ AND Status = ‘open’ OR Status = ‘clientwait’ OR Status = ‘escalated’ OR Status = ‘otherwait’ OR Status = ‘pricewait’ OR Status = ‘stalled’”;
(as you can tell, our custom statuses are “clientwait”, “escalated”, “otherwait” and “pricewait”)
and
my $all_q = “Queue = ‘$name’ AND (Status = ‘open’ OR Status = ‘new’)”;
became:
my $all_q = "Queue = '$name' AND (Status != 'resolved' AND Status != 'rejected' AND Status != 'deleted')";
I suppose I could have made the second change be universal by making it a set of != including “new”, but I was half asleep, and I’m planning to upgrade anyway, but wanted to see if I could get this working in the meantime.
I also changed the Quicksearch header from “Open” to “(open)” but that’s obviously cosmetic.
I had to rm -rf /opt/rt3/var/mason_data/obj/3544762124 every time to get this to ‘take’; I’ve read all the Mason stuff about how you shouldn’t have to clear the cache but that just doesn’t seem to be true in my experience.
I’m sending this not because I think many folks care, but to capture the facts for the record in case one day someone DOES care!
…phsiii
Hello!
Yeah, I’m sounding like an amateur here – I do know better.
This is 3.4.4. Sounds like it’s time to upgrade!
Very much so. We’ve found 3.5.5 to be pretty stable for our purposes,
and a huge usability improvement. Huge. Enormous. Indescribably large.
Also, I think the schema changes from 3.4.x → 3.5.x were additive – I
don’t think a 3.4.x instance would notice the difference. BEFORE YOU
BELIEVE THAT, you should see if anyone contradicts me here and/or go
read the sql code that’s used to do the upgrade.
I mean both the “10 highest priority” list and if I click through on a
queue name in the “Quick Search” list at the right.
3.5.x settles your list issue; IIRC, you’ll have to hack the Quicksearch
component in ${RTHOME}/local/html/Elements/Quicksearch (after copying it
there from …/share/html/…, of course =).
Cheers!
–j
Jim Meyer, Geek at Large purp@acm.org
Very much so. We’ve found 3.5.5 to be pretty stable for our purposes,
and a huge usability improvement. Huge. Enormous. Indescribably
large.
Wow, that’s pretty big. Makes me wonder if its time to upgrade
myself… /me wishes he had a dev environment.
Also, I think the schema changes from 3.4.x → 3.5.x were additive –
I
don’t think a 3.4.x instance would notice the difference. BEFORE YOU
BELIEVE THAT, you should see if anyone contradicts me here and/or go
read the sql code that’s used to do the upgrade.I mean both the “10 highest priority” list and if I click through on
a
queue name in the “Quick Search” list at the right.
Anyone anyone?
Duncan
Very much so. We’ve found 3.5.5 to be pretty stable for our purposes,
and a huge usability improvement. Huge. Enormous. Indescribably
large.Wow, that’s pretty big. Makes me wonder if its time to upgrade
myself… /me wishes he had a dev environment.
We’ve found and fixed a whole lot of issues since then. I’d love to know
if 3.5 from subversion works as well for you.
Jesse
I just put 3.6pre0 into production. So far so good. Everyone loves
the new look, graphs, and the user prefs. Is 3.5 from subversion
newer than 3.6pre0?
Barely. I need to roll Pre1 in the next few days. Once we get to RC1,
the branch will get moved to 3.6-RELEASE 
I just put 3.6pre0 into production. So far so good. Everyone
loves
the new look, graphs, and the user prefs. Is 3.5 from subversion
newer than 3.6pre0?Barely. I need to roll Pre1 in the next few days. Once we get to RC1,
the branch will get moved to 3.6-RELEASE
Mmmmm. I’m getting excited for 3.6!
UPDATED – Found a bug in my change (Missing parens in the Quicksearch update)
Thanks to the various helpful advice from y’all, I’ve got it working. I had to change 4 files:
./share/html/index.html
./share/html/Elements/MyRequests
./share/html/Elements/MyTickets
./share/html/Elements/Quicksearch
In all but the last, it was a matter of changing:
"Status = ‘new’ OR Status = ‘open’"
in lines such as:
my $status = “Status = ‘new’ OR Status = ‘open’”;
to:
“Status != ‘resolved’ AND Status != ‘rejected’ AND Status != ‘deleted’”;
The change to Quicksearch was a teeny bit more involved. The line:
my $open_q = “Queue = ‘$name’ AND Status = ‘open’”;
became:
my $open_q = “Queue = ‘$name’ AND (Status = ‘open’ OR Status = ‘clientwait’ OR Status = ‘escalated’ OR Status = ‘otherwait’ OR Status = ‘pricewait’ OR Status = ‘stalled’)”;
(as you can tell, our custom statuses are “clientwait”, “escalated”, “otherwait” and “pricewait”)
and
my $all_q = “Queue = ‘$name’ AND (Status = ‘open’ OR Status = ‘new’)”;
became:
my $all_q = "Queue = '$name' AND (Status != 'resolved' AND Status != 'rejected' AND Status != 'deleted')";
I suppose I could have made the second change be universal by making it a set of != including “new”, but I was half asleep, and I’m planning to upgrade anyway, but wanted to see if I could get this working in the meantime.
I also changed the Quicksearch header from “Open” to “(open)” but that’s obviously cosmetic.
I had to rm -rf /opt/rt3/var/mason_data/obj/3544762124 every time to get this to ‘take’; I’ve read all the Mason stuff about how you shouldn’t have to clear the cache but that just doesn’t seem to be true in my experience.
I’m sending this not because I think many folks care, but to capture the facts for the record in case one day someone DOES care!
…phsiii