Umm, before I go any further, did you guys know that you don't have to define $belongs_many_many? I have at times mistakenly defined both as $many_many and it works fine.

Maybe try that first?

I never got the whole belongs_many_many thing, anyway.

Hey guys,

Really appreciate your work on this. I have been thinking, and I wondered if it was possible to NOT call 'getCMSFields_forPopup()' when the only permission that is set is 'show'. Because, if you have a page-to-page relationship you probably wouldn't need to add or edit the information from the dataobjectmanager. Let me know what you think.

Hi Martijn.

I don't think that code is ready to be included partially since you seem to have found a bug I'll have to take a look at and because it kind of breaks the way things normally work.

Fixing the bug is doable but I'm very unsure if there is a satisfactory solution to the infite loop since that's simply how DOM/Complextablefield is built. They all have the functionality of defaulting to getCMSFields() and this fix breaks that functionality in a pretty huge way.

Since this seems to be a pretty rare scenario that break might be kind of acceptable but that decision is up to UncleCheese. IE we would have to inform people that using DOM on the belongs_many_many side means you have to setup separate popup-getters, otherwise everything explodes.

Nice to see that the code is getting some use.

I haven't had the time to look at the problem you reported Martijn but I'll hopefully get to it in the next couple of days and see if I can figure out what goes wrong when you use the same name as key/value.

I just wanted to add that there is one more scenario where this will break rather messily and that is when you have several many_many relations to the same object, for example

This is probably a pretty rare scenario but if it applies to anyone trying this fix then know that this will break it. The big problem here (which I don't think there is a real solution to within the boundaries of how this works today) is that there's no way for the belongs_many_many class to figure out which one of the two relations above is the one that applies and thus it can't reliably find the correct relationship table.

If there's just one many_many relationship to a class then it works, if there's more it doesn't. I am going to have a look at how (or if) SilverStripe solves this with it's getters, if we're lucky there is actually a solution to this somewhere in the code.