Proposal to remove ModelAdmin's collection of actions from superclasses

89 views
Skip to first unread message

Tim Graham

unread,
Nov 5, 2018, 12:03:55 PM11/5/18
to Django developers (Contributions to Django itself)
Hi,

A recent bug report [1] brought up the fact that ModelAdmin collects actions from superclasses. For example:

class BaseAdmin:
    actions = ['a']

class SubAdmin(BaseAdmin):
    actions = ['b']

SubAdmin will have action 'a' and 'b'. The behavior isn't tested and only mentioned in passing in docs for ModelAdmin.get_action(), "Most of the time you’ll use this method to conditionally remove actions from the list gathered by the superclass."

I think the reason for the "collect from superclasses" behavior was to inherit the "delete_selected" action from BaseModelAdmin, however, that reason was obsoleted in a later commit where AdminSite actions were added and delete_selected was moved there.

I propose removing this surprising (to me, at least) behavior and follow normal Python inheritance. If someone wants to inherit actions from a subclass, they should use:

class SubAdmin(BaseAdmin):
    actions = BaseAdmin.actions + ['b']

Adam Johnson

unread,
Nov 5, 2018, 1:09:42 PM11/5/18
to django-d...@googlegroups.com
I agree, it shouldn’t be doing something so surprising and undocumented.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3235fe9c-30e2-4534-93eb-c7f6a45eac63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Adam

Carlton Gibson

unread,
Nov 5, 2018, 1:22:07 PM11/5/18
to Django developers (Contributions to Django itself)
The idea was that you could define a base admin and have the actions appear without having to redeclare them. 

The only question is are people actually using that? (I can't think of a third-party app that provides an admin with actions that you're meant to subclass for instance — anyone?) 

If not, then the "usual Python behaviour" argument is favourite. (i.e. +1) 

— Carlton

charettes

unread,
Nov 5, 2018, 1:38:56 PM11/5/18
to Django developers (Contributions to Django itself)
I agree with you Tim. +1 from me.
Reply all
Reply to author
Forward
0 new messages