#8359 closed (fixed)
Adding a user in admin doesn't create a LogEntry for the addition
| Reported by: | evan_schulz | Owned by: | nobody |
|---|---|---|---|
| Component: | contrib.admin | Version: | dev |
| Severity: | Keywords: | ||
| 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
UserAdmin's add_view method doesn't call the log_addition method to create a record that the new user was created which means you'll get the incorrect message "object doesn't have a change history. It probably wasn't added via this admin site" when viewing the user history.
Attachments (2)
Change History (10)
by , 16 years ago
comment:1 by , 16 years ago
| milestone: | → 1.0 |
|---|---|
| Triage Stage: | Unreviewed → Ready for checkin |
comment:2 by , 16 years ago
comment:3 by , 16 years ago
FWIW there is a small patch in #8357 to get user creation working again for quick verification purposes
by , 16 years ago
| Attachment: | 8359choices.diff added |
|---|
Optional additional patch to fix object history display.
comment:4 by , 16 years ago
The 8359choices.diff patch fixes the problem whereby the object history displays no action when no change_message was specified. With this fix a default action description ("Added.", "Changed." or "Deleted.") is displayed based on the action_flag setting when change_message is not set.
follow-up: 7 comment:5 by , 16 years ago
The second patch should go into a new ticket and we can consider that after 1.0. It's a feature addition, since it restricts the choices on the actions available in the LogEntry model, which may or may not be what we want to do.
comment:6 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:7 by , 16 years ago
Replying to mtredinnick:
The second patch should go into a new ticket and we can consider that after 1.0. It's a feature addition, since it restricts the choices on the actions available in the LogEntry model, which may or may not be what we want to do.
This is a weak decision. First off, the bug as submitted is not entirely fixed without the second patch since the logentry for the user addition still does not show up as an addition in the object history. Second, the choices on the action_flag are already restricted to a SmallPositiveInteger. If you are seriously concerned about restricting the values, you need to change this to an IntegerField at the very least. Third, set theory suggests that the defined actions -- addition, deletion and change -- are all of the possible actions available for any object. There are no other choices that would not logically overlap the available choices. If you want to argue that set theory is incomplete and new types of state transitions that are not changes or additions or deletions may be discovered someday, then your comment is valid. Otherwise it simply perpetuates a wart that is trivially fixed as my patch demonstrates.
A bit hard to verify the fix until #8353 has been fixed. :-)