Using raw_id_fields with a many-to-many field

[Hancock, David (dhancock)]

I've found that using raw_id_fields saves a lot of time for our users over loading an entire many-to-many select. (But for shorter lists, the many-to-many widget is by far the best interface I've seen for multiple selections.)

There's an aspect of the raw_id_fields (this is in the admin interface) that is unsettling to the users, though. On a normal foreign-key relationship, it works great. But here's a scenario where it's not so good for the many-to-many relationship. A trip leg can have several travelers. If you open that leg to add a traveler, you see the list of IDs and a little magnifying glass. Click the glass to add another traveler, click the one one you, and it's added to the list. If you click the magnifying glass, determine that you need to add a NEW traveler from that index list, and then save the traveler, it's populated back on the original leg page as the sole ID in the travelers field. (That is, all the IDs previously in that field are overwritten.)

This seems like a bug to me, but if someone can set me straight on how it should work, I'd be grateful.

Thanks, and
Cheers!
--
David Hancock | dhan...@arinc.com

[Karen Tracey]

It sounds like a bug to me and worth a ticket so it's not forgotten, assuming a search of the tracker doesn't reveal any similar reports.  Sample (simple) models with a detailed recreation recipe are always appreciated in tickets.

Karen

[AndrewD]

I have a ManyToMany field that works as a raw_id_fields item. It is an
intermediary ManyToMany model class using the through='ClassName'
feature.

The admin.py shows that ManyToMany model using an Inline admin class.
The Inline class has the raw_id_fields and extras attributes. Here is
an example based on the Admin tool docs...

# models.py
class Membership(models.Model):
person = models.ForeignKey(Person)
group = models.ForeignKey(Group)

# admin.py
class MembershipInline(admin.TabularInline):
model = Membership
raw_id_fields = ('person',)
extra = 1

class PersonAdmin(admin.ModelAdmin):
# ... add other features
inlines = (MembershipInline,)
admin.site.register(Person, PersonAdmin)

The resulting admin tool generates a separate Membership ID field
(table row) with a spyglass next to it. Each spyglass sets or replaces
the single ID in that row.

The "extra" makes a new open field. Use that to add more entrties,
without deleted the others.

DISCLOSURE
This applies to an intermediary model, with a ForeignKey field, and
the "through" declaration. You may see the bug as described with an
implied "many-to-many table", which is the normal way to do this.

[Brian Rosner]

On Wed, Oct 29, 2008 at 4:35 PM, AndrewD <adro...@gmail.com> wrote:
>
> # models.py
> class Membership(models.Model):
> person = models.ForeignKey(Person)
> group = models.ForeignKey(Group)
>
> # admin.py
> class MembershipInline(admin.TabularInline):
> model = Membership
> raw_id_fields = ('person',)
> extra = 1
>
> class PersonAdmin(admin.ModelAdmin):
> # ... add other features
> inlines = (MembershipInline,)
> admin.site.register(Person, PersonAdmin)

The MembershipInline doesn't make much sense. You have put the foreign
key used for the relationship between Membership and Person in a
raw_id_field. In this case it would normally be implied by the
relationship you have setup. Is explicitly putting 'person' in
raw_id_fields intentional, it should rather be 'group' if anything.

> The resulting admin tool generates a separate Membership ID field
> (table row) with a spyglass next to it. Each spyglass sets or replaces
> the single ID in that row.

I presume you are asking a question here? That extra row is
technically a bug in the fact that it should always render it hidden.

--
Brian Rosner
http://oebfare.com