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

[Kenneth Crocker]

Jan,


	My understanding of the "SeeQueue" and "CreateTicket" rights are that 
they are related/coupled when creating ticket via WebUI. It's the same 
thing as granting "CreateTicket" globally but also needing the 
email/correspondence address of any queue you want to create a ticket in 
using self-service. In other words, granting the "SeeQueue" right to a 
group for a queue accomplishes the same filtering effect for creating a 
ticket via WebUI as giving/witholding the email/correspond address to a 
queue from a user so they can/can't create tickets via email (unless you 
have given them the ability to "SeeConfigTab", which would be highly 
unlikely/unwise for someone who should only be creating tickets). It 
makes sense to me and I don't see it as broken. As to your idea of 
granting "SeeQueue" on a "group only to queue" basis sounds like the 
right approach. Nothing broken and no need for changes to code. Hope 
this helps.

Kenn
LBNL

On 11/30/2007 4:20 AM, Jan Grant wrote:
> 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
>