Opened 10 years ago

Closed 9 years ago

Last modified 8 years ago

#338 closed defect (fixed)

ManyToMany fields don''t work in the generic views

Reported by: mlambert@… Owned by: jacob
Component: Generic views Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Given a model like:

class A(meta.Model):

...

class B(meta.Model):

fields = ( meta.ManyToManyField(A) )

then when using a {{form.as}} in the template, the selection box (the list of all A's) is filled out correctly, but the list of A's related to B is not correctly filled out.

SelectMultipleField does take in a data parameter, and appears to correctly add selected="selected" to the <option>s, but there is no data for "as" in the data dict of fields. Likely this just needs to be setup properly somewhere. Don't know if/what anything special needs to be done on the POST-submission side of things.

Attachments (3)

cu.diff (876 bytes) - added by mlambert@… 9 years ago.
diff that fixes #337 and #338
cu.2.diff (884 bytes) - added by mlambert@… 9 years ago.
Proper Fix for 337 and 338
django-select-prepopulate.patch (2.0 KB) - added by robert@… 9 years ago.
Incomplete fix that is not specific to generic views.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 10 years ago by mlambert@…

views.admin.main's change_stage does a bunch of logic for filling up new_data, including handling many_to_many objects. I imagine code like this just needs to be run for generic views as well.

comment:2 Changed 10 years ago by jacob

  • Component changed from Template system to Generic views
  • Owner changed from adrian to jacob
  • Status changed from new to assigned

comment:3 Changed 9 years ago by H.B. Taylor <HBTaylor@…>

Does this apply to ForeignKey fields, too? I'm seeing the same behavior in generic views for a ForeignKey field of mine. The choices are populated correctly, but "data" is empty when the tag is built, so the "selected" attribute defaults to the first choice (the dashes indicating to select one choice).

comment:4 Changed 9 years ago by mlambert@…

So the quick hack-fix for this is:

In views/generic/create_update.py, in the big else statement for the request.POST check, after "new_data = object.dict", add:

for f in opts.many_to_many:

if f.rel.raw_id_admin:

new_data[f.name] = ",".join([str(i.id) for i in getattr(obj, 'get_%s_list' % f.rel.singular)()])

Basically, a c&p of the code from the admin interface to use the functions that we need in the generic views. If this is a proper fix, great, but I imagine there should be some reorganization to factor out the common "set up data for public web page viewing" functionality (dates, many2manys, etc)

Changed 9 years ago by mlambert@…

diff that fixes #337 and #338

Changed 9 years ago by mlambert@…

Proper Fix for 337 and 338

comment:5 Changed 9 years ago by mlambert@…

Of course, I forgot to properly test my original (cu.diff) diff, so it doesn't quite fix many2many-in-generic-views. The most recently uploaded diff (cu.2.diff) does work, though.

Changed 9 years ago by robert@…

Incomplete fix that is not specific to generic views.

comment:6 Changed 9 years ago by robert@…

mlamberts fixes above are modifications of the generic views. This is highly suboptimal: the manipulators should not need several hacks around them in order to work, and adding these hacks to every place manipulators are used is just wrong.

So my patch changes the way form fields work : they no longer assume that every field keeps its data in a field of exactly the same name. Instead, each field can extract the data from the dictionary itself.

I have only written this for one case : select fields of foreign keys. I have not tested if this breaks the admin ( but I doubt it, it probably just makes the hacks there pointless). Other fields will need to implement either get_member_name or extract_data if they store data in a non standard way, eg date fields.

comment:7 Changed 9 years ago by jacob

  • milestone set to Version 1.0

comment:8 Changed 9 years ago by anonymous

  • Cc jforcier@… added

comment:9 Changed 9 years ago by Seer

  • Summary changed from ManyToMany fields don't work in the generic views to ManyToMany fields don''t work in the generic views

Hi all
im fine, gl all!

comment:10 Changed 9 years ago by anonymous

  • Cc jforcier@… removed

comment:11 Changed 9 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from assigned to closed

I believe this has been fixed at some point in the interim. I just tried putting a many-to-many related field in a form and it was displayed as a select box with all the currently selected values shown as selected (and the other values as not selected).

Closing for now. If the problem still exists, please reopen, perhaps with a more concrete example (e.g. a form template that fails when used in the create_update generic view).

comment:12 Changed 8 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

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