i took this idea from wordpress. in wordpress when you delete an user instead of deleting all related posts you can choose to assign them to another user.
we can extend this system on every model class, i think. whatch here, sorry wordpress is in italian (hope u understand a little) http://grab.by/5kn6 we can use a radio field to choose the mode (or we can choose the mode with a GET param, or with two different urls ^delete/ and ^substitute/), and then a combobox to select the instance... not too difficult, and it would be a fancy feature. On Jul 7, 3:20 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, Jul 7, 2010 at 3:41 PM, Ric <riccardodivirgi...@gmail.com> wrote: > > Hello i opened a ticket, but somone suggest me to discuss this new > > feature here. > > >http://code.djangoproject.com/ticket/13900 > > ---- > > i would like to edit > > django.contrib.admin.options.ModelAdmin?.delete_view and add a helpful > > feature. > > > Instead of deleting all the nested objects, the delete_view could > > handle 3 options: > > > 1. delete all the related objects (current option) > > 2. where the foreign key to the current instance is nullable, null or > > delete > > These first two options are really a duplicate of ticket #7539; it > isn't something that should be handled at the admin level, but at the > model level. The broad ideas behind #7539 are well established; the > patch just needs to be carried the last few steps to trunk. > > > 3. replace all the related objects with an other model instance (we > > can make a user choose it with a forms.ModelChoiceField?) > > i really would like to contribute to this feature, because i need to > > do this in my admin site, but i'm new, so please help me :) > > This is an interesting idea. At a raw technical level, introducing a > 'pre-deletion cleanup' stage for admin deletions shouldn't be too > difficult -- the current deletion confirmation view provides a > convenient place in the workflow that could be replaced with a view > that provides options to nominate how relations should be cleaned up. > > However, my concern is whether this could be made a generic > capability. If this is to become a configurable capability of the > admin interface, it needs to work with every possible model, not just > a subset of models. It isn't immediately obvious to me how you could > specify a relation substitution scheme in a completely generic way. > > There's also the issue of how to handle this sort of substitution on a > bulk delete - if you're deleting a group of 50 objects using an admin > bulk action or as a result of a cascaded deletion, you don't want to > be presented with an auto-generated dialog of 50 pulldown/raw_id_admin > widgets. > > I suspect the best course of action for trunk will be to make it > *possible* to easily introduce a pre-deletion stage, but not actually > provide that capability as part of core admin functionality (i.e., > cleanup and document the mechanism by which you can define a > pre-delete view, but not actually provide a "cleanup= ('field', > 'field')" definition on ModelAdmin that automatically turns into a > pre-configured deletion view. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
