I’m writing an application which will allow local chapters of a larger organization to do stuff. Many of the volunteers of this organization work with multiple chapters in different capacities at each… for instance, a person could be the treasurer of one chapter, and just a member/volunteer at another chapter, and a past member of another chapter. The club landing page will allow the chapter’s treasurer to do things that the same member, as a volunteer for another chapter, cannot.
I’m considering creating a table like so to allow for this:
tbl_chapter_user_group
user_id
chapter_id
group_id
Where group_id is the id of access at the chapter level, e.g. "chapterAdmin," "chapterTreasurer," "chapterVolunteer," etc.
Does this sound like a sound way to go about what I’m looking at doing or is there perhaps a better “best practice” way of going about this?
I’m not certain how you’re suggesting RBAC would fit the bill here. A single user would have different roles dependent on the chapter they were working with at any given time. In other words, they would have a role of “treasurer” in one chapter’s dashboard and one of “volunteer” in another chapter’s dashboard. The “treasurer” role would allow that user to, say, access financials. But, we don’t want that same user to be able to access the financials of the chapter he is only a volunteer for, but we still want him to be able to, say, sign up for volunteer hours.
So, I need to be alter a user’s role based on the chapter they are accessing. I’m not sure I understand how you’d do that with RBAC. Is this a job for business rules… if so, wouldn’t I still need the additional table?
So I’ve been through all the documentation for a second time thinking maybe I was just missing something the first time through it and still can’t find anything showing how RBAC will handle what I’m trying to do without an additional lookup table. Is this pretty much how this community works? Send members to documentation pages which don’t really address the question?
You might take a look at the RBAC implementation in the ‘user management module’. It uses a groups table for special interest groups and a pivot table to handle membership in multiple groups at the user table level. I believe it is close to what you want but might not go far enough.
The RBAC schema on sqlrecipes.com is probably closer to what you need. It should not be too difficult to extend the existing Yii code to handle this because the database relationships between domains/objects and privileges/actions in that schema are similar. A domain could be a chapter and an object could be something like a module. You might need to add a chapter table anyway possibly to handle differences among the various chapters (different layouts, different module or portlet sets, etc.).