If I am understanding this system correctly, each entry is a file within my intended system. The initial loading of all files on to the server and the creation of associated db records will be programmatic.

Farshad

Thank you!

Dimitar

Hi Ben,

Here goes the patch as I promised in last post.
rbac_patches.zip

Note:
1. patch also incorporates two fixes from this forum and class.rbacAdmin_bv.php and class.rbac_bv.php from your RBAC.zip
2. patch is against vanilla rbac_admin
3. there are two versions of patch, one for unix and other for windows environment (difference in cr/nl or nl)

How to apply patch?
uncompress patch archive
choose the patch based on your environment
copy patch to path_to_vanilla_rbac_admin
cd path_to_vanilla_rbac_admin
patch -p1 patch

Examples of use are in function PrintPage of class.page_bv.php
Be warned that I didn't make test on windows at all.

Cheers,
Sinisa

Thanks a lot Sinisa. That is great.
Cheers,

Ben

Hi,

I'm not sure whether your RBAC system can solve the following problem. So I hope you could give me some help.

Some blogposts exist. Permissions apply based on a variety of conditions. Eg an admin may view all posts, a regular user can only view posts that don't have the 'draft' status.

This could probably be solved easily by creating 2 domains: posts and drafts (or something alike). But suppost additional rules exist. The regular users also cannot view posts that are in category 'premium', or tagged with 'pending review'. This would mean an explosion of domains (all the combinations).

How would your system solve this?

Thanks
Koen

Domains are collections of objects. In your case you will have the following objects:
- post
- draft
- premium
- pending

Based on these objects you can create domains. And it is not as complex or large as it seems. (The system is meant to efficiently deal with thousands of objects and actions).

In your case it would probably be easier to define what a regular user CAN do since by default the system will NOT allow a user to perform an action if it is not defined.

So if you define a rule that allows a regular user to view a standard post, by definition that same user will NOT be able to view anything else. So that rule would be really simple.

However to get to what you were asking you could create a domain called 'regular_user_not_viewable_objects' and add the corresponding objects to that domain, But it would really not be the best approach.

As a rule of thumb you always want to focus (or define) what a user CAN do. It is only when an object in a larger domain (or an action in a larger privilege) conflicts with the rule that you generally specifically exclude it. That is really the only time you would want to define negative rules. (Look at the first post and see how I define the rules for 'moderators'.)

Hope this helps.

Ben

From the examples in the first post I understand that domains and objects do not refer to domain models and business objects (as in the model layer of a MVC approach). So in order to determine whether a user can view a post I would create a postModel and translate its properties (such as being a draft, pending etc) to the objects defined in the RBAC system.

Am I right so far?