Last modified: 2010-01-08 06:30:41 UTC
Created attachment 6798 [details] patch for order error in validate_type_of_multiple_fields (SF_FormUtils) I don't know if this covers more than dates, but at least for type=date, the IDs for the field tags for multiple part fields in the form are in the format "input_<<field_num>>_<<instance_num>>", example: id="input_123_day" id="input_123_month" id="input_123_year" . . . This javascript was looking for them in the format "input_<<instance_num>>_<<field_num>>", example: id="input_day_123" id="input_month_123" id="input_year_123" The attached patch fixes that order. Unknown: Will this cause or fix problems with validate_type_of_multiple_fields with type other than "date"? Causes browser hangs in large forms
I can't duplicate this problem; date validation works fine for me on multiple-instance templates. Is this still an issue?
Yes, this is still a problem. To replicate, do validation when you have MULTIPLE instances of a multiple-instance template. Only the first will be validated because the javascript only verifies the passed ID. This was a big problem for us - and would not alow us to have multiple instances of where file uploads occured - the upload popup will fail.
Yaron, wasn't this an IE only problem? I just remember you couldn't save a form because the validations would never pass.
(In reply to comment #1) > I can't duplicate this problem; date validation works fine for me on > multiple-instance templates. Is this still an issue? This error occurs when there are multiple instances of multi-part forms that contain any fields that use validate_type_of_multiple_fields. The primary example of this is dates. You can reproduce this in two ways: 1. Create a multi-part form that uses at least two different templates each having a unique field that uses the above validate: 2. Create a multiple instance form with a field that has the validate in question. In either case, the second field would fail to validate because it doesn't exist (found this out by debugging the javascript). To validate the existence of this bug, I offer three options: 1. Use the below code (you'd have to create your own templates or get them from me) 2. Contact me and I'll set up a site to demonstrate 3. Take my word for it - this is a real a replicable problem solved by the attached fix (which doesn't have any performance or security issues) <pre> {{{info|Add title=Add New Change/Incident Report|edit title=Edit New Change/Incident Report|page name=CIR-<unique number;start=000000>}}} {{{for template|Change Incident Report}}} {| {{FormStyle}} style="width:100%" |- | colspan=2 | {{{field|Name|size=80}}} | colspan=2 | {{{field|Date|input type=datetime|default=now}}} |} {{{end template}}} {{{for template|Activity Plan|multiple}}} {| {{FormStyle}} style="width:100%" |- ! style="vertical-align:text-top;" | Expected Time to Complete: | {{{field|Expected Time to Complete|input type=datetime|default=now}}} |} {{{end template}}} </pre>
(In reply to comment #4) Also, the symptom is that the browser hangs (can't find the field in question), until the browser times out - this may be especially noticeable in IE, may just appear as an error in other browsers.
Setting to "invalid" - this is apparently no longer a bug in the current version of SF.
