budibase
budibase copied to clipboard
Signature field and component support
Description
Enhance your app with direct signature capture in Budibase forms!
- Internal data sources now directly support a
Signaturedata type. - Forms can now capture and store signatures with the
SignatureFieldcomponent type. - Signatures are stored as
.pngfiles and can be embedded in your applications. - Supports
mousecapture and alsotouchentry for mobile users.
Addresses
- https://linear.app/budibase/issue/BUDI-8104/signature-component
Bug- Single attachment validation behaviour was missing. It has now been added and supportsRequiredandMax upload sizeoptionsBug- added support for single attachment type in the edit row modal.
Screenshots
View and edit signature in the data section
Capture signatures in your app forms!
Launchcontrol
Signature field support added to internal datasources and forms.
Feature branch env
Great work Dean, this will be a well-used feature, I'm sure.
One thing I have noticed is that it still works when the form is set to disabled, both in the builder and on the published version.
Great work Dean, this will be a well-used feature, I'm sure.
One thing I have noticed is that it still works when the form is set to disabled, both in the builder and on the published version.
Niiice catch!
- Creating a form manually, when I use the signature component, the text/title of the signature input pop-over is
undefinedeven when the New Signature component is set up with a field name. Is the title of the popover here fetched from the schema?
Steps to replicate:
- Create a New Form with a Schema set to Custom
- Include a signature field component with a value set for Field
- Publish, and enter a signature
-
Checking
Disabledon a form block should disable all components regardless of their individualDisabledsetting. The individualDisabledsetting works well though. -
We also don't get this little menu to allow the component to be narrowed into columns - might be a nice touch to be able to have sign and print side by side in a form.
Should this new type behave as Attachments, or should we use the single attachment one? Does it make sense to have a multiple signature column? We used the single attachment to simplify bindings and similar, not sure if we should use the same approach for it
@deanhannigan I can help refactoring it to be saved as single item if needed
Should this new type behave as Attachments, or should we use the single attachment one? Does it make sense to have a multiple signature column? We used the single attachment to simplify bindings and similar, not sure if we should use the same approach for it
Hey Adria, I'm happy for the signature field backend to use the Attachments approach. I assumed that somewhere down the line we could add multi-signature support to the UI, so I think it's OK to leave it as it is.
As for the bindings, I'm less worried about them these days considering they can be evaluated by the user live in the builder. This should make using them much more intuitive to work with.
Not sure if it happens everywhere, but using firefox I am getting the following:
That's really odd. It should be confined to the canvas bounds. I tried to replicate on the latest Firefox(MacOS) but couldn't get the same behaviour. Were there any console errors or specific steps you followed?
@adrinr, any luck reproducing this issue? I still haven't been able to reproduce.
Gave this a go myself, Ubuntu + Firefox, all seems to be working well with my graphics tablet
Takes a little bit of getting used to due to it not starting immediately where you click, but works nicely!
Bit of a random one, but if you just click (don't drag) you get lines shooting in from the top left... Not a massive issue lol unless there's an easy fix.
Edit: as @mike12345567 pointed out it probably actually does need fixed if possible, because it would be impossible to dot an "i" otherwise (you'd get a weird line in the top left).
Edit 2: I can see you dotted i's successfully in your demo video, so I'm puzzled.
@aptkingston there appears to be a recent issue around this on the framework itself https://github.com/jakubfiala/atrament/issues/99
Switching to the version from 3 weeks ago might fix the issue.
Had a call with @adrinr this morning to run through this and the error he's seeing is definitely happening. It seems that it only occurs when the component is loaded on a native/laptop monitor 🙃. The canvas get's resized to 800x400 irrespective of the configuration. This was reproducible in Firefox and Chrome. Reviewing the issue now.
This was due to devicePixelRatio being 2 for the Mac laptop screen and 1 on external monitors. Restricting the canvas to the configured size will keep it bound within the modal.
@aptkingston @mike12345567 added a fix for the issue around clicking on the canvas. The issue manifests itself if you click in exactly same area without moving. I added a check for where the last draw ended and where the pointer is on click. If they match exactly, the draw behaviour will be canned and the odd lines wont appear.
@aptkingston @mike12345567 added a fix for the issue around clicking on the canvas. The issue manifests itself if you click in exactly same area without moving. I added a check for where the last draw ended and where the pointer is on click. If they match exactly, the draw behaviour will be canned and the odd lines wont appear.
Ah I see - I think the common manifestation of this is then if you have never clicked yet, it treats it as if you've clicked in the same area since your reference point is null.
