Right. The user has a single rank. I’m actually going to have to rethink
this though, as I may want to add users to multiple roles at certain
ranks. So now I’ll have to break this out into another table.
This is for a martial arts site. When someone gets to a particular rank,
they’ll be added to a role for that rank. Certain ranks (black belt and
fifth degree black belt) will also get other roles(namely access to an
additional forum, and forum moderating privilages). Essentially, their
rank will be specified as the highest rank that they have earned. They
will also have all the roles associated with the ranks below that one.
Does that make sense?
[email protected] wrote:
Can you clarify:
As far as I can tell, you’re saying that a user (which does not exist
yet) may have a single rank. Implicit in a set of ranks is a role.
Without knowing the context and business problem that you are trying to
solve, this seems backwards to my entire experience.
Generally I think of rank and role as being either independent, or
For example, “sergeant” is a rank, whereas “quartermaster” is one of
many roles that can be fulfilled by sergeants or other ranks. Another
example is a rank of “1st degree black belt”, with a role of
“instructor”, where instructor is one of many roles that may be filled
by a 1st degree black belt or other black belt ranks.
Your model seems odd to me also in that one user is only permitted to
fill one role and rank. I can’t fill the roles of both quartermaster
and instructor, or hold both the ranks of sergeant and 1st degree black
user HABTM role via table roles_users (what roles the user fills)
user HABTM rank via table ranks_users (what ranks the user holds)
rank HABTM role via table ranks_roles (allowed rank/role relationships)
At worst, it will give you more flexibility than you need but
sufficient information to allow edit checks against the ranks_roles
relationship to enforce your particular paradigm. At best, it may
resolve problems that you have not yet anticipated.
Unless users pick a role, the set of roles will remain empty. For
practical purposes, this is the same as the relationship being nil.
Under your proposed model, you do not need to do anything because,
until you assign a role, the role ID is nil.
Will G. wrote:
- I know I need to set up the relationships in the entities, but I’m still not clear on how to do it correctly to make this work. I would assume that Role has_many ranks, and rank belongs_to one role. Would that be correct?
I’ve created a pair of entities:
Someone can be added to a role all on their own. Being set to a
particular rank will automatically add them to the role (at least
eventually - I don’t have a user class yet, so it’s gonna be a while).
Anyway, rails was smart enough to pick up on the fact that Rank.role_id
is a reference to the roles table. It did not, however, add anything on
the default view for it.
What I’d like to do is the following:
Enable the user seeing the view to select a role by name, if they
want to do so. Otherwise, I would like for the value to remain nil. This
is the part that I imagine is difficult.
I know I need to set up the relationships in the entities, but I’m
still not clear on how to do it correctly to make this work. I would
assume that Role has_many ranks, and rank belongs_to one role. Would
that be correct?
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail.
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2Â¢/min or less.