eZ Community » Forums » General » Role has Policy ?
expandshrink

Role has Policy ?

Role has Policy ?

Thursday 19 January 2012 6:01:38 pm - 7 replies

Good evening everyone.
 In a PHP script, I want to know if a role already has a policy.

$anonymous = eZRole::fetchByName('anonymous');
$anonymous->hasPolicy('content', 'read');

I need to know this to avoid doing so several times.

if ( ! $anonymous->hasPolicy('content', create) ){
   $policy = eZPolicy::create($anonymous_id, 'content', 'read');
   $policy->store();
}

Obviously the function hasPolicy does not exist ....
How can I achieve this?

Bonus: I need to extend that to the limitations.

 

Thank you in advance for your help.

Modified on Thursday 19 January 2012 6:02:16 pm by Rémy PHP

Friday 20 January 2012 9:44:14 am

Good morning.

The night has inspired me big-smile.gif Emoticon

it works pretty well

 function role_has_policy($role_id, $module, $function, $limitations = null){
    $db = eZDB::instance();
    $sql = "SELECT COUNT( DISTINCT p.id ) AS cnt
    FROM ezpolicy p
    WHERE p.role_id = $role_id
    AND p.function_name = '$function'
    AND p.module_name = '$module'";
    $countResult = $db->arrayQuery( $sql );
    return (bool)$countResult[0]['cnt'];
}

EDIT : Please do not use my solution !!! 

Modified on Monday 23 January 2012 10:06:51 am by Rémy PHP

Friday 20 January 2012 10:17:32 am

Hello Remy,

I welcome your sharing here on share. Thank you!

 

But the thing is ... and I've said it a bit more regularly here in the forums but it's still true.

Now on the outset ... this may seem like a well inteneded solution but it's really the worse way I could imagine to reach your goal.

 

It really seems simply a bad idea made worse by resulting to it in the same way I would not want to embed identifiers in templates or not upgrade code that was not cluster aware or not use a unique identifier prefix in an extension name or write a mysql only database hardcoded solution. 

 

The best advice given is always simple to follow.

Always use the PHP eZ Publish API to get the work done within eZ Publish (as must as is possible; almost always possible).

 

We live in the future! Kernel overrides are your friend!

In this case I wonder about the more viable, maintainable, flexible alternative for those who will not lower themselves to these forms of lower level implementations. What about using a kernel class override extension?

With a kernel override you can modify the eZRole PHP class to provide the functionality you desire and require cleanly.

This also provides for the oportunity to write a solution which is not database specific (remember pgsql support just got advances very recently in master so ... we are not mysql only any more (for the cluster folks as well at least)).

 

eZ Role Modification Ideas and Suggestions

I was just briefly looking at the doxygen docs for eZRole and wonder if you could not easily fasion a solution based on the implementation of the 'removePolicy' function.

http://pubsvn.ez.no/doxygen/trunk/html/classeZRole.html#ac0dc9b6c36cd9463cafd0bec26664155

http://pubsvn.ez.no/doxygen/trunk/html/ezrole_8php_source.html#l00352

 

Also worth reading is the 'policyList' function

http://pubsvn.ez.no/doxygen/trunk/html/classeZRole.html#afeb6e2c93dfc4a746220f731b225d8eb

http://pubsvn.ez.no/doxygen/trunk/html/ezrole_8php_source.html#l00610

 

Warnings and closing

I'm no expert mind you on this matters but that itself sounds like a helpful feature, provided within the available system not outside it, unless I'm overlooking something else that already exist elsewhere.

Still I would not recommend the solution your sharing because of the database specific nature of the implementation when eZ Publish is rigid in it's database abstraction. I remember watching them shoot down the fetch object_id only solution in the issue tracker because it could only be a mysql only solution at the time.

What I mean is eZ Publish is supports using any combination of an number of different database solutions and vendors (mysql, pgsql, oracle, and prolly more with a little effort) and that a solution that goes against those values seems like one that would not be the best solution to recommend overall.

 

Offer to help

If any one can concur with my statements (above).

I'd be happy to write and share a gist with the required code for review and testing.

 

I hope this helps ...

 

Cheers,

Heath

 

Update: Apologies for not replying earlier with an answer more directly. It's been a very long and distracting work day.

Modified on Friday 20 January 2012 10:23:29 am by // Heath

Friday 20 January 2012 11:07:19 am

Hello Heath and thank you for your reply.
I agree with you on all these points.
But I do not master well enough yet the eZPublish kernel to be able to operate properly.
I hope it will come.

Friday 20 January 2012 11:22:04 am

Hello Remy,

 

I encourage you to keep studying and practicing. This is key. You can reach your goals within the system as designed.

 

Updated Edit: We have published the extension we commited to previously.

Hello Remy,

 

We have just now published the solution I spoke about yesterday as a full GitHub repository: https://github.com/brookinsconsulting/bcrolehaspolicykerneloverride

You can download the improved eZRole PHP Class as a complete extension and use it right out of the box in minutes as an extension or a kernel hack in other non-standard configurations.

 

Let me know if you still need some help with using kernel override extensions (enable extension normally, clear cache, regenerate autoloads, regenerate kernel override autoloads, config.php setup to enable kernel overrides in general) and I can explain in greater detail. Also you can refer to the extension documentation which is quite detailed I must say ..

 

We welcome testing and feedback from any and all users with an interest or time to see if this improvement is valuable to them as well.

 

If there is a  specific interest  having us move this solution into a eZ Publish GitHub Pull request for inclusion back into the eZ Publish kernel by default.

Please share your desire for us to make this a pull request and we will greatly consider doing so as the extra work is usually worth while endeavor provided the results are desired by others as well.

This might help you later if the feature you wanted was provided by default, then you would not need this solution at all. Just a thought ...

 

Again, I hope this helps ...

 

Cheers,

Heath

Modified on Sunday 22 January 2012 10:41:41 pm by // Heath

Sunday 22 January 2012 10:36:33 pm

Hello Remy,

 

We took the time to convert the Gist posted previously into a full fledged eZ Publish kernel override extension. This extension has been documented with a specific attention to detail. 

Anyone should be able to use this solution right out of the box without troubles.

Anyone should be able to create a kernel override extension using this solution as an example reference implementation as it is very simple and well documented.

Get your copy today! https://github.com/brookinsconsulting/bcrolehaspolicykerneloverride

 

I hope this helps you and others in the future with a need to override default kernel classes simply as all the specifics are provided in this example implementation.

 

In the next week we will publish this solution on projects.ez.no for everyone to find and use as needed.

 

Cheers,

Heath

Monday 23 January 2012 10:05:47 am

Thank you! It's great! I did not know this possibility of eZPublish to override the kernel classes. (Too bad we can not do it by inheritance ..)
 However I noticed that the comments of the functions are written with this syntax:
 
/ *!
* comment
* /
Now my IDE (Eclipse) does not understand this syntax and therefore does not document my auto-completion ...
Where can I find more information on this symtaxe?
Is it possible to be understood by Eclipse?
Again thank you for your help. 

Monday 23 January 2012 11:10:12 am

Hello Remy,

I'm happy to help you expand your knowledge of eZ Publish! 

I think all new PHP comments in eZ Publish are to use the phpdoc standard previously the doxygen standard was used.

I'm sorry I'm not familiar with the type of support you describe offhand within that ide.

Though this search might be a good starting point since this is not eZ Publish specific offhand, http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=phpdoc+support+in+eclipse

 

I hope this helps ...

 

Cheers,

Heath

Modified on Monday 23 January 2012 11:12:57 am by // Heath

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu