Date time component in interface

RE: Date time component in interface

Mike Schmitt — Tue, 14 May 2024 14:03:25 GMT

FWIW this doesn't appear to actually be doing what you're intending it to do.

The dataTime field doesn't actually save any particular value into its target until a valid (complete) date and time is passed in. I believe your RegEx is just validating against a blank input (as in returning a false positive for an error).

The thing is, the dateTime field starts evaluating the validations parameter as soon as either side is filled, but this is before the target variable has actually been passed any value. So any value added at all will cause a validation that matches on a blank value to fire, such as:

(note how local!dateTime still holds no value here).

This functionally works the same as the original input with special characters added - it causes no data to actually be passed, apparently:

Interestingly, this behavior changes when we mark the field as "required":

But this opens the door to it seemingly working *correctly* (if somewhat unintuitively) when we now click a "submit" button - at least it recognizes there is no value where a required one was expected.

RE: Date time component in interface

srinivaasant574373 — Tue, 14 May 2024 06:58:40 GMT

That is working as expected but the validation message is showing before providing the time.

anyway we are fine with that. Thank you for your response

RE: Date time component in interface

Shubham Aware — Tue, 14 May 2024 06:54:55 GMT

[quote userid="72412" url="~/discussions/f/rules/34966/date-time-component-in-interface/135261"]I tried using null check but in Pic 1 and 3 in both scenarios it will be null [/quote]

We are displaying validation for the user to remove special characters from the date. When the user removes those characters, the value becomes available in a variable. Is this not happening?

RE: Date time component in interface

srinivaasant574373 — Tue, 14 May 2024 06:37:25 GMT

,It is working but before providing the time it is throwing validation message. After time is provided the validation is disappeared.

I tried using null check but in Pic 1 and 3 in both scenarios it will be null

RE: Date time component in interface

Shubham Aware — Tue, 14 May 2024 06:09:25 GMT

You should restrict users from adding special characters. I've implemented validation using a regular expression to catch some special characters. I recommend implementing a similar approach for your validation.

a!localVariables(
  local!dateTime,
  {
    a!dateTimeField(
      label: "Date & Time",
      labelPosition: "ABOVE",
      value: local!dateTime,
      saveInto: local!dateTime,
      validations: if(
        regexmatch(
          tostring(local!dateTime),
          "[$&+,;=?@#'<>.^*()%!]$"
        ),
        "Special Character Found",
        {}
      )
    )
  }
)

Keep me posted.

RE: Date time component in interface

srinivaasant574373 — Tue, 14 May 2024 05:36:48 GMT

By default we are storing created on date if it is null. If we provide any special characters inside the date time component it is taking it as null.

Is there a way to restrict users entering special characters inside the component?

RE: Date time component in interface

Shubham Aware — Tue, 14 May 2024 05:25:02 GMT

Could you help us with code snippet?

RE: Date time component in interface

srinivaasant574373 — Tue, 14 May 2024 04:31:03 GMT

We have written a code to display the value as some default date if the value is null. Is there a way to restrict the user entering special characters inside a date time component ?

RE: Date time component in interface

Stefan Helzle — Mon, 13 May 2024 18:02:49 GMT

If I try this, the date time fields just does not accept my entered values.

You wrote: "After submitting, it is displaying the system date". What exactly do you mean with "it" and "system time"?

RE: Date time component in interface

Mike Schmitt — Mon, 13 May 2024 17:45:10 GMT

If you can reproduce that behavior readily, you should open a support case with Appian and report it as unintended behavior (and possibly as a bug).