Admin views in admindocs crash with AttributeError

[Markus Holtermann]

When using django.contrib.admindocs the views under the admin namespace are not available. With the exception of /admin/<app_label>/<model>/<var>/ and /admin/r/<content_type_id>/<object_id>/.

Django 1.9.8 returns a HTTP 404 while 1.10 raises an attribute error. It appears that only views that are defined as methods on a class are an issue.

This is likely related to #24931 and #23601.

[Tim Graham]

Bisected the change in 1.10 to 31a789f646d0d9af3e8464f2f9a06aa018df5f90.

[Helen Sherwood-Taylor]

I'll have a look at this.

[Helen Sherwood-Taylor]

The problem is that the callbacks for these views are methods on classes.

For those two links that do work:
/admin/r/<content_type_id>/<object_id>/ view function is django.contrib.contenttypes.views.shortcut
/admin/<app_label>/<model>/<var>/ view function is django.views.generic.base.RedirectView
and both of those exist and can be resolved in ViewDetailView so they're fine.

However for /admin/ the view function is shown as django.contrib.admin.sites.index which does not exist. It's django.contrib.admin.sites.AdminSite.index (or django.contrib.admin.sites.site.index since the sites module exposes an instance of AdminSite). This means the view function is insufficiently specified on the URL for the view detail.

This is true for all the others that are crashing.

Next step will be to write some failing tests.

[Helen Sherwood-Taylor]

I'm working on branch ​https://github.com/helenst/django/tree/ticket_27018

Have written tests for the detail and index views.

[Helen Sherwood-Taylor]

I've fixed this but it's a Python 3 only fix due to the use of __qualname__ to find out which class the view comes from and therefore generate the correct URL.

There are ways to emulate __qualname__ in py2, but kind of hacky. I see in migrations/serializers.py qualname is also used and a message generated for py2 users. Is a Python 3 only solution acceptable here? In Python 2 it will continue to just not work (and could be tidied up to raise a 404 rather than an error).

I am not sure what is the best thing here, so some input would be good! All is pushed to the branch linked above.

There is also the issue of ensuring the tests pass (i.e. I have added test cases but they only pass for python 3).

[Tim Graham]

I don't mind if the fix is Python 3 only. Python 2 raising a 404 as happened in older versions of Django would be okay.

[Markus Holtermann]

Awesome Helen! A Python 3 solution would be fine and more than we have now :)

For the tests I'd either go with

if six.PY2:
    validate_stuff_py2()
else:
    validate_stuff_py3()

or

@unittest.skipIf(six.PY2, "Only supported for Python 3")
def test_foo_py3(self):
    validate_stuff_py3()

@unittest.skipIf(six.PY3, "Only supported for Python 2")
def test_foo_py2(self):
    validate_stuff_py2()

The first might be easier to maintain (for the time where we still have general Python 2 support in Django).

[Helen Sherwood-Taylor]

PR: ​https://github.com/django/django/pull/7127

Tests pass on 2.7 and 3.5. I have also added a note in the documentation about this.

[Tim Graham]

Left some comments for improvement.

[Helen Sherwood-Taylor]

Hi Tim, thank you for the review! I have made improvements as suggested.

[Tim Graham <timograham@…>]

In bc1e2d8e:

Fixed #27018 -- Fixed admindocs crash with a view in a class.

Generated correct admindocs URLs on Python 3. URLs generate 404s on
Python 2, as in older versions of Django.

[Tim Graham <timograham@…>]

In ae0f55e:

[1.10.x] Fixed #27018 -- Fixed admindocs crash with a view in a class.

Generated correct admindocs URLs on Python 3. URLs generate 404s on
Python 2, as in older versions of Django.

Backport of bc1e2d8e8edde6cc7d2657c68242a13ee65a15b8 from master

[Paul Donohue]

This seems to have introduced a bug: https://code.djangoproject.com/ticket/29296