search

verbb / formie

The most user-friendly forms plugin for Craft CMS.
Other
95 stars 73 forks source link

Allowing server-side only variables per form #1422

Open jishi opened 1 year ago

jishi commented 1 year ago

What are you trying to do?

I've used the Active Campaign and the Mailchimp integration and both cases I've wanted to send in pre-defined tags (not user-selected) that flags a contact that it's coming from a certain entrypoint.

The only way I've achieved this, is by putting a hidden field with the tag value, and then map that to the tags of the integration. Although this works, it both give me a field in each submission that is editable, but it also allows the submit to create an arbitrary tag value (and basically flood your CRM account with tags) because tags are auto-created.

This feels counter intuitive for me, and I would much rather prefer having a strict control of tags whenever possible.

What's your proposed solution?

Having the possibility to add "server fields", that are stored on the form and selectable in the integration mapping would be nice. It would both hide the applicable values from the visitor, but also mitigate abuse of the tag values.

Another solution might be to allow configuration of "auto-create tags" or similar, so it would only accept tag values that already exist in the CRM. However, this adds complexity for administrators.

Additional context

No response

engram-design commented 1 year ago

I would recommend using a visually-disabled (see the "visibility" setting for a field) field so that it doesn't render on the front-end, but can be populated with Twig.

jishi commented 1 year ago

How is that different than a hidden field? I just tried it out and it's basically a text input that is hidden, it has the same problem that someone can post whatever values they want for these fields if they are malicious.

jishi commented 1 year ago

Actually, since this purely relates to integrations (as I see it), even having the option to map an integration field to a static string would suffice, instead of just allowing form field values (or submission variables)

engram-design commented 1 year ago

I've explained how that's different (also see docs)

You can set any field to be "Hidden" on the front-end. This will still be available in the source of the page, but hidden for general users. You can also set it to be "Disabled", where the field is never rendered on the front-end, but can still have its value set via Field Population

When set to disabled, it shouldn't render at all on the front-end, so it can't be tampered with.

As for mapping to a static string, that's somewhat on the roadmap, we just haven't figured out a nice UI for that yet.