Opened 18 years ago

Closed 18 years ago

Last modified 17 years ago

#2033 closed defect (wontfix)

is_approved

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

Description

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)

  1. A setting in settings.py:

LOGIN_REQUIRES_APPROVAL = True

Change History (9)

comment:1 by Esaj, 18 years ago

Couldn't is_active be used for the same purpose?

comment:2 by Adrian Holovaty, 18 years ago

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 by James Bennett, 18 years ago

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 by germish@…, 18 years ago

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 by germish@…, 18 years ago

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

Resolution: wontfix
Status: reopenedclosed

Won't fix.

comment:7 by James Bennett, 18 years ago

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 by Home, 18 years ago

Type: enhancementdefect

comment:9 by Gary Wilson, 17 years ago

(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.

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