Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.0.2
Bug #6962 crossLinks are no more processed
Submitted: 2006-02-28 17:14 UTC
From: pedro at enova dot com dot br Assigned: justinpatrin
Status: Closed Package: DB_DataObject_FormBuilder (version 1.0.0RC4)
PHP Version: 5.1.2 OS: debian sarge
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 4 + 36 = ?

 
 [2006-02-28 17:14 UTC] pedro at enova dot com dot br (Pedro)
Description: ------------ After updating from 1.0.0RC2 to 1.0.0RC3 the crossLinks set in my application stop working. Watching the DataObject debug messages I found that the crossLink field is marked as "to not be editable by the user". I tried to include the field name in the userEditableFields array in the DO object, but this take no effect. There is a way to make it work? Just in time: there is no fieldsToRender array and no preDefOrder array defined in DO object.

Comments

 [2006-03-01 17:16 UTC] justinpatrin
It still works fine in my tests. You probably are using a side-effect of the old version of FormBuilder which allowed editing of crossLinks even if they were not set as editable. If you're using userEditableFields you need to add the crossLink to it. The name of the crossLink to use is: __crossLink_TABLENAME or __crossLink_TABLENAME_FROMFIELD_TOFIELD Please try these and close the bug if it works.
 [2006-06-12 16:24 UTC] pedro at enova dot com dot br
Today I've found the "troublemaker". A dot in the crosslink'ed table that wasn't sanitized when FB sets $fb->crossLinks property. So, I recommend FB to sanitize the table name at this point too, and not only when it checks if the crosslink is in $editableFields array (line# 2761 on FormBuilder.php). That's all. Keep the good work!
 [2006-12-07 07:16 UTC] justinpatrin (Justin Patrin)
I'm not seeing where this problem could be. I currently don't have any systems set up which allow "." in a table name. Could you show me which line of code is causing the problem? Perhaps fix it and put up a unified diff I can look at? It wouldn't be appropriate to sanitize the crossLinks property of course as this is used to access the table.
 [2006-12-07 07:22 UTC] justinpatrin (Justin Patrin)
If you find the problem please re-open the bug.
 [2006-12-07 11:58 UTC] pedro at enova dot com dot br
The problem occurs when I use schemas in a postgresql database. In this case table names uses dot (public.table).
 [2006-12-08 02:26 UTC] justinpatrin (Justin Patrin)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.