Currently ACLs and Queues must be done separately:
@Queues = (
…
);
@ACL = (
…
);
Most often though you specially want to set the rights on a queue
created previously. And with enough queues and rights it can be hard to
find things depending on how you lay your file out. It also opens the
possibility of typing the name of the queue wrong in one of the acls,
something that can be hard to track down.
This patch allows you to specify queue related ACLs in the Queue definition:
@Queues = (
…
ACL => [
…
],
);
The patch works by first creating the queue, then adding it as the Queue
=> in each item from ACL, then pushing that list onto the global @ACL
list so they will be loaded with the others when Handle gets to them.
Simply put this patch allows you more control over how you organize your
initialdata while reusing code as much as possible.
-Chad Granum
OpenSourcery (www.opensourcery.com)
rt-QueueACL.patch (651 Bytes)
signature.asc (252 Bytes)
The patch works by first creating the queue, then adding it as the Queue
=> in each item from ACL, then pushing that list onto the global @ACL
list so they will be loaded with the others when Handle gets to them.
Simply put this patch allows you more control over how you organize your
initialdata while reusing code as much as possible.
Reasonable intent, but the code itself is fairly hard to read.
“$return and $ACL” sounds kind of bizarre.
Standard convention is ->id rather than ->Id
I’d shy away from using $ACL and @ACL in the same
chunk of code.
$item->{ ACL } isn’t really the same as standard RT style. I’d probably
do $item->{‘ACL’} instead.
I’d move your new if block to inside the else clause running off the end
of your patch and phrase it as
if (my $acl = delete $item->{‘ACL’}) {
}
though I suppose you’d then be passing it into the create, which is
suboptimal.
Well, at least lowercase your variable, since the new allcaps scalar
variable looks like a global 
Here what we have in RTIR, works just fine:
for my $queue (map {$_->{Name}} @Queues) {
push @ACL, (
{ GroupDomain => ‘RT::Queue-Role’,
GroupType => ‘Owner’,
Queue => $queue,
Right => ‘ModifyTicket’, },
…2009/1/8 Chad Granum chad@opensourcery.com:
Currently ACLs and Queues must be done separately:
@Queues = (
…
);
@ACL = (
…
);
Most often though you specially want to set the rights on a queue
created previously. And with enough queues and rights it can be hard to
find things depending on how you lay your file out. It also opens the
possibility of typing the name of the queue wrong in one of the acls,
something that can be hard to track down.
This patch allows you to specify queue related ACLs in the Queue definition:
@Queues = (
…
ACL => [
…
],
);
The patch works by first creating the queue, then adding it as the Queue
=> in each item from ACL, then pushing that list onto the global @ACL
list so they will be loaded with the others when Handle gets to them.
Simply put this patch allows you more control over how you organize your
initialdata while reusing code as much as possible.
-Chad Granum
OpenSourcery (www.opensourcery.com)
List info: The rt-devel Archives
Best regards, Ruslan.
Thats very useful, but only if you want to assign the same right to all
your queues, this is for cases where you have different rights per
queue, and do not want to have the queue and its rights separate.
This is actual one part of a larger thing I have been working on/using
at opensourcery, and thinking about it each part separate like this is
probably not as good as if I rolled it all into a Handle and submitted a
full patch.
Stay tuned 
-Chad
Ruslan Zakirov wrote:
signature.asc (260 Bytes)
Thank you for the feedback and tips!
I have made changes based on the feedback that I think should take
care of the issues.
As I mentioned in a previous email I was planning to roll all the
Handle.pm enhancements I think people might like into one patch. Here it is.
This covers the patch from the start of this thread, but fixed, the
patch I submitted that is now in the ticket:
http://rt3.fsck.com/Ticket/Display.html?id=13036 , as well as some new
functionality.
I added ExpandItems() and several ExpandXXX() functions that use it.
Essentially there are many cases where it would be nice to specify a
list of items in an initialdata item instead of duplicating the item for
each thing you want to apply it to. But on some things, such as ACL
doing so for every key people might want to provide a list to would
create a huge set of nested loops.
This is an alternative to doing a for loop on each thing that can be a
list. Essentially it is a function to take the items that can be a list,
and duplicate them in advance. It does one list at a time and as such it
is much more maintainable.
This also allows a developer to add new items that can be lists very
easily w/o creating more nested loops. The one caveat I can think of is
that there are some things that can be lists that we do not want to
duplicate the item for. The best example is Queues => in @CustomFields,
we do NOT want to create a new field for each queue, we want the same
field in each. Luckily Queue => already supports a list in CustomFields.
There is one part specifically I suspect you might want to ditch, thats
the ExpandScrips, see the comment in the patch.
-Chad Granum
OpenSourcery (www.opensourcery.com)
Jesse Vincent wrote:
signature.asc (252 Bytes)
Ooops, helps to attach the patch…
Chad Granum wrote:
rt-plugins-initialdata.patch (257 Bytes)
signature.asc (252 Bytes)
Wow, I am on a roll today 
wrong patch…
this time for real now…
Chad Granum wrote:
rt-initialdata-expand.patch (5.43 KB)
signature.asc (252 Bytes)