You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Feature Request: Ability to configure "read-only" forms fields to store their submitted values

Forms
Updated February 25, 2021
posted on February 25, 2021

Forms has always had this weird (i.e. non-standard) behavior where values inside fields that are marked as read-only in the Forms Designer are submitted by the browser, but not stored by Forms server.

The HTML specification states that if a field's value should be ignored, then the "disabled" attribute should be set on that field, which makes browsers ignore that field's value when submitting the form. Otherwise, if the goal is just to prevent the user from (easily) editing the field, then the readonly attribute should be set instead.

Forms "read-only" fields do have the readonly attribute, yet they also submit their values, which are then ignored by Forms server. It's like they are the mutant child of readonly and disabled HTML attributes!

It doesn't end there though. If the read-only field is the target of a lookup, then its value DOES get stored. However, if you want to change the looked up value using JavaScript first (maybe you want to trim it or change it somehow), good luck, because it won't work: forms once again will ignore your value, and re-run the lookup and plug the lookup value back into the field when storing it.

The reason this has been challenging for us is that there are many layers of complex and odd behavior like this that we have to try to remember when designing forms, and even for those of us who work with Forms every day, it's just not possible. For this reason, we have stopped using the "Read-only" option in the designer altogether, and are currently using JavaScript to mark those fields as read-only, by just adding the 'readonly' attribute to the input tag. This presents its own challenges though. For example, when the customer's non-technical business users want to be able to make changes to the forms, they can't do it without consulting us, as they aren't proficient in JS. It makes the entire form difficult to understand, maintain and extend (which runs counter to what differentiates LF Forms from competitors, i.e. its ease of use).

Anyway, I propose the following redesign:

If the "Mark as not editable" checkbox is checked, allow the user to make a determination regarding whether the field should simply be marked as readonly (and submit and store its value), or completely disabled (i.e. have the browser ignore it when submitting the form).

3 0
replied on February 25, 2021

We've heard this request for a "somewhat" read-only before. The reason read-only form fields work as such is to prevent a user from manipulating the front end to sneak a value to the back end that is unexpected. Our read-only fields not only prevent the user from editing the front end, but if they manipulate the submission request to trick it to use a different value, we still don't accept the user submitted value for read-only fields. 

For lookups, we can re-calculate the lookup on the backend to make sure the read-only field still matches. If you run a lookup into a read-only field, that looked up value will persist. However, any changes you make using JS will not be known by the Forms Server and treated as a modification on the read-only value. 

Your solution makes sense, if you want to manipulate the value on the front-end, you cannot use the Forms read-only property. The request for a non-editable field by the user but one that can be modified by a URL parameter, JS, or other means is valid, but it wouldn't be as secure since a user could manipulate the value and send it back. 

0 0
replied on February 25, 2021 • Show version history

Security shouldn't really be a concern anymore since you guys added backend validation. I mean, that is its purpose, right? So that the user can't "pop the hood" of their browser and modify a readonly or required field to be not-readonly or not-required?

With the design I'm proposing, it would be like this:

  • Read-only: Mostly a surface-level option to prevent the user from editing values by accident. Values can still be edited by scripts, URL parameters and lookups. Security is not a priority or a concern in this scenario.
  • Disabled: Should be how the Read-only field currently behaves, except the 'disabled' attribute should also be added to the field to make the behavior standards-compliant. Security would be a priority in this scenario, and backend validation would need to be adjusted.

 

You can obviously add tooltips to each option to clearly define the behavior so that people designing forms understand its implications (and limitations)

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...