Hi Russ, nice to talk with u,
i think that we can focus only on substitute feature,
to archive it we have 2 options:
simply upgrade the current delete_view or make a new view, something
like
url(r'^(.+)/substitute/$',
wrap(self.substitute_view),
name='%s_%s_substitute' % info),
to make it work for every model we need to build form with one
ModelChoiceField.
this field will be initialized with a queryset of the model_admin
(queryset method), and then call the queryset exclude method to remove
from the field the instance/s that will be deleted.
field = forms.ModelChoiceField(queryset =
self.queryset(request).exclude(**{"%s__in" %
self.model._meta.pk.attname: objects_to_delete})
so imagine that we have 10 object
1 Banana
2 Apple
3 Tree
4 ...
10 Stick
we mark for deletion object 1 and 2, in the view the form will make us
choose objects from 3 to 10, the use choose to substitute with object
3 and all Banana and Apple in the database will be replaced with a
Tree, using the queryset update method.
is it clear?
On 7 Lug, 15:20, 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.
