Opened 6 years ago

Last modified 6 days ago

#12952 new Cleanup/optimization

Models history doesn't use verbose names

Reported by: acangiano Owned by: nobody
Component: contrib.admin Version: master
Severity: Normal Keywords:
Cc: vvangelovski@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: yes


The history for a model object (within the admin section) should show human-readable messages, favoring verbose names over field names. However, this is not currently the case. For example, consider a model with the following class variable:

pub_date = models.DateTimeField("date published")

Changing the publication date for an object of that model, will display "Changed pub_date." in its admin history, rather than "Change date published." as one would expect (as older versions of Django did).

Attachments (2)

django-admin-history-verbose-name.diff (1.8 KB) - added by Alex 6 years ago.
Initial patch, probably needs tests.
admin_history.diff (4.0 KB) - added by vasiliyeah 4 years ago.

Download all attachments as: .zip

Change History (25)

Changed 6 years ago by Alex

Initial patch, probably needs tests.

comment:1 Changed 6 years ago by russellm

  • Has patch set
  • milestone 1.2 deleted
  • Needs documentation unset
  • Needs tests set
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 4 years ago by lukeplant

  • Type set to Bug

comment:3 Changed 4 years ago by lukeplant

  • Severity set to Normal

comment:4 Changed 4 years ago by vasiliyeah

  • Easy pickings unset
  • Patch needs improvement set
  • UI/UX unset

This patch can't be applied.

Version 0, edited 4 years ago by vasiliyeah (next)

comment:5 Changed 4 years ago by vasiliyeah

  • Patch needs improvement unset
  • UI/UX set

comment:6 Changed 4 years ago by vasiliyeah

  • Cc vvangelovski@… added

Changed 4 years ago by vasiliyeah

comment:7 Changed 4 years ago by vasiliyeah

  • Needs tests unset

Updated patch to apply to current trunk and added a test for the history view.

comment:8 Changed 4 years ago by julien

  • Triage Stage changed from Accepted to Design decision needed

Marking as DDN until an answer to ticket:14358#comment:3 is provided.

comment:9 Changed 4 years ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted

The objection was "for debug purposes, it would be more useful to have the field names, as they are necessarily unique, untranslated, etc."

In my opinion:

  • uniqueness is a weak argument: if you have two fields with the same name, you're just asking for trouble;
  • translation isn't an issue at all: in doubt, just switch the website to the default language of your codebase.

comment:10 Changed 4 years ago by aaugustin

#14358 is a duplicate and has patches too.

comment:11 Changed 15 months ago by timo

  • Patch needs improvement set

Patch will need to be updated to apply cleanly.

comment:12 Changed 5 months ago by agamdua

  • Patch needs improvement unset

A Github pull request (#4496) has been opened for this ticket.

comment:13 Changed 5 months ago by timgraham

  • Type changed from Bug to Cleanup/optimization
  • Version changed from 1.2-beta to master

I am thinking it might be best to try to address #21113 first (allow messages to be translated to the current language rather than displaying the language that was active for editing) since this ticket would require a new implementation for that one.

comment:14 Changed 3 months ago by timgraham

  • Patch needs improvement set

Left comments for improvement on the PR.

comment:15 Changed 3 months ago by RamezIssac

I think it's better to work with the form labels than fields' verbose name,

I think It's actually a more natural flow and more consistent if the label is different then the verbose name. (That's the idea behind the field label option, right?!)

My Approach would be to gather the changed fields' labels, then send it to get_text_list

translated_changed_fields = [form.fields[f].label for f in form.changed_data]
change_message.append(_('Changed %s.') % get_text_list(translated_changed_fields, _('and')))

#again for formset
for changed_object, changed_fields in formset.changed_objects:

    translated_changed_fields = [formset.forms[0].fields[f].label for f in changed_fields]
    #using formset.forms[0] looks ugly i agree , couldn't find better ways But hey , it's a changed formset , index [0] is there ! 
    change_message.append(_('Changed %(list)s for %(name)s "%(object)s".')
                                          % {'list': get_text_list(translated_changed_fields, _('and')),

Created a duplicate 24990


Last edited 3 months ago by RamezIssac (previous) (diff)

comment:16 Changed 2 months ago by timgraham

It seems to me that the verbose name is a safer choice to account for the fact that you might have several different editing forms each with a different label.

comment:17 Changed 2 months ago by RamezIssac

IMHO, that depend on the intended audience of the changed message in the history.
If it's the developer then verbose_name are the way to go.
If it's the site 'content' administrator, this is what i think is the case, then labels are more of expected behavior; and in that case the "maybe different" verbose name can be confused as a bug.

"I edited the field "More info", why does it show me that i edited 'description' which is not even present on the form ?"


Kind regards;

comment:18 Changed 11 days ago by RamezIssac

I see that this pull request didn't get merged.

I can go for it with the form label resolution.

comment:19 Changed 11 days ago by timgraham

After further consideration, I think that approach is okay.

comment:20 Changed 10 days ago by RamezIssac

PR created #5169

comment:21 Changed 9 days ago by timgraham

I left some comments for improvement on the pull request. Don't forget to uncheck "Patch needs improvement" on this ticket after you update it so it appears in the review queue, thanks!

comment:22 Changed 8 days ago by RamezIssac

  • Patch needs improvement unset

comment:23 Changed 6 days ago by timgraham

  • Patch needs improvement set

Some discussion on the mailing list confirmed my feeling that we should fix #21113 first.

Note: See TracTickets for help on using tickets.
Back to Top