0

I'd like the default value for new users' is_active to be False. Is there any way to so that prior to creation? Currently I'm using form_valid to set it on form.instance in my registration view but it seems like there would be an admin setting or something.

meteorainer
  • 913
  • 8
  • 21
  • Unregister User and register you modifications, see: http://stackoverflow.com/questions/2270537/how-to-customize-the-auth-user-admin-page-in-django-crud – yuvi Dec 28 '13 at 18:30
  • actually, it might not help you, as the default value is initiated at model level and not form level, see my answer for details – yuvi Dec 28 '13 at 19:49
  • Is the form written by you or is it a 3rd party form? – Arpit Dec 28 '13 at 20:49
  • @Arpit It's my form, so no problem with using form_valid(), it just seems like it's an extra overhead during user creation that might be avoided by setting a default in the model itself. – meteorainer Dec 29 '13 at 01:34

1 Answers1

1

After reading into the source code a bit, it seems like is_active is part of the AbstractBaseUser and not even as a field, here's direct code excerpt:

class AbstractBaseUser(models.Model):
    # ...    
    is_active = True

It's only later that is_active is turned into a field through another model called AbstractUser:

class AbstractUser(AbstractBaseUser, PermissionsMixin):
    # ...
    is_active = models.BooleanField(_('active'), default=True,
        help_text=_('Designates whether this user should be treated as '
                    'active. Unselect this instead of deleting accounts.'))

The User class itself defines almost nothing, really... This whole setup is sursprisingly convoluted, so I think there's no simple way to do it (unless you want to change the source code, which isn't recommended at all). using form_valid sounds like the best approach here.

yuvi
  • 18,155
  • 8
  • 56
  • 93
  • I am actually using AbstractUser as my base for my own user object. Unfortunately attempting to override existing fields in my user generates a field clash error, so that's a no go. – meteorainer Dec 29 '13 at 01:32
  • Sounds like you should use AbstractBaseUser as your base instead. It would prove more flexible and independent, and it's also what the [documentation recommends](https://docs.djangoproject.com/en/dev/topics/auth/customizing/#specifying-a-custom-user-model) – yuvi Dec 29 '13 at 12:21
  • I started writing that way, but proved to be a pain. Had to rewrite existing functionality in the manager to change this one setting. – meteorainer Dec 30 '13 at 13:01