Quote:
Originally Posted by mithras
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.
|
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?
Quote:
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.
|
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.
Quote:
I think the queries are harder to create with this solution, but couldn't think of another.
|
I think this may be messy. Are the comments I wrote above of any help?
Quote:
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!
|
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