Re: [rt-users] Is lib/RT/Queues_Overlay.pm AddRecord a bug?
On Fri, 30 Nov 2007, Kenneth Crocker wrote: 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 http://ioctl.org/jan/ Random act of violence against bread: whole pint. -- extract from the Hawk the Slayer drinking game ___ 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
Re: [rt-users] Is lib/RT/Queues_Overlay.pm AddRecord a bug?
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
Re: [rt-users] Is lib/RT/Queues_Overlay.pm AddRecord a bug?
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 [EMAIL PROTECTED] 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 http://ioctl.org/jan/
Leverage that synergy! Ooh yeah, looking good! Now stretch - and relax.
___
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
___
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
[rt-users] 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 http://ioctl.org/jan/
Leverage that synergy! Ooh yeah, looking good! Now stretch - and relax.
___
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
