On the same topic (I'm not really sure whether it's not the same thing you're talking about), currently, even if a user has not the permission to delete an object via the change form (because of some custom logic in modeladmin.has_delete_permission(request,obj) ), he can delete it via the batch delete tool.
I think it's not really consistent, arguably a bug. I guess this is the case because we use Queryset.delete(), which doesn't allow for per-instance permission checking. To me, the cleanest way to deal with this would be : - have the default delete_selected action take modeladmin.has_delete_permission(request,obj), and by the way, have the default delete_selected use Model.delete() instead of Queryset.delete() - provide a non default delete_selected_fast action work like the current delete_selected action 2016-10-14 15:31 GMT+00:00 Tim Graham <timogra...@gmail.com>: > Here is a ticket about the memory issue: https://code.djangoproject. > com/ticket/10919 > > It's hard for me to evaluate the other idea without looking at the code. > If you want to open a ticket and provide a patch, go ahead. > > On Friday, October 14, 2016 at 9:08:16 AM UTC-4, Marcin Nowak wrote: >> >> Hi all. >> >> Sometimes there is huge amount of related objects. In the effect there is >> no possibility to delete a model because of http timeout error. >> Displaying objects to be deleted is quite nice feature, but just unusable >> in cases like that. >> >> Another thing is that nobody will read 74k related objects. Believe me. >> It is better to display a summary in that case. >> To display the summary, a related objects must be counted and this is >> time consuming process, of course, but we can count them similar way to >> Collector's fast deletion (using querysets instead of counting models one >> by one). >> >> There is also other design flaw in ModelAdmin.delete_view() - related >> objects are counted twice: one time for display, and second time after >> confirming deletion (for request.method==POST). For the second case django >> is checking only permissions and collected objects aren't used for anything >> else. Until Django provides no row-level permissions checking those can be >> done without instantiating all related objects again. >> >> I'd like to suggest: >> >> - separation of permissions checking from related objects collector, >> - adding configration option for ModelAdmin.delete_view (to display >> related objects, display summary, or finally display nothing). >> >> Thank you. >> >> Marcin. >> > -- > 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-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@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/fb2c2044-241f-4ea6-9db2- > ec2dafebbeb5%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/fb2c2044-241f-4ea6-9db2-ec2dafebbeb5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/CAExk7p1dYqhbna5n78f0qGQR0g3qFZ1PRhH5rBQwbyFTcGzGfw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
