Hmm, your right. We are a small student corporation, so we don't need many groups (though we have quite some commissions, about 26 for 230 members).

Now I've thought about this system for some time, and my cms has a modular structure. It's build only with plugins, so I thought the relation domains -> plugins isn't that hard.
Another thing is the object relation. Each plugin can have several objects, but I don't want to store all the objects from all plugins into one table. Then my modular system is going to be completely messed up.
Is there a solution to have a table for every plugin? E.g. my gallery has tables plugin_gallery_categories, plugin_gallery_albums, plugin_gallery_photos and plugin_gallery_reactions.

Do you think, is it alright to create an additional table "plugin_gallery_objects", which replaces the complete rbac_objects and rbac_domain_has_objects table structure?
I think the queries are harder to create with this solution, but couldn't think of another. Of course, it is still possible to store the objects into a seperate object table and create a plugin_has_object table, but don't think that is a clean solution. What do you think?

Thanks for your (previous and upcoming) advice!

I am not sure what you want to achieve but I don't think it will mess things up if you store all the information in one table.
What actions are you thinking of using on the objects?

OK I see what you mean now... :-)

I would give the domains and objects relevant names like:

Domain: plugin_gallery_categories
Object: pgc_nature
Object: pgc_city
Object: pgc_people etc...

Domain: plugin_gallery_albums
Object: pga_2007
Object: pga_2006 etc...


For the photos and reactions I don't see the need to create specific objects. I would leave the domain singular. (i.e the domain and the object would have the same name.)

Having said that you may want to create some objects based on the user who uploaded the photos.
i.e.

Domain: plugin_gallery_photos
Object: pgp_username1
Object: pgp_username2

This would allow you to control what other members are allowed to do with other members photos. (I.e. leave comments, delete, rename, view, etc...)

[/quote]Do you think, is it alright to create an additional table "plugin_gallery_objects", which replaces the complete rbac_objects and rbac_domain_has_objects table structure?

[/quote]You understand your problem better than I do, so it is hard for me to make a comment. At this stage I don't see the need to change the structure of the database,... but I may be wrong ;-)

The whole idea behind sharing this RBAC structure with the community and releasing it under the MIT license is to allow people to improve and change it to meet their needs. Once you get the general idea of how it works you can customise it as much as you like.

I think this may be messy. Are the comments I wrote above of any help?

Let me know if what I wrote makes any sense to you. It is hard for me to really comment on your structure because I am not 100% sure of what you want to do.

Cheers,

Ben

Hi I was involved in a project designing a desktop and laptop deployment tool. One issue was always to assign the correct user rights for web pages and menu entries. I saw your post one year ago and I'll try to implement it in MS SQL 2005/ASP.NET.


Keep you informed if I'll make progress. By the way GREAT Article.

Cheers
Joachim

Hi Trash,

If you have any questions, post them here on the forum.
Glad you liked the article... at least I know someone found it worth reading ;-)

Cheers