On Mon, Oct 19, 2009 at 11:52 PM, Hanne Moa <[email protected]> wrote: > > It doesn't look like Contrib-06, covering ticket #3011, Allow for > extendable user module, will be in for 1.2. So: let's think afresh, > start from scratch, think about what we really, really want. This is > my pony for *2.0*:
I completely agree that we need to do something about #3011. If you look at the voting, I'm +1 in favour - with the caveat that the most recent patch on #3011 is *completely* the wrong approach. However, the time has really past for big ticket discussions for v1.2, and it certainly isn't the time to talk about ponies for v2.0. We've just been through a 3 month process of discussing features, and this discussion process consumes a lot of time. At some point, we (the community) need to stop talking about features and start implementing them, and we (the core team) needs to start integrating the work that the community develops. That point is essentially now. I don't want to dampen your enthusiasm here - I think this is a _very_ important problem, and your analysis covers many of the reasons why I think this ticket is important, and the use cases that we need to capture with any potential replacement. I just want to point out that now isn't the best time to start an abstract discussion about big changes. Personally, I think you're on the right path - I think auth.User needs to become a barebones model that is essentially just a primary key, some datestamps for last login and last modified, and m2m relations with permissions. Authentication should then be against a profile-style model; calls like user.get_full_name should be deferred to the information provided by the auth profile. One of the big problems that needs to be solved that you haven't addressed is the migration path. Obviously, we can't just replace the current auth.User model - we need to have a migration plan for all existing users of contrib.auth. I have some ideas on how this could be done, but I'd be interested in hearing what others come up with. There are also complications with integrating with admin that need to be worked through. So, if you want to play around with ideas in this space, I encourage you to do so. Having a working implementation of an alternative auth module would be a good starting point for discussions when we make the call for proposals for v1.3. If you need feedback on a design issue you confront, django-developers is still the right place to ask. However, I want to moderate your expectations regarding the level of intense design discussion that the core will be able to engage in while simultaneously working on v1.2. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
