Related field checks should use their model's apps to lookup related models

[Simon Charette]

Related model fields are using the global apps registry to determine whether or not their related model is registered (to, through).

This prevents the creation of checks tests that define model using an isolated Apps() instance.

e.g.

isolated_apps = Apps()

class Foo(models.Model):
    class Meta:
        apps = isolated_apps

class Bar(models.Model):
    foo = models.ForeignKey(Foo)

    class Meta:
        apps = isolated_apps

# The following assertion will fail since the `to` check
# will detect a `fields.E300` issue.
asset Bar._meta.get_field('foo').check() == []

[Tim Graham]

​PR

[Simon Charette]

Comments addressed.

[Simon Charette <charette.s@…>]

In c550beb0:

Fixed #25723 -- Made related field checks lookup against their local apps.

[Simon Charette <charette.s@…>]

In c049c43e:

[1.9.x] Fixed #25723 -- Made related field checks lookup against their local apps.

Backport of c550beb0ccc8855fde7ff50ada530f7ceff1a595 from master

[Collin Anderson]

This seems to have broken django-taggit. ​https://github.com/alex/django-taggit/issues/360

Manager.opts was just added in 1.9. django-taggit seems to have worked fine without it up to this point. I'm wondering if we should error on the side of not using self.opts for now.

​https://github.com/django/django/pull/5718

[Simon Charette]

Not sure about what should be done here. I don't mind if we use self.model._meta like proposed to allow older version of taggit to work with 1.9 out of the box but on the other hand this whole issue is caused by the fact taggit override contribute_to_class() without calling super().

Does django-taggit also override related_query_name() and resolve_related_fields()? These methods also use self.opts.

[Collin Anderson]

Ahh, yeah, the more I think about it, it's probably best to have the error thrown in checks right away rather than have a possible issue when the code is actually running.