Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Problems with build-filters which not manage n-n relations. #130

ComOcean opened this Issue · 13 comments

5 participants


Since last release, sfGuardPlugin doesn't work with sfPropelORMPlugin

The build-filters doesn't create the sfWidgetFormPropelChoice widget and validators for n-n relation.

Then I have in sfGuardPlugin :

Fatal error: Call to a member function setLabel() on a non-object in /MyProject/site/plugins/sfGuardPlugin/lib/filter/sfGuardPermissionFormFilter.class.php on line 17


I'm having the same problem with the forms.
I've created a sfGuardPlugin_schema.custom.yml that takes cares of the missing crossRefs (which appear to have become mandatory):

_attributes: { package: plugins.sfGuardPlugin.lib.model }

_attributes: { phpName: sfGuardGroupPermission, isCrossRef: true }

_attributes: { phpName: sfGuardUserPermission, isCrossRef: true }

_attributes: { phpName: sfGuardUserGroup, isCrossRef: true }

However, sfGuardPlugin now works correctly but in other places I seem to have it mixing up the crossRef data in forms, creating widgets whose name does not correspond to the model-parameter of sfWidgetFormPropelChoice.
In some places the widget is missing where it should clearly be, in other it creates one choice widget with mixed up data instead of creating two or more widgets.


Ok thanks a lot for this information.

I think, either

  • users will have to be warned and these change documented because it concerns a lot and a lot of plugins.
  • or it has to work like before (no need to update or customize all plugins)

Looks like other are having similar problems: #129


@jaugustin I think we need to revert your changes, or at least, to think a bit more on that...


yes we can revert the changes and wrote another patch but I think we will have to do choices:

  • no BC break and keep bugs
  • little BC Break and fix bugs ;)

Maybe my patch could handle many-to-many without isCrossRef parameters but it will probably leave some bugs


IMO having to explicitly set isCrossRef to enable it's behavior is fine, but I do have a problem with the mixing of several crossrefs, a I described in the second comment. If that can be fixed I'd be very happy.


@jaugustin I understand but keep in mind that it introduce bugs in a lot of Symfony plugins (open-source or not) and projects.

Then it is not a "little" BC Break, it is a major BC Break that will have to be warned to all sfPropelORMPlugin users for next official release. Ok it is not difficult to add this property to all schemas but users will not have to spend hours to find where is the problem.


i also see this as a major bc break especially since isCrossRef method to add relation seems unstable


I will work on a better patch,
For now the solution is to use the tagged version of the sfPropelORMPlugin 1.4

maybe @willdurand could revert my patch until I made a new one.


a revert would be nice for the svn users.


you could use this svn url to checkout 1.4 tag


@jaugustin I was just about to ask that question :)


thx @jaugustin i didnt know tags were accessible via github for svn users

@jaugustin jaugustin referenced this issue from a commit in jaugustin/sfPropelORMPlugin
@jaugustin jaugustin fix issue #129 and #130 with BC break of generated form for M2M witho…
…ut isCrossRef parameters
@jaugustin jaugustin referenced this issue from a commit in jaugustin/sfPropelORMPlugin
@jaugustin jaugustin fix many-to-many form generation when middle table join one table twice,
(only without isCrossRef=true) issues #130 #129
@willdurand willdurand closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.