Opened 9 years ago

Closed 9 years ago

#24746 closed Uncategorized (wontfix)

Add support for excluding callables in child ModelAdmin defined in its super

Reported by: Markus Amalthea Magnuson Owned by: nobody
Component: contrib.admin Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


If I have a super ModelAdmin class that defines list_display with some callable, there is no obvious way to have this callable in the exclude attribute in subclasses of the same ModelAdmin. See example:

class ParentAdmin(admin.ModelAdmin):
    def my_callable(obj):
        # Some custom stuff here.
        return obj

    list_display = ('name', 'description', my_callable)

class ChildAdmin(admin.ModelAdmin):
    exclude = ('description',) # I want to exclude my_callable but I can't!

I currently achieve this through weird hacks such as filtering the parent attribute to exclude items with a certain func_name, etc.

Or am I missing something obvious?

Change History (4)

comment:1 by Markus Amalthea Magnuson, 9 years ago

Note that in my example I could just redefine list_display, but in my actual use case there are several levels of inheritance of which I want to exclude some things from some levels.

comment:2 by Tim Graham, 9 years ago

If you need dynamic values, I think it would be easier to use the method versions like get_list_display(). Will that work for you?

By the way, my understanding is that exclude affects the model form, not the values in the changelist (list_display).

comment:3 by Markus Amalthea Magnuson, 9 years ago

Yes, you are right, it was only in my confused mind that exclude affects list_display as well.

Using get_*() makes code cleaner, but I still wish there was some simple way to subtract from list_display by just setting an attribute on the model admin class. Worth opening another ticket?

comment:4 by Tim Graham, 9 years ago

Resolution: wontfix
Status: newclosed

I don't think adding another customization hook for your use case will make things simpler in the long run (to make the API consistent, we might need to add a similar flag for many other ModelAdmin attributes). The function-based hooks were added so that we don't have to try to support every use case with simple attributes. You can raise the issue on the DevelopersMailingList if you like, but that's my perspective.

Note: See TracTickets for help on using tickets.
Back to Top