Opened 14 years ago

Closed 13 years ago

#14649 closed (wontfix)

.save_m2m() will override any Many-to-Many relationships created via signals/save method overloading.

Reported by: Chris Chambers Owned by: nobody
Component: Forms Version: 1.2
Severity: Keywords: save_m2m, signals, post_save, save_method
Cc: Chris Chambers Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Example:

# models.py

class Event(models.Model):
    calendars = models.ManyToManyField(Calendar, verbose_name=_('calendars'),
        blank=True, related_name='events'
    )

    def save(self, *args, **kwargs):
        super(Event, self).save(*args, **kwargs)
        if not self.calendars.exists():
            default_calendar = Calendar.objects.get(slug='')
            self.calendars.add(default_calendar)

However, when an admin creates an Event without specifying the calendar via the admin view:

# line 795, contrib.admin.options
self.save_model(request, new_object, form, change=False) # at this point, new_object.calendars.all() contains the default calendar
# line 796, contrib.admin.options
form.save_m2m()                                          # new_object.calendars is cleared.

The workaround is to provide a custom admin form, but this still seems counter intuitive.
(Additional thought: being able to specify defaults for m2m fields (#2750) would avoid this issue, and provide a slighter cleaner UI, as the appropriate calendar would be pre-selected in the admin interface).

Change History (1)

comment:1 by Russell Keith-Magee, 13 years ago

Resolution: wontfix
Status: newclosed

I'm not sure I agree it's counterintuitive, because I can't see what *would* be intuitive in this case. The sequence of model saving and inline saving is inherently complicated, and I don't see how we could easily maintain the user-space code structure you have described *and* satisfy the basic saving requirements of m2m form elements.

Even if it is counterintuitive, this ticket doesn't contain a proposal for what *would* be an intuitive interface.

Closing wontfix; Looking at the example, #2750 would appear to be a better way to address this use case.

Note: See TracTickets for help on using tickets.
Back to Top