Added protection against proxying swapped models.
This commit is contained in:
parent
abcb027190
commit
dfd72131d8
|
@ -108,6 +108,11 @@ class ModelBase(type):
|
|||
|
||||
is_proxy = new_class._meta.proxy
|
||||
|
||||
# If the model is a proxy, ensure that the base class
|
||||
# hasn't been swapped out.
|
||||
if is_proxy and base_meta.swapped:
|
||||
raise TypeError("%s cannot proxy the swapped model '%s'." % (name, base_meta.swapped))
|
||||
|
||||
if getattr(new_class, '_default_manager', None):
|
||||
if not is_proxy:
|
||||
# Multi-table inheritance doesn't inherit default manager from
|
||||
|
|
|
@ -1953,6 +1953,18 @@ control access of the User to admin content:
|
|||
the given app.
|
||||
|
||||
|
||||
Custom users and Proxy models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
One limitation of custom User models is that installing a custom User model
|
||||
will break any proxy model extending :class:`~django.contrib.auth.models.User`.
|
||||
Proxy models must be based on a concrete base class; by defining a custom User
|
||||
model, you remove the ability of Django to reliably identify the base class.
|
||||
|
||||
If your project uses proxy models, you must either modify the proxy to extend
|
||||
the User model that is currently in use in your project, or merge your proxy's
|
||||
behavior into your User subclass.
|
||||
|
||||
A full example
|
||||
--------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue