Bryan wrote:
> My point is how do you lock the user out until he confirms his changed
> email address?
Ah, I had no idea you would want to do that, and can't see why you
would want to (the e-mail address that is stored is still correct), but
you know your requirements. But, you can always set i
I would prefer it if the first name and the last name are removed from
the User model, but it has no priority to me since you can leave them
empty.
IMHO these fields are not that common:
- sometimes the policy is to save initials + lastname (or any other
combination)
- in the Netherlands we also h
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote:
> Now that you've mentioned it, first_name and last_name should not even
> be in User. They should be in profile. Profile is for
> personalization, not for user specific login criteria like (is_active,
> is_staff, is_super
Ok, this is my last comment on the topic.
Now that you've mentioned it, first_name and last_name should not even
be in User. They should be in profile. Profile is for
personalization, not for user specific login criteria like (is_active,
is_staff, is_superuser, IS_APPROVED).
I'm ce
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote:
> I need their email to be verified at sign up and when they change it in
> their profile. I don't understand how this system would verifiy
> someone changing their email address.
Honestly, now that I've read through this more thoroughly, I think
what
My point is how do you lock the user out until he confirms his changed
email address?
Luke Plant wrote:
> On Tuesday 30 May 2006 19:58, Bryan wrote:
>
> > I need their email to be verified at sign up and when they change it
> > in their profile. I don't understand how this system would verifiy
>
On Tuesday 30 May 2006 19:58, Bryan wrote:
> I need their email to be verified at sign up and when they change it
> in their profile. I don't understand how this system would verifiy
> someone changing their email address.
I just implemented this in my system yesterday :-)
For an existing user
I need their email to be verified at sign up and when they change it in
their profile. I don't understand how this system would verifiy
someone changing their email address.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
,
> how are you doing it?
>
> On 5/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> > Bryan wrote:
> > > I strongly feel the need for an is_approved field in the User
> > > model (django.contrib.auth.models). This field would allow for
> > > user
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote:
> 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
ASP.NET's built in Membership system, which was I'm sure was thoroughly
thought out, has an IsAppproved field in addition to their IsLockedOut
(is_active) field.
>From a few of the emails I received, I'm not sure you all are seeing
the difference between is_active and is_a
But what if you want to verify someone's e-mailaddress *and* someone's
name? Then we need two of those fields. IMHO we should keep the User
model as simple as it is right now. If you want to add fields, you
should use model inheritance, but that's still on the to-do list, as
far as I know. The sub
Ok, i made a ticket for this (i thought that was probably a better
place for this): http://code.djangoproject.com/ticket/2033
Bryan wrote:
> 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
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. Some
14 matches
Mail list logo
