Documentation and handling of numbers and dates in POST /submissions API

[Doreapp]

Hi, First of all, thanks for this great project !! 🙏

DocuSeal Version

1.4.2

Introduction

This issue is also here as documentation for other folks encountering the same problem as me.

Description

When using POST /submissions API endpoint with default values, the format must be:

• For dates: yyyy-mm-dd
• For numbers: Stringified numbers.

Other formats may be accepted (e.g. ISO format for dates and raw numbers), they will be properly displayed in the document, but not accepted when submitting ⚠️ :

• For dates, the user will have to input a brand new date
• For numbers, he/she will see the fields filled, but will get an error like "Please fill all the required fields"

Steps to reproduce

Create a new template with a submitter Submitter, a date field DATE and a text field NUMBER.

Using the API, create a new submission like

curl -X POST http://localhost:3000/api/submissions \
       --header 'X-Auth-Token: xxx' \
       --data-raw '{
         "template_id": 1,
         "submitters": [
           {
             "role": "Submitter",
             "email": "your@email.com",
             "values": {
               "DATE": "2024-02-08T14:26:02.349Z",
               "NUMBER": 123
             }
           }
         ]
       }'

Expected behavior

The fields should be properly filled or empty (if the values are not accepted).

Actual behavior

The fields look filled but their values are not usable for a submission:

• The date field must be fully filled by the user
• The number field must at least be edited by the user

Feature proposal

1. Add the formats expected in the documentation, near the API documentation.
2. Accept numbers passed as raw in JSON
3. Reject dates (and possibly numbers if 2. doesn't suit you), rather than allowing buggy behaviors

[omohokcoj]

@Doreapp thanks for the detailed issue report 👍 It has been already fixed in the Cloud SaaS and will be released in the open-source version on Monday.

[omohokcoj]

@Doreapp the fix has been released in the 1.4.3 docker version - please reopen if the issue still persists