I see that method **_check_list_display_item** of class
''ModelAdminChecks'' in module ''check'' of ''django.contrib.admin'' has
changed significantly between releases 2.0.6 and 2.1.3; in the latter, has
been removed the last branch (else) of the top-level if-elif-else
structure, although it was explicitly stated, in a comment inside it, that
the associated path was required.
I'm not able to make a complete diagnosis, but it seems that testing
{{{
hasattr(model, item)
}}}
in general gives a different result than testing the existence of the same
field with
{{{
model._meta.get_field(item)
}}}
In fact, using the ''manage.py shell'' command, I experimentally verified
such difference on a subset of the fields presenting the above mentioned
problem: the ''hasattr'' test yields sometimes True and sometimes False
(don't know why), while the other way of testing the existence of the
field always yields a True result.
--
Ticket URL: <https://code.djangoproject.com/ticket/29992>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by Tim Graham):
Please give a minimal sample project that reproduces the issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/29992#comment:1>
Comment (by Tim Graham):
Check if #29636 explains the cause.
--
Ticket URL: <https://code.djangoproject.com/ticket/29992#comment:2>
Comment (by gtoffoli):
In my view #29636 correctly identifies the commit at the origin of the
problem, but doesn't explain the cause.
My case is very similar but it involves only ''CharField'' and
''TextField'', not a field class I defined, nor, for example,
''IntegerField''.
And, as far as I can understand, these field classes haven't the
''__get__'' method at all.
An excerpt of my code follows
{{{
@python_2_unicode_compatible
class Repo(models.Model):
name = models.CharField(max_length=255, db_index=True,
verbose_name=_('name'))
description = models.TextField(blank=True, null=True,
verbose_name=_('short description'))
state = models.IntegerField(choices=PUBLICATION_STATE_CHOICES,
default=DRAFT, null=True, verbose_name='publication state')
...
}}}
{{{
class RepoAdmin(admin.ModelAdmin):
list_display = ('id', 'name', 'slug', 'description', 'repo_type',
'state', 'user_fullname', 'created', 'modified',)
...
}}}
and this is an excerpt of the error log:
{{{
<class 'commons.admin.RepoAdmin'>: (admin.E108) The value of
'list_display[1]' refers to 'name', which is not a callable, an attribute
of 'RepoAdmin', or an attribute or method on 'commons.Repo'.
<class 'commons.admin.RepoAdmin'>: (admin.E108) The value of
'list_display[3]' refers to 'description', which is not a callable, an
attribute of 'RepoAdmin', or an attribute or method on 'commons.Repo'.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29992#comment:3>
Comment (by Tim Graham):
I don't get a check error with the excerpt you provided. Please provide a
minimal project that demonstrates the issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/29992#comment:4>
Comment (by gtoffoli):
You are right. I created a new project for testing, starting with that
excerpt; then added some more stuff, without being able to reproduce the
problem.
I don't know what, in the real project, interferes with the creation of
admin classes. When I can, I'll keep adding stuff to the test project.
For the moment I will use a patched version of the admin.check module.
--
Ticket URL: <https://code.djangoproject.com/ticket/29992#comment:5>
* status: new => closed
* resolution: => needsinfo
--
Ticket URL: <https://code.djangoproject.com/ticket/29992#comment:6>