I like this proposal because I am a big fan of a stripped down `User` model which is basically just an ID, whic provides a common hook into groups/permissions and other django and 3rd party profiles.
What I don't like is the magical `data` bag (accessing `User.data` and filter lookups), the new `AUTH_PROFILES` setting, and the idea of Django automagically or lazily creating profiles for me. I would rather see Django rely solely on its `OneToOneField` field to access user profile data. Any pluggable app (app1) will know what fields it's own profile model has and how to access them, relative to the central `User` object. If app1 relies on fields defined by another app (app2), that other app should be a requirement of app1 and app1 would know how to access app2's fields. I am happy to use project-level signals for everything else (syncing common profile data from app1 and app2, or auto-creating user profiles), because project-level signals give me explicit control over what is going to happen and when. I don't need any more magic here. Cheers. Tai. On Tuesday, 3 April 2012 10:35:41 UTC+10, Jacob Kaplan-Moss wrote: > > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. > > In essence, this does two things: > > * Vastly "prunes" the required fields on auth.user. The only things left > are an "identifier" (which could be username, email, url, uuid, whatever), > and a password. > * Introduces a new "profile" system that provides a way to contribute > extra related fields. Multiple profiles are supported, along with some > syntactic sugar for dealing with multiple profiles in a reasonably reusable > way. > > And that's about it. I'm deliberately trying to find a middle ground > between "do the minimum to allow people to move on" and "throw out and > rewrite django.contrib.auth entirely". I'm not expecting everyone to be > thrilled by this idea, but I'm hoping that this is "Good Enough" for almost > everyone. > > For more please see the document. Please do try to read the whole thing: > I've had a few rounds of feedback incorporated already, and there's even an > FAQ at the end. > > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I > very much want to hear feedback, objections, and alternatives. I'm > particularly interested in hearing from people who've got complicated auth > needs and think this absolutely won't work for them. > > I *have* reviewed all the other proposals and I'm between -0 and -1 on all > of them. This means that if you don't like my proposal, you'll probably > have to come up with a complete *new* idea to have any chance of getting my > vote. > > Thanks! > > Jacob > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/PMpcPCKgTuoJ. 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.
