Adding functionality to forms (long text and attachments)

[DavidFabijan]

I've just stared using Grist in our company and we have so far found quite a few uses for it. People seem to be especially enamoured with the possibility of quickly generating forms. But we have come across two issues with forms as well:

1. There doesn't seem to be any way to enter longer/multi-line text into the form. Using the Shift+Enter that works in the table view will instead instantly submit the form. Are we missing something here? It would also be useful if there was a way to somehow set the height of a certain text input field on a form. Say mark some of them to be single line, and others to be multiline (say 4 lines heigh by default)

2. The attachment type just seems to show up as a text field in a form as well. Being able to actually upload things (imges, pdf's, etc.) would be most useful. Would it be possible to implement something similar to the attachment field in the table view?

[georgegevoian]

Hi @DavidFabijan.

An option to display Text fields as textareas is being worked on. I don't have an exact ETA, but expect to see it soon.

Support for attachments is also on our internal roadmap for forms. No ETA, but hearing feedback like this always helps us prioritize which features to work on next, so we appreciate it.

[root-hal9000]

@georgegevoian If I may follow up here, since it's directly related - Is that currently a possibility in card views? I just started testing grist to potentially deploy for my enterprise, but was curious about this. In our case, forms are not as important because it's mostly internal data entry, but we have a lot of longer text fields, so something of the sort would be great in cards. If not, do you know of plugins for this? Thank you!

[georgegevoian]

@root-hal9000 not currently.

I don't know of any custom widgets off the top of my head, but one thing you could try is pointing a custom widget's URL to the preview URL of an unpublished form in your document (with the submit another response option enabled). Form previews are fully functioning forms (they just aren't accessible to the public) so embedding them in a custom widget should just work - it just might be a little cumbersome to have to click a button each time you want to submit a new record.

There's a few related product improvements we've been discussing, including allowing form widgets to be used within a Grist document for data entry, and bringing some of the functionality of form widgets to card widgets. We've received feedback from a number of users specifically asking about the possibility of using forms internally for data entry, as it can be useful to be able to fill out all of the fields of a record before committing to creating it; this is something that cards can't currently do (but perhaps could be a configurable option in the future). We still haven't decided on any concrete changes, but it's top of mind for us.

By the way, you can still enter multi-line text in card fields by typing Shift+Enter to insert lines, and if wrapping is enabled (which is the default), the height of the field will grow to fit its content. (Mentioning it just in case, as it's not obvious it works the same way across tables and cards.)

[root-hal9000]

hey @georgegevoian thank you so much for the detailed answer. Yes, I saw the Shift+Enter - this was more just thinking about the UX of our internal users, and their brains not associating the look of a single line as a long text entry. Although, considering that they're not entering rich text and thus we are not talking about a full text editor anyway, I suppose this is more about doing a friendly layout, which as you said, the forms functionality does a pretty good job of!

In any case, I wrote this within my first thirty minutes of testing Grist (which actually started with me thinking forms was also for internal data entry before I tried card views) - now that I saw the flexibility and simplicity of the plugin architecture, I can envision several ways of going about this and other needs I have. Thanks for the suggestion on using the forms preview link, that's a good hack, even if it doesn't cover editing records.

And yes, I would add my voice to people wanting internal forms like functionality :) I say this as someone who is looking for an alternative to coding something every time a need arises for some sort of internal database frontend app. Loving what I see so far putting together a little proof of concept!

[Sieboldianus]

Support for attachments in forms would be awesome. We considered nocodb for our non-profit organisation, to collect data on a specific topic, but they don't offer SSO in their CE plan. Grist looks perfect for what we need, but the form needs to support image upload. HackMD has a pretty nice integration of Drag&Drop Image upload, which just puts files in a folder on the server using a random hash.

[crelocks]

I second this, in case you are looking to set any priorities :)

[fflorent]

Just a feedback from our users (ANCT and DINUM), the possibility to support attachements is regularly asked and very expected.

[paulfitz]

At Grist Labs, the discussion about attachments and forms has gone like this:

• We want them!
• But if we add them, will users make documents with a lot of attachments that get too big.
• Shouldn't we externalize attachments first (store them outside of .grist file).
  We have plans for how to support externalized attachments, but don't yet have someone to work on it.

[fflorent]

Externalized attachments is also something we would like!

Is there an issue for that?

[vviers]

Update : work is underway for Externalised attachements :)

[David-Fabijan]

Highly looking forward to this new functionality! I assume there will be a simple process to move from the current state to the externalized attachments state of affairs? Also are we to expect any changes to the attachments API, just wondering since a lot of our workflow right now actually hinges on the attachments API?

[vviers]

@David-Fabijan you might want to have a look at what's going on in #1021

[Spoffy]

I assume there will be a simple process to move from the current state to the externalized attachments state of affairs?

@David-Fabijan, The current plan is for Grist to function identically to how it does now, if you don't make any configuration changes.

If you want to use external attachments, the current plan is for a per-document mechanism for migrating existing attachments to the external storage (and back).

are we to expect any changes to the attachments API

There may be some new endpoints added, and possibly some optional extra parameters added to some existing endpoints. I don't anticipate any breaking changes with this 🙂