Hi, On Tue, Mar 20, 2012 at 2:05 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On 20/03/2012, at 8:00 AM, Ian Lewis wrote: >> Though we have had other times where there were multiple types of >> users in a single project. i.e. users that signed up via some >> affiliate program. username is unique so you wouldn't be able to use >> the same username across user account types etc. > > I can see the use case here, but it seems to me that this is exactly what > UserProfiles (or a denormalized User model with multiple auth options) should > be used for.
With user profiles you have one single user and username/email namespace whereas what I'm talking about are user namespaces and types that are completely separate from each other. Sure you *could* make everyone register once and then tack on user profiles based on what things the user is signed up for or whatever but it seems like something that the framework doesn't need to mandate. No argument against it being the recommended way to do multiple users though. > There's a very practical reason I say this -- If you have two separate user > models, aren't ForeignKeys a complete PITA? > > Lets say you have two different user types -- say, FacebookUser and > TwitterUser. Now, I create a comment model, and a comment has an Author which > is a User. How do I set up this foreign key? > > If FacebookUser and TwitterUser were set up as different subclasses/profiles > of User, then there's a common base class you can reference in a FK; but if > they're completely separate keys, you've either got to use > GenericForeignKeys, have two foreign keys every time you want to reference a > user, or maintain a third table that unifies the two user types. > > I feel like I must have missed something obvious here (either in your use > case or in your technical solution), because this seems like a pretty big > hurdle. Hmm, I'm imagining different types of users with orthogonal spaces rather than a two user types that can essentially do the same thing. I suppose the use case I'm trying to describe isn't encountered very often which is why it's hard to explain or visualize. If you had the kind of user you are describing there is no doubt you would have a user table and have profiles or a related model. This is part of the reason it's at the bottom of the list of features I described earlier (it was sorted by importance). >> Granted separation >> *may* be done by creating a whole separate project and isolating >> common code into a library but auth/admin is currently making it so >> you *have* to do it that way. > > One option is to allow auth to support multiple models, as you've done. > > A second would be to have a separate project, as you alluded to earlier. > > The third option would be to have multiple auth apps -- e.g., one for admin > users, and one for regular users. Yes, there's a configuration issue of > determining which auth app you want to use in different circumstances, but > that's going to exist anyway under your approach -- you're going to need apps > to know how to ask for the "right" User model. > > The problem I'm having with your newauth is that I'm not yet convinced that > the use case you present is enough to warrant adding a 'multiple user model' > capability to Django's base auth app -- especially if you can achieve the > same end by having multiple auth apps, or parallel projects. To my mind it's the least important of the tenets of the design of newauth, but I personally would like to use it at least for admin users and normal site users. The issue for me is that the functionality required of users of the admin will be different from users of the site itself. Part of the problem with the current auth is that it's forcing a number of fields and functionality on developers that isn't necessary for their site for the sake of the admin. This is probably my strongest argument and feeling for having multiple user models, at least as far as the admin is concerned. I just don't really see any reason why users on the site needed to share any data with admin users so I separated them and (would) made them different models (currently they are separated simply by the fact they are in different apps). >> I just think that the current auth app is mandating a certain way of >> doing things that it doesn't necessarily need to and most users just >> deal with it, in some cases bending over backwards, because they want >> to use auth's API. That's the way I've always felt. > > I'm in complete agreement that the bits like username and email > size/uniqueness are completely arbitrary, and should be user-configurable. A > base implementation needs to exist so that things work out of the box, but > nothing Django ships should be bound to that base implementation (or, if it > must be bound, then we need to make the case that it truly is universal, or > near universal -- e.g., servicing the "Hi <user>" requirement). There are a lot of issues to consider as well as how far we take this, but I'm of the mind that the username and email fields being on the user model in the first place is something that developers should be able to override. Though being able to override the fact that it's required/unique/too-small/too-big would be o..k. I can't imagine a good way to override the kwargs fro the fields without some ugly new setting but I'm sure you could come up with something. > I also agree that things like a permissions model shouldn't necessarily be > enforced -- although, again, a base implementation needs to be available so > that things like admin work out of the box. Agreed. I'm not sure I would have a good or concrete idea for how to make permissions work within the multi-user-model paradigm either. Though I can imagine some super-duper ACL system where you can stick permissions on anything or even something in-between that and the current permissions, but that's like *way* out of scope. > However, AFAICT, both of these concerns/limitations can be addressed in an > incremental fashion on the existing auth app. > The only part of newauth that *can't* be implemented as an incremental change > (AFAICT) is the multi-user model thing. I'm not convinced that this is a use > case or constraint that is affecting that many people in practice -- or that > it can't be addressed in better ways. Sure, I agree that devs will need to be able to upgrade Django with minimal fuss and and incremental approach with backwards compatibility is necessary. newauth is a reference proposal that didn't consider backwards compatibility or the needs of anyone but myself really so I knew that it wouldn't be accepted into Django as is if at all. I suppose if the base user fields are configurable then it would go a long way towards helping users -- Ian http://www.ianlewis.org/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
