At 10:00 AM 12/11/2002 -0600, email@example.com wrote:
Every time you add a new
queue you’ll have to grant permissions on that queue to the groups you
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
I bet he’d welcome diffs to add in the ACLs you’re looking for, though.
Travis Campbell - Unix Systems Administrator = firstname.lastname@example.org
5900 E. Ben White Blvd, Austin, TX 78741 = email@example.com
TEL: (512) 602-1888 PAG: (512) 604-0341 = firstname.lastname@example.org
"Does anything work as expected?" Yes. An axe through the CPU.