Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#2033 closed defect (wontfix)


Reported by: germish@… Owned by: adrian
Component: Contrib apps Version: master
Severity: normal Keywords: User model is_approved
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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:


  1. A setting in


Change History (9)

comment:1 Changed 9 years ago by Esaj

Couldn't is_active be used for the same purpose?

comment:2 Changed 9 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:3 Changed 9 years ago by ubernostrum

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.

comment:4 Changed 9 years ago by germish@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:5 Changed 9 years ago by 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)?

comment:6 Changed 9 years ago by adrian

  • Resolution set to wontfix
  • Status changed from reopened to closed

Won't fix.

comment:7 Changed 9 years ago by ubernostrum

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.

comment:8 Changed 9 years ago by Home

  • Type changed from enhancement to defect

comment:9 Changed 8 years ago by gwilson

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

Note: See TracTickets for help on using tickets.
Back to Top