Error in "non mandatory" date field in generic form

Camunda 7 Topics Discussion & Questions
1

Hello,

First of all, I’m not sure if this is the right place to report bugs or issue questions… Please correct me if I’m in the wrong place :wink:

Lately, I’ve been using a generic form to retrieve a date. This input should be optional (without the tag ‘required’).
However, if I do not select a date with the date picker, it generates an error message…

Here is the BPMN code corresponding to this section of the form:

camunda:formField label=“Date Courrier” id=“dateCourrier” type=“date”

And here is the error message when submitting the form:

The process could not be started. : Cannot instantiate process definition Incoming_Courrier:3:5d056f85-f1da-11e5-96ef-28b2bd14fbc2: Could not parse value ‘’ as date using date format ‘dd/MM/yyyy’.

Thanks in advance for your help,
François

2

Anyone with any feeback ?

3

Hi @Francois_Barthelemy,

Sorry for the late response. Can you please share the entire form (or reduced to the field in question)? Also, which Camunda version do you use?

Cheers,
Thorben

4

Here is the code for the form:

<startEvent id=“Incoming_Courrier_1” name=“Infos courrier entrant”>
<extensionElements>
<camunda:formData xmlns:camunda=“http://activiti.org/bpmn”>
<camunda:formField label=“Nom du courrier” id=“NomCourrier” type=“string”>
<camunda:validation>
<camunda:constraint name=“required” />
</camunda:validation>
</camunda:formField>
<camunda:formField label=“ID SAP” id=“idSAP” type=“string” />
<camunda:formField label=“Descriptif” id=“DescriptifCourrier” type=“string” />
<camunda:formField label=“Date Courrier” id=“dateCourrier” type=“date” />
<camunda:formField label=“Commentaire” id=“comment” type=“string” />
</camunda:formData>
</extensionElements>
</startEvent>

Also, I’m using the version v7.4.0

Thanks a lot for your help,
François

5

Hi François,

Thanks for providing the XML. I can reproduce the problem and created a bug ticket: https://app.camunda.com/jira/browse/CAM-5903

For a workaround, I see three options:

  1. Make the date field required
  2. Not using generic forms but a custom embedded form
  3. Hotfix the date form field type and replace the default type in the engine. That can be done by subclassing org.camunda.bpm.engine.impl.form.type.DateFormType. Its convertToModelValue method could return null in case an empty String is handed to it and that should avoid the exception you see. The default date type can be replaced by implementing a process engine plugin and in its postInit method, the collection returned by ProcessEngineConfigurationImpl#getFormTypes can be modified. The instance of org.camunda.bpm.engine.impl.form.type.DateFormType should be removed and an instance of your custom subclass can be added.

Cheers,
Thorben

6

Thanks a lot for your help :slight_smile:

7

I’m bringing this old topic back to life as it is the only one about this - and the proposed workaround 3 seems to be not working (at least since 7.7, but I guess it is identical for 7.6).

Please adjust the jira ticket “applies to” to all versions, as the problem is still the same.
I personally cannot understand why it isn’t fixed already and created a PR with the fix, hoping that there will be a solution by “merge click” after 18 months.

Until the bug is fixed and a new camunda-engine is available I’d like to implement a workaround.

@thorben wrote:

That can be done by subclassing org.camunda.bpm.engine.impl.form.type.DateFormType. Its convertToModelValue method could return null in case an empty String is handed to it and that should avoid the exception you see. The default date type can be replaced by implementing a process engine plugin and in its postInit method […]

this all works fine (using the corresponding camunda maven archetype). But now it gets complicated/confusing (with the 7.7 code base)

… the collection returned by ProcessEngineConfigurationImpl#getFormTypes can be modified. The instance of org.camunda.bpm.engine.impl.form.type.DateFormType should be removed and an instance of your custom subclass can be added.

Seems like this isn’t useful any more (or I don’t understand it). While its possible to do

processEngineConfiguration.getFormTypes().addFormType(new FixDateFormType(datePattern));

we immediately must question what datePattern we want to add. This question leads to parseFormPropertyType in FormTypes.class and shows it is actually extracted from the Element. Which brings us back to the question: where should we insert our bug-fix? Overriding FormTypes.class, too (using our FixDateFormType instead of DateFormType) and directly overriding the previously set FormTypes by doing processEngineConfiguration.setFormTypes(new FixFormTypes());?

Any help (and a merge of the PR) would be welcome.

8