set permissions

Another question: I have an object field for group permissions. This retrieves a group list from icms_member_handler and contains the groups included anonymous groups. The group id's will be stored well into the db, but if I try to set the permissions in any way (using ipf_permission_Handler) this seems not to work. I can access as webmaster or as registred user, but not anonymous groups. How I have to handle these stored permissions in ipf? Would be great, if someone could explain this.. Thanks!

Are we talking about access permissions for a specific object?
This would be a one-liner (almost).

yes.. if I add a new object, I can select the groups, which can access the object/see the object..

Edit: to explain more: There's a field called 'grp_perm', wher I want to select the allowed groups to see the object. These object contains other objects from a second class, but without new permission-settings.

Are you using the permssion methods of the handler class to achive that? At least, that's the suggested way of doing it.

$handler->addPermission() would be your starting point. You shouldn't try to recode all the logic. It's already there.

Yes, added this a few hours ago.

In this case I don't understand the issue. Could you be as precise as possible?

So it should be enough to add the permissions in handler (now it is in objectHandler->__construct.. and I don't need to check this again in frontend or any other function? so I should have a look throughout the module to search, if I forgot any code-snippets from previous tryouts.. therefore I asked, how the permissions are working in ipf. there are a lot of possible functions available..

Ok, found it. There was an additional check from previous tryouts. Now it's working fine. thanks for your help..

Glad you figured it out.
For future reference: Additional checks are required (e.g. using the accessGranted function of the object).

Hi together!
Back to the permission control! Ok, I needed some time, but I'm pretty sure, that I understodd now the funktionality of permission control. Two reasons for me, to write this down: At first, I think, this could be useful for others, too. The second reason is, that I would like to know, if one of our core programmers agree in my way or would suggest a different method.
To set up a permission control for a module will require just a few lines of Code. The first, most important step is: add the permissions to the constructor in your handler. I'll try to explain for my new article module, as an example: I have three permissions to set in my handlers: View permissions for Articles, view permissions for categories and submit permissions permissions for new articles for users related to a specific category. So my first way is, to tell the handlers, where I need the permission control:
CategoryHandler.php:

This would initiate the permissions for the system permission handler. What does this code mean? Well, let's have a look inside:

e.g. would be be the permission, I like to use for submit permissions. This is the name for the permission, you can call it however you like. Add one for the view permissions for categories and one for submit permissions for new articles (like you can see in the two lines I added in the constructor above.) The next part in the line, the first constant, will be the language Identification for the field, the second constant is optional to describe the permission control.
That would be the first, most important part. Add something similar for your article handler and you're done:

Again: 'article_grpperm' is the name of the view permissions for articles, described by the two constants.
It will not be necessary to add any field into the Object table now. This will be done by IPF. So you have set up the permission control using three lines of code. But what now? What happens, if you like to check, if the current user has access? Ok, let's start in the handler, it will be the same way for both handler. Usually you will do the query using IPF and adding some db criterias, which Objects you'd like to have. Well, I'm partly using some more. Let's just have one required field: the item should be set to online and the user should have permissions to view the item:

Ok, this is quite simple query, but it will be enough to explain the permission handling:
The first criteria will just be the field, which you have defined to set an item online or offline. The second line will handle the permissions.

The function is in your ipf handler. The first argument is your criteria, however you're calling it. The second argument is the defined permission in your constructor above. That's it. IPF will fetch only Objects, which can be called by the current user/guest.
That's it. Add this line to each query, where it's necessary to fetch objects for a special group. (search function etc.)
Well, but one function you will need to add in the Object, too. Just to get sure, that the current user have permissions to the called Object. Anyone could forward a link to an Object which has restrictions or someone could have bookmarked an object, which is deactivated or had changed the permissions anytime.
So, add the function accessGranted() to your Object.
Add here the lines below:

At first let me explain, what's going on:
in the first part of the code I'm just defining the group permission handler. The third line will check the access permission. The first argument is the permission control you defined in the constructor, again. The second argument will call the current Object id. $groups will call the groups of the current user. If there are no groups, it's anonymous. The last argument will give the current module id. If you need this function from a block, get sure to define your module id by another way.
That's it. Add your additional requirements for object access, e.g. if the current item is set to online. The check to finish the function would be: if $viewperm && your requirements == true-> return true, else return false.
That's it. You're done now in the Object table, too. Your view permissions are ready to go. To check submit permissions add a similar function userCanSubmit() and use something like the $viewperm in the code above and you're done. Just replace in category with category_uplperm or however you called it.
That's it! Your classes are done, if hou have added all similar in
both objects and handler: for categories and objects. Just the submit permissions will be enough to have in category defined, not in Article.
Now let's go to the frontend. Here you normally don't need to do much. Just, if you're calling an Article or a category as a single object. Check something like:
if(is_object($articleObj) && $articleObj->accessGranted() && !$articleObj->isNew()) {

}
if you have defined an action, what to do if not all of the above, place it here, otherwise you'll get a blank page.
That's all. You'll need this twice: once for categories, another for articles and you're done in the frontend. Hopefully I didn't forgot anything? Well, you have questions? don't be shy to ask.. You have suggestions to make it better? Let me know! Have fun if you like to try it

Many thanks for the input on this - I'm sure it could be useful for other developers as well.

Extremely useful. Thank you very much. This should go into the wiki!