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
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
If you sign up for a new RT support contract before December 31, we'll take
up to 20 percent off the price. This sale won't last long, so get in touch today.
Email us at [EMAIL PROTECTED] or call us at +1 617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
