[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