is_approved

[germish@…]

I strongly feel the need for an is_approved field in the User model (django.contrib.auth.models). This field would allow for user systems that require email verification, user systems that require subscriptions/payment, etc...

Checking for is_approved at login should be an option. Here are ome possible solutions, which would both allow for optional approval and backwards compatibility:

1. A modified login_required decorator:

@login_required(approval=True)

2. A setting in settings.py:

LOGIN_REQUIRES_APPROVAL = True

[Esaj]

Couldn't is_active be used for the same purpose?

[Adrian Holovaty]

Won't fix. To do this, just create a separate TemporaryUser model and save unapproved users in there. Then, when they're approved, make them official User objects.

[James Bennett]

I'm with Esaj in thinking is_active is a better fit than a new field. Also a better fit than any sort of temporary model; just set things up so the user's account isn't active until they confirm it or give the secret handshake or whatever.

[germish@…]

ASP.NET's built in Membership system, which I'm sure was thoroughly thought out, has an IsAppproved (is_approved) field in addition to their IsLockedOut (is_active) field.

I'm not sure you all are seeing the difference between is_active and is_approved. An email verification system works by locking out a user until that user has verified their email address by clicking on a link. If we implement that verification view by having it turn on is_active (is_active = True) instead of using is_approved, then we can never explicitly make our users inactive, because all they would have to do to reactivate their account is click their email verification link. Thus we need to separate the two, having an is_approved field in addition to the is_active field.

[germish@…]

Oh, and the problem with using a TemporaryUser object is how do you handle someone changing their email address after they've registered? What would deleting or moving the User object to TemporaryUser do to all of that User's posts (the author FK of post)?

[Adrian Holovaty]

Won't fix.

[James Bennett]

Per discussion of this on the mailing list, I'm now advocating a user profile class as the best way to do this; that's the standard, built-in way to manage any addiitonal attributes you need on users.

[Gary Wilson]

(In [7040]) Fixed #6354 -- Fixed url in django/conf/urls/shortcut.py to work with non-integer primary keys (refs #2033) and made use of the URL file in the admin urls.