Opened 8 years ago
Last modified 8 years ago
#29132 closed Bug
Incorrect update_last_login signal handler behavior when using custom User model with an arbitrary last_login attribute (not a Field instance) — at Version 1
| Reported by: | Mikhail Porokhovnichenko | Owned by: | nobody |
|---|---|---|---|
| Component: | contrib.auth | Version: | 2.0 |
| Severity: | Normal | Keywords: | last_login, update_last_login, signals, user_logged_in |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Please note! It's not a #26823 duplicate, and it's just an issue related this one.
In the current implementation, a signal handler connects with a user model when this model has a last_login field.
if hasattr(get_user_model(), 'last_login'): from .models import update_last_login user_logged_in.connect(update_last_login, dispatch_uid='update_last_login')
And it would work when there isn't a last_login attribute in the custom user model. But what if I've inherited my custom model from AbstractUser and dropped the last_login by setting it to None?
class User(AbstractBaseUser): last_login = None # Drop ``last_login`` field off
Technically, the model has a last_login attribute, but it's not a field!
Suggesting change the check condition something like that:
last_login = getattr(get_user_model(), 'last_login', None) if last_login is not None: # ...
or even
if isisintance(last_login, models.Field): # ...