Opened 12 years ago
Closed 11 years ago
#18460 closed Bug (fixed)
In admin, the history for model User shows always a change in password, although it is not changed
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.admin | Version: | 1.5 |
Severity: | Normal | Keywords: | admin, password |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Once a user is saved in django admin, and entry in the log is created.
When a field is changed, i.e the username, the history for that user shows:
"Changed password and username."
It shouldn't show password
Change History (7)
comment:1 by , 12 years ago
Component: | Uncategorized → contrib.admin |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 12 years ago
Has patch: | set |
---|
comment:4 by , 12 years ago
It is probably RFC, however, if we commit the patch attached to #16612 (waiting review), the _has_changed
method will move from widget to field.
comment:5 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:6 by , 11 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
Version: | 1.4 → 1.5 |
I'm still experiencing this issue when using a custom User model. If I comment out the line:
password = ReadOnlyPasswordHashField()
in my CustomUserChangeForm class, then saves with no changes are correctly logged with "No fields changed." However, then I'm able to see and edit the hash. Once the line is back in my code, every save results in a "Changed password." log entry.
comment:7 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This was fixed in 1.6, not 1.5 (if you look at the commit, you'll see it has 1.6 tags). Since you've set "Version" to 1.5, I'm assuming that's the version you are reporting this against -- please reopen if not. A test case for Django's test suite would also be extremely helpful if you believe there's still a bug here.
Indeed, this bug is trivial to reproduce. It probably has something to do with the new password hashing (or it may predate it).