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 possibl
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
> that require
Ivan Sagalaev wrote:
> You are looking for undocumented "follow":
>
> class MyManipulator(MyModel.ChangeManipulator):
> def __init__(self, id):
> MyModel.ChangeManipulator.__init__(self, id, follow={
> 'my_text_field': False,
> 'my_date_field': False,
>
Luke Plant wrote:
> However, I had
> problems. But I've forgotten what they were now
I remembered what my problem was:
Manipulator.get_validation_errors() ignores the 'follow' parameter, so
you get validation errors for fields that aren't included. Also, it's
not simple to strip them out, sin
On 30/05/2006, at 4:43 PM, Shaun Cutts wrote:
>
> Ian,
>
> Thanks. Your code looks concise, but a bit mysterious (maybe it's
> the time
> of night). Is this a way to get extra events triggered in a db
> transaction,
> or is it just inside a single web request?
>
just inside a single web requ
Luke Plant wrote:
>Manipulator.get_validation_errors() ignores the 'follow' parameter, so
>you get validation errors for fields that aren't included.
>
Just tested it and it shows that you don't. I have a required field
switched off with "follow" that is not in the form. It doesn't give an
erro
Luke Plant wrote:
> Also, 'follow' is sub-optimal -- you have to calculate (either by hand
> or automatically) the fields that you want to *exclude*, rather than
> pass in simply the ones you want to include. Maybe some utility
> function on AutomaticManipulator might help.
Here's my version ...
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
Ivan Sagalaev wrote:
> Luke Plant wrote:
>
> >Manipulator.get_validation_errors() ignores the 'follow' parameter, so
> >you get validation errors for fields that aren't included.
> >
> Just tested it and it shows that you don't. I have a required field
> switched off with "follow" that is not in
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_approved. An email
verif
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
> their account is click
Has anyone tested out the multi-auth branch yet? I haven't heard
anything, so either people aren't using it, or it's working well and
the docs are good enough. Personally, I've been using it with both
external SQL and LDAP backends for over a month now. No issues, but my
apps are internal and don'
I mistakenly sent a reply to Bryan instead of the group, and here is my
reply to Brian's reply:
On Tuesday 30 May 2006 18:43, Bryan, wrote:
> And do you use is_active = True in your verification view to give the
> user access to his account? If so, please read my new post. If not,
> how are yo
On 05/30/06 20:33, Joseph Kocherhans wrote:
> Has anyone tested out the multi-auth branch yet? I haven't heard
> anything, so either people aren't using it, or it's working well and
> the docs are good enough. Personally, I've been using it with both
> external SQL and LDAP backends for over a mon
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
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
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 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
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 certain this i
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_superuser, IS_APPROVED).
My perso
Ilias Lazaridis wrote:
> After reviewing the relevant source code base a little, I have started
> with the implementation of the schema evolution skeleton (which will
> contain a functional "Add Field" support).
>
> http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution
>
> With a very sma
Ivan Sagalaev wrote:
> gabor wrote:
>
>> i'm also willing to help with this task... but..do i understand this
>> correctly, that it's agreed that django is going to switch to unicode?
>>
>>
> Being one of the proponent of the all-unicode way back when it was
> proposed I should say that the m
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/31/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> Has anyone tested out the multi-auth branch yet? I haven't heard
> anything, so either people aren't using it, or it's working well and
> the docs are good enough. Personally, I've been using it with both
> external SQL and LDAP backends
> It would be nice if I could have an answer on this, thus I can avoid
> redundant effort.
Perhaps there would be more confidence in your efforts if it:
a) Wasn't making someone else's work redundant
b) Came from some detailed design
c) Worked on all databases before being checked in
If you pos
oggie rob wrote:
>> It would be nice if I could have an answer on this,
>> thus I can avoid redundant effort.
>
> Perhaps there would be more confidence in your efforts if it:
> a) Wasn't making someone else's work redundant
> b) Came from some detailed design
> c) Worked on all databases befor
Thanks everyone for the ideas, I've updated the wiki page. Please take
a look if you have a moment and let me know.
Thanks,
Chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
Joseph,
On 5/30/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> Has anyone tested out the multi-auth branch yet? I haven't heard
> anything, so either people aren't using it, or it's working well and
> the docs are good enough. Personally, I've been using it with both
> external SQL and LDAP
Ilias Lazaridis wrote:
> After reviewing the relevant source code base a little, I have started
> with the implementation of the schema evolution skeleton (which will
> contain a functional "Add Field" support).
>
> http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution
>
> With a very sma
gabor wrote:
>>Using this convention
>>one can write international apps without worries since all messy things
>>are made inside the framework.
>>
>>
>
>well, i would replace 'without worries' with 'good enough' :)
>
>
Ok :-)
>for example, i was building a very simple web-file-manager. y
30 matches
Mail list logo
