budibase icon indicating copy to clipboard operation
budibase copied to clipboard

Signature field and component support

Open deanhannigan opened this issue 1 year ago • 9 comments

Description

Enhance your app with direct signature capture in Budibase forms!

  • Internal data sources now directly support a Signature data type.
  • Forms can now capture and store signatures with the SignatureField component type.
  • Signatures are stored as .png files and can be embedded in your applications.
  • Supports mouse capture and also touch entry 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 supports Required and Max upload size options
  • Bug - added support for single attachment type in the edit row modal.

Screenshots

View and edit signature in the data section signing

Capture signatures in your app forms! Screenshot 2024-04-08 at 17 06 45

Launchcontrol

Signature field support added to internal datasources and forms.

Feature branch env

Feature Branch Link

deanhannigan avatar Apr 05 '24 13:04 deanhannigan

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.

Link to example

mikesealey avatar Apr 15 '24 15:04 mikesealey

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.

Link to example

Niiice catch!

deanhannigan avatar Apr 15 '24 17:04 deanhannigan

  • Creating a form manually, when I use the signature component, the text/title of the signature input pop-over is undefined even 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

image

  • Checking Disabled on a form block should disable all components regardless of their individual Disabled setting. The individual Disabled setting 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. image

mikesealey avatar Apr 16 '24 10:04 mikesealey

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

adrinr avatar Apr 17 '24 15:04 adrinr

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.

deanhannigan avatar Apr 18 '24 15:04 deanhannigan

Not sure if it happens everywhere, but using firefox I am getting the following: image

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.

deanhannigan avatar Apr 18 '24 15:04 deanhannigan

Gave this a go myself, Ubuntu + Firefox, all seems to be working well with my graphics tablet image

Takes a little bit of getting used to due to it not starting immediately where you click, but works nicely!

mike12345567 avatar May 15 '24 15:05 mike12345567

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. image

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 avatar May 15 '24 15:05 aptkingston

@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.

deanhannigan avatar May 15 '24 16:05 deanhannigan

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.

deanhannigan avatar May 16 '24 09:05 deanhannigan

@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.

deanhannigan avatar May 16 '24 15:05 deanhannigan

@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.

aptkingston avatar May 17 '24 15:05 aptkingston