Opened 17 years ago

Closed 17 years ago

Last modified 16 years ago

#2033 closed defect (wontfix)


Reported by: germish@… Owned by: Adrian Holovaty
Component: Contrib apps Version: dev
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: no UI/UX: no


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 17 years ago by Esaj

Couldn't is_active be used for the same purpose?

comment:2 Changed 17 years ago by Adrian Holovaty

Resolution: wontfix
Status: newclosed

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 17 years ago by 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.

comment:4 Changed 17 years ago by germish@…

Resolution: wontfix
Status: closedreopened

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 17 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 17 years ago by Adrian Holovaty

Resolution: wontfix
Status: reopenedclosed

Won't fix.

comment:7 Changed 17 years ago by 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.

comment:8 Changed 17 years ago by Home

Type: enhancementdefect

comment:9 Changed 16 years ago by Gary Wilson

(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