What `User.is_active` really means
John-Scott Atlakson
There was a separate earlier changeset [3] related to this ticket that changed the inline help text from "Designates whether this user can log into the Django admin." to "Designates whether this user should be treated as active."
The comment on the ticket says "Nothing in the User model or login path enforces is_active (which is a good thing)".
There is at least one enforcement of 'is_active' in django.contrib.auth.forms.AuthenticationForm [4] and the admin 'staff_member_required' decorator also checks this value.
From my perspective it seems that the default behavior would be to in fact have all the django.contrib.auth functionality take this flag into consideration where appropriate. I'm just not seeing why we would want the default behavior to allow `user.is_active = False` to login, reset their password, etc.
I had opened a ticket a couple of weeks ago [5] with a patch so that at least password_reset would not send an email to accounts that were `is_active = False`. It appears the only way to limit use of the `django.contrib.auth.views.password_reset*` views to "user.is_active = True" would be to use wrapper views (or start stacking decorators). But this seems an unnecessary extra step when we are encouraged to use `is_active` instead of deleting users.
Clearly, I'm missing why this is a 'good thing'. But since Malcolm usually knows what he's talking about, I'll assume I'm the one missing something here. Clue-stick me, please and thank you.
Cheers,
John-Scott
[1] http://code.djangoproject.com/changeset/9176
[2] http://code.djangoproject.com/ticket/7011
[3] http://code.djangoproject.com/changeset/7414
[4] http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/forms.py#L81
[5] http://code.djangoproject.com/ticket/9213
Malcolm Tredinnick
Firstly, I was attempting documenting the existing behaviour, nothing
more. I wasn't intending to document every single use of is_active
within Django; the idea was simply to indicate that it wasn't the same
as "can login" and I didn't want the documentation of the edge-cases
(every single use of the function) to overwhelm the substance of the
feature.
If I've missed a case where it is used on the login path or something,
please file a patch to amend that. Accurate documentation is a good
thing. Incorrect documentation is a bug.
With respect to changing the behaviour: we can't really change is_active
to mean cannot_login now, since that would not be backwards compatible
and would be hard to detect for existing sites. Something that
previously worked would stop working without any kind of error message.
So that's not really an option. Being allowed to login to do some
minimal thing (such as confirm an account) which then sets your account
to active isn't an inconceivable way of handling account registration or
re-activation.
Adding new things that depend on is_active is probably reasonable.
Whether sending password email is one of them is something I haven't
thought about yet (particularly as to how it ties into the "you have a
very restricted account until we make it active" style of use). But
making it equivalent to 'cannot login' is not something I'd be in favour
of.
Regards,
Malcolm