You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
data manipulation by changing the hidden id field in html as described in #40 is still possible if the PK field is a FK field too. (Many to Many, One to One)
This is because the ForeignKey check in sfPropelFormGenerator (getValidatorClassForColumn, getValidatorOptionsForColumn) is before the PrimaryKey Check so the normal sfPropelValidatorChoice is used.
Changing the two checks will result in the normal Validator for PK's being used on FK-PK's too but i'm not sure if it's the best course of action since there would be no validation anymore if the FK exists for new objects (therefor no pull request yet).
However, the Widgets are hidden in FK-PK's too (PK Check is before the FK Check) so it seems it's assumed that you have to set your FK-PK manually before creating the form anyway.
Kind regards
Tschebel
The text was updated successfully, but these errors were encountered:
Hello
data manipulation by changing the hidden id field in html as described in #40 is still possible if the PK field is a FK field too. (Many to Many, One to One)
This is because the ForeignKey check in sfPropelFormGenerator (getValidatorClassForColumn, getValidatorOptionsForColumn) is before the PrimaryKey Check so the normal sfPropelValidatorChoice is used.
Changing the two checks will result in the normal Validator for PK's being used on FK-PK's too but i'm not sure if it's the best course of action since there would be no validation anymore if the FK exists for new objects (therefor no pull request yet).
However, the Widgets are hidden in FK-PK's too (PK Check is before the FK Check) so it seems it's assumed that you have to set your FK-PK manually before creating the form anyway.
Kind regards
Tschebel
The text was updated successfully, but these errors were encountered: