multiple signatures on one webform?

[twomice]

Hi @mattwire I've got a use case for having two e-signatures, linked to separate custom fields on a single activity, on a single webform. Any thoughts on what it would take to make that possible?

[mattwire]

@twomice Potentially quite straightforward. We just call the attachment API to actually upload the signature - and the "configuration" for that is done via webform fields (for custom field ID + activity type ID) with specific keys. It would be nice to improve that "configuration" and do it some other way. But to support two e-signatures (assuming the underlying esignature plugin supports multiple) you could just add a loop to the code which creates the attachments and append _1, _2 etc to the webform elements which are used for configuration.

[twomice]

I think I understand. So a site builder would need to create one additional hidden webform field, esign_custom_field_2, and the module code, finding that additional field, would display an additional esign widget. Is that right? (Or would they also need to create a second esign webform field as well?)

Also, slightly tangential, but if we're having multiple esign fields on a form, do we need to consider the possibility that the webform could be configured for multiple activities of the same type -- and in that case, the possibility that we want one esignature on one activity, and the second esignature on the other activity?

[mattwire]

You'd need an additional esign widget too - and then enough hidden webform fields to describe the required configuration

[twomice]

@mattwire Sorry just getting back to this. Thanks for answer. Any thought on this part?

if we're having multiple esign fields on a form, do we need to consider the possibility that the webform could be configured for multiple activities of the same type -- and in that case, the possibility that we want one esignature on one activity, and the second esignature on the other activity?

[mattwire]

@twomice Yes, that should be pretty easy to resolve. It's just a case of collecting the right info and doing something logical with it when processing.

[twomice]

Hi @mattwire . We've got a working solution (pretty close to a PR) which supports use cases like the following:

1. Multiple signatures, each stored in a separate specified field on the same activity
2. Multiple signatures, each stored in a specified field on separate activities (An odd quirk in the available data in $values is preventing us from knowing multiple activity IDs if they're of the same activity type, so such activities must be of different types)
3. Of course the existing use case of one signature for one activity.

Different to what we discussed above, our approach was -- instead of making the user create additional hidden webform components -- we accept comma-separate values in the two existing hidden fields. Example configurations are like so:

Use case	esign_custom_field example	esign_activity_type_id example	notes
A single custom field on a single activity	custom_9	70	(same as current behavior)
A single custom field on multiple activities (must be different types)	custom_9,custom_9	70,71
Two custom fields on a single activity	custom_9,custom_10	70,70	Note that the same activity_type_id is given twice
Different custom fields on different activities (different types)	custom_9,custom_10	70,71

Things I like about comma-separated vs a fieldname_N convention:

• Avoids confusion between fieldname and fieldname_1; of course in the fieldname_N convention, both should have the same meaning, but explaining that is tedious.
• Avoids a long proliferation of hidden fields on the webform; keeps the config in one place.

Are you interested in a PR along these lines?

[mattwire]

@twomice That seems sensible!

[mattwire]

Closed via #5