[rt-users] Is lib/RT/Queues_Overlay.pm AddRecord a bug?

Jan Grant jan.grant at bristol.ac.uk
Fri Nov 30 07:20:35 EST 2007


Looking for an appropriate way to get the following behaviour, being 
stymied by the
    return unless $Queue->CurrentUserHasRight('SeeQueue');
line.

Basically: we have teams here. We're using RT predominantly internally 
to manage inter-team requests (to stop them getting dropped on the 
floor). Since we want to get rid of having to pester middle-men, our 
config gives "CreateTicket" to all Privileged members globally.

This works: we can raise tickets in any team's queues (which they can 
then reject if necessary, but the point is that we don't have to say to 
someone, "please raise a ticket in your team's queue", which defeats the 
object).

BUT: there are many queues. In an attempt to reduce clutter on the front 
page, we're interested in allocating SeeQueue on queue X to groups only 
associated with team X. That way the front page has a less cluttered 
Elements/QuickSearch.


(Summary: we have queues where users may have CreateTicket but not 
SeeQueue.)


Now, it appears that lib/RT/Queues_Overlay AddRecord us using SeeQueue 
not just for UI creation, but assigning it additional semantics: if I 
ask for queues where I have the CreateTicket rights, I only get a list 
of queues where I have both CreateTicket AND SeeQueue.

I think that's broken: I can raise tickets via the mailgate, for 
example, solely on the basis of "CreateTicket". But the "new ticket in" 
dropdown (Elements/CreateTicket) doesn't show me all queues I have that 
right on.


So, I'm wondering where to go from here. My options appear to be, 
firstly, to remove the SeeQueue filtering that goes on in 
Queues_Overlay/AddRecord. I'm not sure how much code relies on that 
test, however.

The second option is to accept that SeeQueue's semantics are overloaded 
by RT::Queues, and to add an additional right to manage the visibility 
of queues within UI elements.


If I'm barking up the wrong tree please let me know! - I basically can't 
figure out what SeeQueue should really be for. Looking for advice as to 
the best way to proceed.

Cheers,
jan

-- 
jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661   http://ioctl.org/jan/
Leverage that synergy! Ooh yeah, looking good! Now stretch - and relax.



More information about the rt-users mailing list