CMS MADE SIMPLE FORGE

Form Builder

 

[#5422] If site uses multiple forms submitted data can only be retrieved for first form entered.

avatar
Created By: Mike Hughesdon (mikeiwk2)
Date Submitted: Tue Sep 14 10:01:28 -0400 2010

Assigned To: Samuel Goldstein (sjg)
Version: 0.6.4
CMSMS Version: None
Severity: Major
Resolution: Fixed
State: Closed
Summary:
If site uses multiple forms submitted data can only be retrieved for first form entered.
Detailed Description:
I have found a problem in a site which uses multiple forms and frontendusers. 
If a user enters data to more than one form and later returns to one of the
forms, only data for the first form completed is redisplayed, the other forms
are displayed blank.

I've dug into the code and the problem appears to be in
cmsms\modules\FormBuilder\FormBuilder.module.php - function
getResponseIDFromFEUID.  The function executes SQL 'SELECT fbr_id FROM ' .
cms_db_prefix(). 'module_fb_formbrowser where feuid=?' which retrieves the first
row on *.module_fb_formbrowser with the supplied feuid, hence the problem.

I've made a local change to pass in the id of the form being processed and
changed the SQL to use it as one of the qualifiers.  The function is called from
both the FormBuilder and FormBrowser modules, since FormBrowser isn't a problem
for me I've added an if condition so that it executes the original SQL.  The
changed code looks like:

if ($formId)
{ 
  $sql = 'SELECT fbr_id FROM ' . cms_db_prefix().
'module_fb_formbrowser where feuid=? and form_id = '.$formId.' ORDER BY
submitted DESC';
}
else
{
  $sql = 'SELECT fbr_id FROM ' . cms_db_prefix().
      'module_fb_formbrowser where feuid=?';
}

Note that I've also changed the SQL to return the most recent row based on the
submitted timestamp since my form is inserting a new row if the form data is
updated.

I've amended the call to this function in
cmsms\modules\FormBuilder\classes\Form.class.php - function Load.  Here I've
captured the form Id from $this->GetId() and passed it into the function call.

That has fixed the problem I had.

I've also made a change to the FormBuilder module to pass a FALSE value (-1) to
the function so the original SQL is currently executed.  The change was made to
cmsms\modules\FormBrowser\classes\Browser.class.php - function LoadResponse.

One other inconsistency that may need tidying up, the function is defined as
getResponseIDFromFEUID, but it is called as GetResponseIDFromFEUID.  I know PHP
is case insensitive with function names, but that may change one day?


History

Comments
avatar
Date: 2010-09-15 06:40
Posted By: Mike Hughesdon (mikeiwk2)

Cleared out my form data to restart testing and I'm now finding that only one
row is created in the module_fb_formbrowser table for a form, which is then
updated when I amend the form input.  Previously, everytime I accessed the form
and submitted it a new row was created, not neccessarily a bad thing as it gave
me a history of my user input.  If this is now the standard behaviour it removes
the need for the ORDER BY clause in my amended SQL, though I'd be tempted to
leave it just in case!  I don't know why this change has happened, but my
coworker updated FormBuilder from 0.6.2 (I think) to 0.6.4 last week when he was
preparing to look at this bug, so perhaps it's a fix in the software that has
changed the behaviour.
      
avatar
Date: 2010-12-05 22:44
Posted By: Ryan Foster (RytoEX)

Confirmed this bug in Form Builder 0.6.4 on CMSMS 1.9.1.

If you could email me either a diff or the files that you modified, that would
be helpful in merging the changes.
      
avatar
Date: 2010-12-06 09:09
Posted By: Mike Hughesdon (mikeiwk2)

Ryan,

I've emailed the files to your gmail address.

Mike
      
avatar
Date: 2011-01-07 02:44
Posted By: Ryan Foster (RytoEX)

This fix has been checked into SVN as Revision 535 on Friday, January 7, 2011 at
02:36:29.
      
avatar
Date: 2011-04-08 17:04
Posted By: Ryan Foster (RytoEX)

Closing this bug because it has been fixed, a version with the fix has been
released, and no additional complaints have been made.
      
Updates

Updated: 2011-04-08 17:04
state: Open => Closed

Updated: 2011-01-07 02:44
resolution_id: 6 => 7

Updated: 2010-12-05 22:44
resolution_id: 5 => 6

Updated: 2010-09-23 09:27
severity_id: 12 => 2
assigned_to_id: 100 => 110

Updated: 2010-09-15 06:40
resolution_id: => 5