Django

Code

Ticket #2033 (closed: wontfix)

Opened 4 years ago

Last modified 2 years ago

is_approved

Reported by: germish@gmail.com Assigned to: adrian
Milestone: Component: Contrib apps
Version: SVN Keywords: User model is_approved
Cc: Triage Stage: Unreviewed
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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)

2. A setting in settings.py: LOGIN_REQUIRES_APPROVAL = True

Attachments

Change History

05/30/06 03:38:56 changed by Esaj

Couldn't is_active be used for the same purpose?

05/30/06 08:57:57 changed by adrian

  • status changed from new to closed.
  • resolution set to wontfix.

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.

05/30/06 09:00:33 changed 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.

05/30/06 12:46:12 changed by germish@gmail.com

  • status changed from closed to reopened.
  • resolution deleted.

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.

05/30/06 12:55:55 changed by germish@gmail.com

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)?

05/30/06 13:21:16 changed by adrian

  • status changed from reopened to closed.
  • resolution set to wontfix.

Won't fix.

05/31/06 06:27:09 changed 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.

06/12/06 05:28:25 changed by Home

  • type changed from enhancement to defect.

01/27/08 23:36:45 changed by gwilson

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

Add/Change #2033 (is_approved)




Change Properties
Action