mptt specific attributes not proxied

[GoogleCodeExporter]

Consider a heterogenous tree of groups and products modelled using one
model "ProductNode". ProductNode is registered with mptt
("mptt.register(ProductNode)").

Now, in order to provide separate admin interfaces for products and groups,
I make use of Django proxy objects, as follows:

class Product(ProductNode):
    objects = ProductManager()
    class Meta:
        proxy = True

class ProductGroup(ProductNode):
    objects = ProductGroupManager()
    class Meta:
        proxy = True

This enables me to leave out certain Product-specific fields from
ProductNode out of the ProductGroup admin interface, which works really well.

However, when attempting to modify any of the proxy objects, the following
exception is thrown:

AttributeError: 'ProductGroup' object has no attribute 'lft'

I would expect that the mptt specific attributes were proxied
automatically, without having to register Product and ProductGroup to mptt.

Original issue reported on code.google.com by dotsph...@gmail.com on 2 Jul 2009 at 6:43

• Merged into: #34

[GoogleCodeExporter]

This problem comes from _meta. Field names are assigned to _meta on registered 
model. It will require to have 
those assigned to Meta (class) also, but actually there isn't any way how to 
assign something to Meta - because 
of the Options checker - this should be changed in django itself. There should 
be support for user defined meta 
attributes.

When the proxy gets created, it mixes up _meta for it based on origin Meta, so 
specific fields are not in proxy 
anymore. The same problem happens with model inheritance.  

Original comment by pcicman@gmail.com on 22 Jul 2009 at 10:33

[GoogleCodeExporter]

Fixing this would require some level of deep magic. As pcicman points out, 
merely adding the fields to the model is the easy part. We need to add things 
to the _meta as well.

One option is to add a metaclass to the model which automatically registers 
model subclasses. Enough magic to make me uncomfortable, but maybe someone can 
improve on that.

Original comment by craig.ds@gmail.com on 2 Sep 2010 at 12:38

• Changed state: Chatting

[GoogleCodeExporter]

This can be considered fixed in the abstract-model-refactor branch, since that 
uses abstract models, and fields inherit nicely.

Closing, any further discussion should go to Issue 34

Original comment by craig.ds@gmail.com on 20 Sep 2010 at 10:28

• Changed state: Duplicate