I am trying to set up a system that mirrors the features of our in-house
request tracking system, specifically, we have something like queues which
can be either public or private.
The idea being that a public queue can be viewied or reported to by the
‘Everyone’ group, but a private queue has to have access granted explicitly.
Is this possible?
Philip Warner | —___
Albatross Consulting Pty. Ltd. |----/ -
(A.B.N. 75 008 659 498) | /(@) —
Tel: (+61) 0500 83 82 81 | _________
Fax: (+61) 03 5330 3172 | ___________ | Http://www.rhyme.com.au | / |
| –___–
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
The idea being that a public queue can be viewied or reported to by the
‘Everyone’ group, but a private queue has to have access granted explicitly.
Is this possible?
We have two distinct departments using our system and I have created groups
for the two departments. There are several queues for each department and I
grant access to the queues based on group membership. If your not a member of
group A, you don’t see any of group A’s queues, etc.
So yes, it’s possible. You just need to dig into the permissions and adjust
accordingly. You can even set things up so that one group can see all queues
(that’s how our RT administrators group is set up). Every time you add a new
queue you’ll have to grant permissions on that queue to the groups you want to
have access.
Good luck.
Dave Hull
Senior Information Technology Analyst
The University of Kansas
voice: (785) 864-0403 || fax: (785) 864-0485
At 10:00 AM 12/11/2002 -0600, dphull@ku.edu wrote:
Every time you add a new
queue you’ll have to grant permissions on that queue to the groups you
want to
have access.
That’s the problem - they are effectively all private queues. Which means
that a new user can not submit an issue to any of them via email (which
auto-adds the user).
AFAICT, all groups must be public, or all groups must be private - there is
no ACL semantics to deny access - just grant.
Philip Warner | —___
Albatross Consulting Pty. Ltd. |----/ -
(A.B.N. 75 008 659 498) | /(@) —
Tel: (+61) 0500 83 82 81 | _________
Fax: (+61) 03 5330 3172 | ___________ | Http://www.rhyme.com.au | / |
| –___–
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
At 10:00 AM 12/11/2002 -0600, dphull@ku.edu wrote:
Every time you add a new
queue you’ll have to grant permissions on that queue to the groups you
want to
have access.
That’s the problem - they are effectively all private queues. Which means
that a new user can not submit an issue to any of them via email (which
auto-adds the user).
AFAICT, all groups must be public, or all groups must be private - there is
no ACL semantics to deny access - just grant.
We got around this by having a select set of queues that allowed Everyone to
create tickets in. Those queues were monitored by human eyes and tickets were
parceled out to the private queues as needed.
You have to make sure you’re doing this at the queue-level ACL management
interface. If you’re only doing global ACL’s, yes, the queues are one way
or the other.
I agree that it would be nice to have ACLs to deny access, but in the grand
scheme of things, it works well enough to work the other direction. Jesse may
be working on this in later revisions; I don’t know, I haven’t been tracking
the changes.
I bet he’d welcome diffs to add in the ACLs you’re looking for, though.
At 10:39 AM 12/11/2002 -0600, Travis Campbell wrote:
I agree that it would be nice to have ACLs to deny access, but in the grand
scheme of things, it works well enough to work the other direction.
…
I bet he’d welcome diffs to add in the ACLs you’re looking for, though.
Thanks for the info; for the moment I’ll work with existing ACLs and see
how it goes.
Philip Warner | —___
Albatross Consulting Pty. Ltd. |----/ -
(A.B.N. 75 008 659 498) | /(@) —
Tel: (+61) 0500 83 82 81 | _________
Fax: (+61) 03 5330 3172 | ___________ | Http://www.rhyme.com.au | / |
| –___–
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
