Based on my research, I don’t think either of the following are available, but I wanted to double-check with the community before I submit feature requests to grist-core.
Both are related to creating Forms:
Can you include “hidden fields” which are included with the form submission (i.e., go into the underlying data table with a predefined value), but are not visible to the form submitter? A use case for this would be if I want to accept data via a Form, but I want a chance to review/sanitize it before it gets included/used elsewhere. For example, I could have a “New Submission” Toggle field which would default to “True”, but only if the record is inserted via Form. Or perhaps there is a way to do this with a Trigger Formula, if I have access to the “source” of the value when I am writing my trigger value (i.e., if source=form, do X, otherwise do Y).
Can you select Reference and/or Reference List field values using a Drop-Down box, instead of just checkboxes? I have a source table with hundreds of values, so the checkboxes approach is pretty much a non-starter…
A form being just a widget, you can hide away columns (or “fields”) from it just like with any other widget. But when the form is submitted, not only those fields that were visible and were filled in by the user get written to the underyling table – all the others are there, too, just without any content. Set them up with a trigger formula, to trigger “on new record”, and you should have exactly what you’re looking for.
Correction: Sorry, I didn’t read that properly the first time. What you want is to be able to tell data that came from a form vs. data that didn’t. This is not possible per se. If your table has fields that only regular (non-form) users can see and that they also fill in usually, you can trigger on those to have, say, a check column “is_data_from_within_grist” turn to True.
At least for reference fields, the creator panel on the right, where it says “Field Format”, allows you to choose between “Select” and “Radio”, the former of which is a dropdown menu. For reference lists, this doesn’t seem possible. As a workaround you could create new individual reference columns, each pointing to the same record that the reference list in question also points to, and show those (but not the latter) on the form. That way, you’d at least have a way of letting users choose a fixed number of options from the reference list, each by using a dropdown menu.
Hope this helps!
PS. Just had another idea concerning no. 2. I have no idea what using user.Name yields for records created by a form, but it’s probably different from what a normal, logged-on Grist user would show up as. Maybe you could use this for your “from Grist” switch.
Hi, thanks for the tips. I tested a few things out, here’s what I found + my thoughts…
Set them up with a trigger formula, to trigger “on new record”, and you should have exactly what you’re looking for.
Although as you noted this wasn’t exactly what I’m looking for, this might work. As long as it stays hidden in normal table views and the special column is solely for that purpose, it could definitely work.
For reference lists, this doesn’t seem possible [to use a select box]
True, unfortunately. I basically would like it to be similar to the UX you get when you’re selecting items in a Reference List column of a table.
I have no idea what using user.Name yields for records created by a form, but it’s probably different from what a normal, logged-on Grist user would show up as. Maybe you could use this for your “from Grist” switch.
At least on my self-hosted instance, it still grabs my username (I don’t have the sign-in bits wired up yet)… but for sure on the cloud instance, I’m sure it ends up being blank or something which you could key off of.