Opened 14 years ago
Closed 14 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).
Note:
See TracTickets
for help on using tickets.
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.