Hi,

I've just install SilverStripe 2.3 RC2 and I'm trying the real interesting new feature : ModelAdmin

It work real properly with one to many relationship but doesn't work with many_many.

Here are my classes :

Here is the code for model admins :

When I've build my db and flush everything I can see Category tab on Book's edit view, but can't add categories on it.
Is something wrong with my code?

Well, sheesh... you asked a question during the biggest vacation week of the year.

I'm just barely getting my feet wet with the ModelAdmin. I love the idea, but it seems like there's a lot of room for refinement. It wouldn't surprise me if handling complex relationships like many-to-many is something that's just out of its reach right now. I'm actually not sure it will even be included with the official 2.3 release.

My suggestion would be to just go back to using a CTF like the old days.

Hey Everyone,
I'm in the same situation as Jean-Phi is/was and am encountering the very same problems.
I'm quite sure that this is a bug and I (and Jean-Phi) have worked properly. Even the sample code from the german SilverStripe Book does not work properly there (I refer to the Developer <-> Skills Relationship).
Hopefully, they'll get that fixed, though I've not yet found a corresponding entry in the Trac System. The only way to get it (more or less) working at the moment is to explicitely define the CMS-Fields (using getCMSFields() and ManyManyComplexTable) after that, the existing records are listed.

Henning

PS: I'm using Silverstripe 2.3.1 "stable" release

This still doesn't work out of the box in 2.4, right?

I got it to work using a ManyManyComplexTableField, however, but only by messing with names and relationsships for quite some while.
Relating to the example above, I turned the $many_many and $belongs_many_many around, resulting in classes like this:

Here's the things I stumbled upon:
* Which side of the relationship uses $many_many and which one $belongs_many_many actually matters, because of the table name automatically created by Sapphire. The given relations result in a table name of "Book_categories"

* The name (second) parameter given in the constructor of ManyManyComplexTableField must match the name choosen in the $many_many relationship, i.e. "categories" in this example, because it is obviously used to construct the table name to retrieve relations from.

* The name of the tab to add to must also match this name. Although you can choose any name you want, if you do so, nonetheless an additional tab named "categories" will be created which is simply empty. This seems wrong...

* After I made it work, I tried to do the same thing in categories, just vice versa, so I might be able to tick on books that belong to the current category. This did not go so well, simply because of the naming conventions that result from the points above. I suppose it is impossible to achieve, because ManyManyComplexTableField will assume a table name of "Category_books" if you do so, but the relations table is already named "Book_categories" using the given setup. Maybe this could be fixed in the future, if ManyManyComplexTableField adheres to the setup of $many_many and $belongs_many_many just the way the /dev/build process does when generating table names. Might be necessary to name many-many tables by their base objects, too: "Book_Category" in this example.