On Sun, Sep 16, 2012 at 8:15 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On 16 syys, 02:15, Russell Keith-Magee <russ...@keith-magee.com> > wrote: > Creating an admin class for no-added-fields extended user model is > somewhat straightforward, although the admin forms currently assume > the auth.User as the base user. I did a little hack to make it easier > to use these forms, see commit: > https://github.com/akaariai/django/commit/04ae5183df8613fd0d91b43834a4582fdf6b0d04 > - but I am not totally happy about this approach. If you use an > AbstractBaseUser derived user model, these forms aren't actually > usable. > > Creating an admin class for added fields model is also somewhat easy, > you just need to play with UserAdmin.fieldsets to have the additional > fields actually present in the edit form, and you need to make your > required fields "blank=False, null=True", so that the two-stage user > creation works correctly.
I'll take a closer look at this patch; however, see my comments below about admin integration. > Some additional findings: > - The get_by_natural_field() manager method has a bug: getattr(self, > 'USERNAME_FIELD', ...) should be getattr(self.model, > 'USERNAME_FIELD', …) Good catch - I've just pushed a fix. > - Do we want to future-proof some of the interface methods by adding > **kwargs to the method signatures? At least has_perm / > has_module_perms seem like possible candidates. I'm not convinced by this -- at least, not for the permissions methods. The API for module permissions isn't a new invention -- it's something that's been part of the auth backend API since pretty much day 1, and the only modification that has been required is to support object permissions. If there's any other API where you think there's room for expansion, I'm open to discussion. > I wonder if we want to do something about allowing easier password > handling in (admin)forms for custom user classes. Currently making an > admin class for your user class is somewhat hard - you need to either > dig out what auth.admin does for the password field or reinvent it > yourself. > > In total this is looking really good, but I can see the need to do > additional polish for some time. Maybe we could take a somewhat > relaxed approach to what constitutes a feature addition when it comes > to this feature? To me it seems there might be something we want to do > about the password forms for example. But, I am not sure we can get > that something done about this by the end of month... We could easily hold up this patch on making the admin forms completely flexible for all possible user models. However, for my money, we still have a couple of months to nail down any problem areas in the API, and we'll get more benefit from having this in the trunk repo and getting more eyeballs looking at it than we will from endlessly polishing behind the scenes aiming at some Platonic ideal. However, that said -- even if we don't make any significant changes between now and 1.5 final, it's now *possible* to write and use a custom User model that is compatible with admin. That's the big step IMHO, and the piece that needs to land for the alpha. We can continue to improve forms and documentation until the 1.5 release, and we can continue to improve post-release. I'm not denying that there is room for improvement, but the problems you're talking about are on the scale of "making difficult things easier", not "making impossible things possible". Russ %-) -- 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.
