Top N lists

RT Users
1

We’ve taken the code in “MyTickets” and modified it to form a new module.

With the new code, instead of limiting the list to the current user, it is
limited to “Nobody”, thus allowing everyone to easily see which tickets have
got the highest priority but no owners.

That is all working fine.

However, we’ve now added a second queue. Not a problem, you might think. The
problem comes when some of the privileged users have rights on one queue but
not the other.

What seems to be happening is that the code is taking the list of tickets,
limiting them by owner & status, then taking the first N rows and then
displaying them.

So what is wrong with that?

Well, if the current user doesn’t have privilege on both queues, and the
first N tickets (in priority order) all belong to the other queue, the above
code displays no tickets at all.

What I want/need/would like to see happen is for the list of tickets to be
filtered by what the user has rights over first of all, before anything else
is done.

I had sort of expected that, given that “new RT::Tickets” takes the current
user session has a parameter.

Any suggestions?

Thanks.

–Philip

Philip Colmer, MBCS CEng CCSE Tel: 01223 271223
I.T. Manager Fax: 01223 215513
ProQuest Information & Learning
The Quorum, Barnwell Road, Cambridge, CB5 8SW

2

I’ve tried to do some more research into why my “Top N unassigned” module
doesn’t work properly if you don’t have access to all of the queues on the
system.

Here is the test scenario:

2 queues
4 tickets - 2 in each queue, alternating IDs
2 groups - one for adminning each queue
3 users - one in each group and a third in both

If you have the Top N module configured to show only 2 jobs:

User Desired behaviour Actual behaviour
Both Show top 2 jobs Shows top 2 jobs
Q1 Show top 2 Q1 jobs Shows first Q1 job
Q2 Show top 2 Q2 jobs Shows first Q2 job

I hope that is clear :slight_smile:

My initial thinking was that RT::Tickets wasn’t limiting the set of tickets
to those that the current user could admin, but further checking of the code
shows that it doesn’t work like that.

The filtering of which tickets the user sees is actually done by the Next
method. The next ticket is retrieved through $self->SUPER::Next(); and then
checked. If the user has “ShowTicket” rights, the ticket is returned
otherwise the method recurses to get the next ticket that the user can see
or the end of the line.

It is the recursion that is where this appears to go wrong. By adding
debugging to the code, it looks as if the next ticket retrieved through the
recursion process doesn’t work and it just returns undef. By comparison, if
you comment out the permission testing, all records do get returned (albeit
some of them aren’t accessible by the user because of permissions).

Unfortunately, my Perl isn’t up to figuring out why the recursion isn’t
working, so I’m hoping that someone can help me out here!

I also had an idea that I might be able to solve the problem by using
"LimitQueue" first off to explicitly restrict the ticket list by specifying
which queues the user has access to, but that doesn’t work either!

I’ve tried adding this to the INIT code for the module:

My $MyQueues;
$RT::Logger->debug(“Checking queues\n”);
$MyQueues = new RT::Queues ($session{‘CurrentUser’});
while (my $Queue = $MyQueues->Next) {
$RT::Logger->debug("Got queue ".$Queue->Name);
}

But the debugging code that says “Got queue” is never used. The only way I
can get any names out is by adding

$MyQueues->UnLimit

before the while loop, but then it outputs ALL of the queue names,
regardless of whether or not you’ve got See Queue permission.

Am I overlooking something or is there a problem with the RT code?

–Philip

Philip Colmer, MBCS CEng CCSE Tel: 01223 271223
I.T. Manager Fax: 01223 215513
ProQuest Information & Learning
The Quorum, Barnwell Road, Cambridge, CB5 8SW