django-newsletter icon indicating copy to clipboard operation
django-newsletter copied to clipboard

Use object instance when getting _meta info in admin

Open frennkie opened this issue 5 years ago • 6 comments
trafficstars

Make sure to use the object instance in admin.py in order to get the correct app_label and model_name. This is important when a subclass (e.g. of Newsletter) is used.

fix #330

frennkie avatar Sep 22 '20 17:09 frennkie

Changed to Draft as tests are failing (worked on my machine).. will look into it.

frennkie avatar Sep 22 '20 17:09 frennkie

Coverage Status

Coverage remained the same at 88.389% when pulling 6a250893bc5ff813b1852a194d7523c122df49e2 on frennkie:fix-app-label into 57ac58df4e6049d30e4b9871a31e738d79fc7bb4 on dokterbob:master.

coveralls avatar Sep 22 '20 18:09 coveralls

The tests prevented me from making a mistake. I don't think this can be "fixed". But other line is being fixed in this PR. Makes it easer to subclass.

frennkie avatar Sep 22 '20 18:09 frennkie

The tests prevented me from making a mistake. I don't think this can be "fixed". But other line is being fixed in this PR. Makes it easer to subclass.

Why can't it be fixed? It seems obj is a class instance (just from looking at it), so it does seem it would have the same behaviour. Could you verify this, for completeness sake?

Thanks! Great contribs! Forgot how much fun Open Source was. 🙌

dokterbob avatar Oct 24 '20 18:10 dokterbob

Why can't it be fixed? It seems obj is a class instance (just from looking at it), so it does seem it would have the same behaviour.

Yes, obj is an model instance. It has the opts attribute. The way the other classes are passed into model appears to be different. Even it I instantiate them (run model().opts) there is no opts attribute.. :-/

Update: I think I found it.. the opts attribute is not on the Model but on the ModelAdmin and set when that is instatiated: https://github.com/django/django/blob/master/django/contrib/admin/options.py#L589

frennkie avatar Oct 25 '20 19:10 frennkie

Right. Thanks for the feedback.

Are the API's used here documented API's? If not, they might be eligible to change and thus they might add additional maintenance load. In such case, perhaps it's wise to keep this work alive in a branch or a fork, until a stable API allows us to implement this well. I feel that subclassing the Newsletter model is a rather limited use case, as most people requiring such functionality have been making the modifications in their own forks of the project.

What are your thoughts about this?

dokterbob avatar Oct 26 '20 09:10 dokterbob