There has been an important change made in the default behavior of Date and DateTime control which previously prevented it from working properly with externally bound data sources. This does not break any backward compatibility for existing applications which were not data bound even if that behavior was incorrect. Please read this carefully and if you have any questions, please contact AgilePoint Support for clarification.
Date Control
What has changed?
Till v7.0 SU1 the eForms Date control used to send the selected date in ISO format including the time (set to 00.00.00 midnight local time). From v7.0 SU2, if you drag and drop a Date control that control will send the selected date in ‘yyyy-MM-dd’ format. There will be no time component in the value.
Why this change is needed?
- Conceptually the current behavior of Date control to send back selected date with some time component attached to it is wrong. The Date control should send only date component.
- Associating the time component to the selected date and sending it in ISO format has shown wrong behavior especially when that date is data bound to other cloud services like Salesforce which would apply its own time zone conversion and if you have cross regional teams participating in workflow, it can cause a change in date. For e.g. if someone in France submits the form but the Salesforce is hosted in US, it will apply time zone conversion on Salesforce side and store the date as previous day.
Does this cause any impact on running apps:
No. In SU2 we have made eForms intelligent enough to detect the form being submitted has Date control which is data source bound and force the value to be sent in standard date only format, which is, ‘yyyy-MM-dd’. If the Date control is not data source bound then it will keep working as it was working before. Any new date control which is dragged on form surface will be correctly configured to send date as ‘yyyy-MM-dd’ irrespective of whether it is data bound or not.
The only case where you might see an error message is when a date control on form was wrongly mapped to a DateTime control in backend source. This was previously possible because for both Date and DateTime field in data source, you could select to use either a date or date time control on the form. This has been blocked now and you could only use date control for date field type in data source and date time control for date time field type in data source. Anyways using date control for date time field was incorrect. If you did that, you would see an error message. The same message would be shown if for some reason an AgilePart wrongly tries to pass incompatible value.
How this change is implemented?
- After SU2, when user drags the Date control on the canvas, the “Store Date as Plain Text, and not ISO format’ check box in the Advanced tab will be checked by default. For non-data bound controls, you could still uncheck this manually if you wanted to get old (wrong) behavior but not recommended as shown in tool tip. For data bound controls, it should not be unchecked.
2. If you bind the Date control with data source node, either by dragging data source node from Data Model tree on the existing Date control on the canvas, or just dragging the node on empty canvas (which creates the Date control on the form), then the check box ‘Store Date as Plain Text, and not ISO format’ will be checked and disabled. As all underlying data sources stores Date as only date and gives back only Date (on read operation), it makes sense to force data source bound Date control to send only Date.
3. For any reason if user wants a Date control to capture the Time component as well, then it is recommended to use DateTime control instead of Date control.
4. Because eForms’ Date control used to send Time component as well, to maintain the backward compatibility the Date control with ‘Store Date as Plain Text, and not ISO format’ check box unselected, will continue to send back Date in ISO format with time component included (00.00.00 local time). However in that case, it is recommended you check “Current Time” checkbox so that atleast correct time zone conversion is applied. Again this is just for backward compatibility and not recommended as shown in tool tip. Date should only be used as date and not date time.
DateTime Control
It is opposite for Date Time. All underlying systems like Salesforce, SharePoint, Databases expect you to pass dates in ISO format with time component so that they can apply regional settings on their side while displaying date time to user in the 3rd party system’s UI. As you might know, we have an option of sending DateTime as plain text which indicates to our form that do not apply any time zone conversion which makes sense from eForms perspective if fields are not data bound but would not make sense if fields are data bound since those underlying systems expect to do time zone conversion. This case has been handled.
What has changed?
If you have a DateTime control associated with data source node, then the checkbox ‘Store Date Time as Plain Text, and not ISO format’ in Advance tab will be unselected and disabled, making sure the control always sends back the selected datetime in ISO format. For non-data bound control, you have a choice of selecting it if you have a use case for that. For data bound control it is enforced that the date always goes back in ISO format since not doing so will always result in wrong result.
Why this change is needed?
The data sources like Salesforce, SharePoint, etc. requires the input datetime to be in ISO format as these are cloud systems accessed by users scattered in different time zones and the Salesforce/SharePoint UI has to show dates and times in corresponding timezone.
Does this cause any impact on running apps:
No. In SU2 we have made eForms intelligent enough to detect the form being submitted has DateTime control which is data source bound and force the value to be sent in standard ISO format, which is, ‘yyyy-MM-ddThh:mm:ss.fffZ’. If the DateTime control is not data source bound then it will keep working as it was working before. Even previously the default behavior was correct where the Plain Text checkbox was not checked which is what almost every client has but since it gave an advanced option of storing DateTime as Plain Text, we are just ensuring that advanced option is disabled for data bound controls to ensure consistency of data.
How this change is implemented?
- After SU2, when user drags the DateTime control on the canvas, the “Store Date as Plain Text, and not ISO format’ check box in the Advanced tab will be unchecked by default which is the default behavior even pre SU-2 so no change in that part.
- For non-data bound controls, you could still check this manually if you wanted to get DateTime in plain text if you do not want eForms to apply any timezone conversion while displaying DateTime. This is an advanced and rare case.
- If you bind the DateTime control with data source node, either by dragging data source node from Data Model tree on the existing DateTime control on the canvas, or just dragging the node on empty canvas (which creates the DateTime control on the form), then the check box ‘Store Date Time as Plain Text, and not ISO format’ will be unchecked and disabled to avoid user mistakes.
These changes are done to ensure consistency specially if these controls are data bound which as you know is a new concept introduced late last year. There are not many apps like that and even for the apps that exist, since most of them use DateTime which already had correct default behavior, no issues are reported by client. However since this has come to our attention as part of internal testing, we have enforced the rules around usage of Date and DateTime in data bound scenarios to avoid user mistakes.