You should make it so you're always working from a User object, and a User will have a "type", that can imply a certain group in the security system, and it can also imply a relationship between User and that "Type" class. You could also then setup some magic between the User and the "type" model to share properties so that if the Admin user type model has a property named "some_column", then you could access it via $user->some_column, or $user->getTypeRecord()->some_column.
http://www.doctrine-project.org/blog/using-behaviors-to-share-relationship-properties User hasOne Type UserType hasMany User as Users based on the User->Type then User would then have relationships setup to the type classes. User hasOne AdminUser AdminUser hasOne User AdminUser contains the foreign key back to User. The getTypeRecord() method would return the proper user type record based on the type of the user. - Jon On Tue, Apr 21, 2009 at 7:41 PM, Richtermeister <nex...@gmail.com> wrote: > > Hey Jon, > > thanks for your reply. > yeah, that sounds right as far as permissions are concerned. I'm > pretty sure those are flexible enough to acomodate my needs. > > What I am more concerned with is where I would store the extra fields > for each usertype.. > a customer would have different fields than say, and admin, or > whatever other usertype I might think up later on.. > > I'm thinking I could store those in separate models and access them > via $user -> getProfile() which would return the appropriate model, > based on what usertype is currently logged in.. I'm just concerned > that by doing that I would confine the areas each usertype would be > able to move in, since some parts of the app would be expecting a > customer object, and others an admin profile.. > Any thoughts on that? > > Thanks, > Daniel > > > > On Apr 21, 3:35 pm, Jonathan Wage <jonw...@gmail.com> wrote: > > The user type you speak of is a "group", and each group has a set of > > permissions. These permissions get turned in to credentials for the user. > > So, you create a list of permissions, locking down each individual piece > of > > your functionality. Then you can create groups that give user access to > some > > permissions. Granting them access to the functionality the permission is > > wrapped around. > > > > - Jon > > > > > > > > On Tue, Apr 21, 2009 at 5:16 PM, Richtermeister <nex...@gmail.com> > wrote: > > > > > Hi all, > > > > > I am working on a somewhat large multi-site cms setup (which is a > > > breeze with symfony's configurability), and I am wondering how much I > > > should tie my user-administration around the sfGuardPlugin. I have had > > > great experience with it when it comes to single usertypes (admins for > > > example), but in my current project, I will have admins and clients > > > (at least, possibly others). > > > So, one way I consider is to use the plugin to just manage general > > > userinfo (username & password) and access control (credentials), and > > > depending on the usertype, link either a customer model or an admin > > > model to the general userobject, via a getProfile() method or > > > something.. > > > > > One caveat might be that "ideally" I'd like the administrators to be > > > able to assume client roles, so they can look at things from the > > > client perspective.. but it's probably enough to just auto-login as a > > > client and keep the session namespaces different between the > > > applications.. > > > > > Either way, that's where' I'm at. Any experience with multi-users > > > sfGuardPlugin out there? > > > > > Thanks for your time, > > > and have a great day. > > > > > Daniel > > > > -- > > Jonathan H. Wage > > Open Source Software Developer & > Evangelisthttp://www.jwage.comhttp://www.doctrine-project.orghttp:// > www.symfony-project.org > > > -- Jonathan H. Wage Open Source Software Developer & Evangelist http://www.jwage.com http://www.doctrine-project.org http://www.symfony-project.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
