ManyToMany fields don''t work in the generic views

[mlambert@…]

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.

[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.

[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).

[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)

[mlambert@…]

diff that fixes #337 and #338

[mlambert@…]

Proper Fix for 337 and 338

[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.

[robert@…]

Incomplete fix that is not specific to generic views.

[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.

[Seer]

Hi all
im fine, gl all!

[Malcolm Tredinnick]

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).

[(none)]

Milestone Version 1.0 deleted