I would suggest not creating two tables. This falls into the domain of access control and I would recommend looking at Acl9 http://github.com/be9/acl9/tree/master
As for information pertaining only to clients or contractors, you could use a single User model and add contact details to it. Or you could go with straight table inheritance if phone numbers and addresses are all you need. On Apr 11, 11:29 pm, Nik <niks...@gmail.com> wrote: > Thanks for the help Philip. -- clients and contractor get their own > passwords for access to a project's home page. In the project's home > page, a few things can be done by both clients and contractors and > other things only one or the other party can do. And these 'things" (I > am terribly sorry to have to hide them) they do are stored in several > other tables. Hence my thought of using the authenticate + authorize > (users/roles/rights) system from Rails Recipes. But then those sort of > solid info like address, phone #1, phone #2, #3, ..., e-mail #1, > #2, ..., and preferred payment column, sort of things only apply to > either clients or contractor. So I was confused what to do about these > columns. > > So you would suggest a client table and a contractor table. > > Thank You! > > On Apr 10, 3:59 pm, Philip Hallstrom <phi...@pjkh.com> wrote: > > > Not knowing too much about your application, it sounds like the *only* > > things that a client and contractor really share is a username and > > password. Ignoring the "address" for a moment (as you could just > > create an Address model) it seems like you might have a lot of reasons > > for creating completely separate models: Client and Contractor. > > > Assuming this is some sort of PM system I imagine the things they can > > do and the properties they have will pretty different. > > > On Apr 10, 2009, at 3:42 PM, Nik wrote: > > > > Hello All, > > > > I have a User Model at the moment that has only username, password, > > > and roles. As you might guess, I can add to the User Model a phone > > > column which our clients have and our contractors also have. Many > > > other attributes may be share by both actually. But then only a client > > > can have a "rate" column, and a company association and other things. > > > And only a contractor can have, say, an internal FTP login/password > > > pair. > > > > I don't quite know the nature of rules on deciding just how I should > > > do about these un-shared attributes, I know that I use the "roles" > > > column to differentiate a client and a contractor (learned from Raile > > > Recipes); should I pool all attribute into User Model anyway and then > > > find a mechanism to permit/forbid a client to see the contractor only > > > attrib and vice versa? or two other tables one being > > > contractor_only_properties and the other client_only_properties? I > > > feel that having to build a table for each role seems a bit, I am very > > > unlikely to be right, inflexible or at least un-easily-extensible > > > (sorry for making words like this). > > > > Your (any) opinion is very valuable to me and I thank you for spending > > > your time reading my problem > > > > All my best, > > > Nik > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
