Is lib/RT/Queues_Overlay.pm AddRecord a bug?

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 jan's very old home page
Leverage that synergy! Ooh yeah, looking good! Now stretch - and relax.

In more versions of RT 3.6.x (all?) you can customizer per-user what
queues show up under Quick Search. This would be much better than
trying to monkey with rights.On 11/30/07, Jan Grant jan.grant@bristol.ac.uk 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


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


The rt-users Archives

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 sales@bestpractical.com or call us at +1 617 812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

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
LBNLOn 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

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.

Understood. As Todd points out:

In more versions of RT 3.6.x (all?) you can customizer per-user what
queues show up under Quick Search. This would be much better than
trying to monkey with rights.

… which is ok, although we’re using a customised interface that dates
from the 3.4 era. I’ll look into the possibility of shifting our local
changes into a 3.6-based interface.

I’m still interested in using a new right (which we can manage for large
groups of users rather than on a per-user basis) to control the
Elements/QuickSearch selection. Is this as straightforward as I think it
should be?

Cheers,
jan

jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661 jan's very old home page
Random act of violence against bread: whole pint.
– extract from the “Hawk the Slayer” drinking game