When Form Fields Set to Read Only Aren't Really "Read Only"

Reported Issue

A school submitted a Slate support request reporting that a student's name had changed to strings of question marks (i.e., "???" and "??") after they submitted a form. They were unsure how this was possible, since the First Name and Last Name fields were configured as Read Only. Intuitively, respondents should only be able to see the information already stored on their record without being able to edit it.

What We Found

From the person record's audit log, we saw that the form was submitted from an iPhone from Japan and the student had a traditional Japanese name. The suspicion is that somehow the kanji spelling of the name was entered, which could explain the string of question marks. See this related Community forums post (🔐 requires login). But that still doesn't explain how a read-only field could be updated in the first place.

This has us wondering whether Apple's autofill behavior, and its interaction with Slate's read-only fields, could ultimately be the cause. Some browser engines have had documented exceptions to read-only enforcement. Mozilla confirmed and fixed a related Firefox defect, Bug 1752198: "Autofill modifying readonly input", though it wasn't necessarily specific to Slate or any other platform. We can't yet confirm whether the behavior we saw is autofill-based, browser-based, tied to the way Slate renders the field, or an interaction between the two. It's worth testing when time allows, if only to put the curiosity to rest.

Ultimately, testing may tell us more about how the field value was changed, but that doesn't change the recommended configuration.

The ReSolution

If information is being shown only so the respondent can see what is already stored in Slate, do not use a mapped read-only field to display it.

Instead, add the needed values as merge fields on the form and place them in an Instructions block. The respondent can see the current information without those values existing as form controls that can be changed or submitted back to the mapped fields.

This approach follows Technolutions' Slate Knowledge Base guidance (shoutout to Max Zeryck for the sleuthing help and reminder!). The Merge Fields on Forms article specifically identifies displaying record information that should not be edited as a typical use for merge fields and how to build them on a form. Custom Tabs also recommends merge fields over read-only fields.

Other Considerations

Perhaps you're thinking, "We have so many forms with read-only field configurations, especially on key system-mapped fields. How am I ever going to find them all for moving to merge fields?"

This can be done in configurable joins, via a form-based query (also when time allows, we'll build and add a suitcase with snazzy clickable links directly to the form edit page), but a basic custom SQL query can track them down quickly.

1. Create a Quick Query with type = local and base = Custom SQL

2. Copy and paste this code snippet into the window:

   select
       f.id as [Form ID],
       f.summary as [Form],
       ff.labelText as [Field Label],
       ff.export as [Mapped Field]
   from dbo.[form.field] ff
   inner join dbo.form f
       on f.id = ff.form
   where ff.export like '%sys%'
     and ff.readOnly = 1
     and ff.active = 1
   order by
       f.name,
       ff.position;
   

3. Click Save

4. Run Query

The results show which mapped fields appear on which forms, so you can go straight to the ones that need updating.