Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Devel

[PATCH] Specify Queue ACLS at queue declaration on initialdata

 

 

Request Tracker devel RSS feed   Index | Next | Previous | View Threaded


chad at opensourcery

Jan 7, 2009, 3:53 PM

Post #1 of 7 (1196 views)
Permalink
[PATCH] Specify Queue ACLS at queue declaration on initialdata

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)
Attachments: rt-QueueACL.patch (0.64 KB)
  signature.asc (0.25 KB)


jesse at bestpractical

Jan 7, 2009, 3:59 PM

Post #2 of 7 (1140 views)
Permalink
Re: [PATCH] Specify Queue ACLS at queue declaration on initialdata [In reply to]

On Wed, Jan 07, 2009 at 03:53:01PM -0800, Chad Granum wrote:
>
> 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 ;)



>
> -Chad Granum
>
> OpenSourcery (www.opensourcery.com)

> --- lib/RT/Handle.pm-orig 2009-01-07 14:57:06.000000000 -0800
> +++ lib/RT/Handle.pm 2009-01-07 15:24:17.000000000 -0800
> @@ -768,7 +768,14 @@
> $RT::Logger->debug("Creating queues...");
> for my $item (@Queues) {
> my $new_entry = new RT::Queue($RT::SystemUser);
> + my $ACL = delete $item->{ ACL };
> my ( $return, $msg ) = $new_entry->Create(%$item);
> +
> + if ( $return and $ACL ) {
> + $_->{ Queue } = $new_entry->Id for @$ACL;
> + push @ACL => @$ACL;
> + }
> +
> unless ( $return ) {
> $RT::Logger->error( $msg );
> } else {




> _______________________________________________
> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


--
_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


ruslan.zakirov at gmail

Jan 7, 2009, 8:33 PM

Post #3 of 7 (1131 views)
Permalink
Re: [PATCH] Specify Queue ACLS at queue declaration on initialdata [In reply to]

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 [at] opensourcery>:
> 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: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>
>



--
Best regards, Ruslan.
_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


chad at opensourcery

Jan 7, 2009, 8:51 PM

Post #4 of 7 (1143 views)
Permalink
Re: [PATCH] Specify Queue ACLS at queue declaration on initialdata [In reply to]

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:
> 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 [at] opensourcery>:
>
>> 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: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>>
>>
>>
>
>
>
>
Attachments: signature.asc (0.25 KB)


chad at opensourcery

Jan 8, 2009, 8:38 AM

Post #5 of 7 (1125 views)
Permalink
Re: [PATCH] Specify Queue ACLS at queue declaration on initialdata [In reply to]

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:
> 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 ;)
>
>
>
>
>> -Chad Granum
>>
>> OpenSourcery (www.opensourcery.com)
>>
>
>
>> --- lib/RT/Handle.pm-orig 2009-01-07 14:57:06.000000000 -0800
>> +++ lib/RT/Handle.pm 2009-01-07 15:24:17.000000000 -0800
>> @@ -768,7 +768,14 @@
>> $RT::Logger->debug("Creating queues...");
>> for my $item (@Queues) {
>> my $new_entry = new RT::Queue($RT::SystemUser);
>> + my $ACL = delete $item->{ ACL };
>> my ( $return, $msg ) = $new_entry->Create(%$item);
>> +
>> + if ( $return and $ACL ) {
>> + $_->{ Queue } = $new_entry->Id for @$ACL;
>> + push @ACL => @$ACL;
>> + }
>> +
>> unless ( $return ) {
>> $RT::Logger->error( $msg );
>> } else {
>>
>
>
>
>
>
>> _______________________________________________
>> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>>
>
>
>
Attachments: signature.asc (0.25 KB)


chad at opensourcery

Jan 8, 2009, 8:41 AM

Post #6 of 7 (1127 views)
Permalink
Re: [PATCH] Specify Queue ACLS at queue declaration on initialdata [In reply to]

Ooops, helps to attach the patch...


Chad Granum wrote:
> 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)
>
>
Attachments: rt-plugins-initialdata.patch (0.25 KB)
  signature.asc (0.25 KB)


chad at opensourcery

Jan 8, 2009, 8:42 AM

Post #7 of 7 (1123 views)
Permalink
Re: [PATCH] Specify Queue ACLS at queue declaration on initialdata [In reply to]

Wow, I am on a roll today :-) wrong patch....

this time for real now...

Chad Granum wrote:
> Ooops, helps to attach the patch...
>
>
> Chad Granum wrote:
>
>> 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)
>>
>>
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
Attachments: rt-initialdata-expand.patch (5.43 KB)
  signature.asc (0.25 KB)

Request Tracker devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.