question Re: Users should not be able to enter a date that is more than one year in the future. in International Localization forum

Users should not be able to enter a date that is more than one year in the future.

kevin246her — Fri, 31 May 2024 07:15:41 GMT

Hi,

I need to restrict users from entering a date more than one year in advance. If they do, an error message should be displayed, and they should not be able to save the form. I've tried creating an on-submit client script, but it's not working. Can anyone suggest a solution?

Thanks in advance.

Re: Users should not be able to enter a date that is more than one year in the future.

Mark Manders — Fri, 31 May 2024 07:33:17 GMT

Create an onChange client script, showing a message and emptying the field. That way the form can't be saved, since the field is mandatory (I assume, since you don't want the form saved without a date).

Re: Users should not be able to enter a date that is more than one year in the future.

Alex Coope - SN — Fri, 31 May 2024 07:36:20 GMT

Hi @kevin246her,

This isn't really a topic for internationalization, but I can tell you that you essentially would want a server-side script (because it's more efficient - so think a before BR with a potential abort action at the earliest order on the table and a redirect back to current),

In that script you would want two Date (or DateTime variables), one representing the field value as is, one representing today (using this + 1 year) to compare against.

Use the API details here to review how to construct the use of "AddYears" in the GlideDateTime API:
https://developer.servicenow.com/dev.do#!/reference/api/washingtondc/server_legacy/c_GlideDateTimeAPI#r_GDT-addYears_N

Many thanks,
kind regards

Re: Users should not be able to enter a date that is more than one year in the future.

Alex Coope - SN — Fri, 31 May 2024 07:40:29 GMT

@Mark Manders,

This is not advisable because we have API's to addYears with GlideDateTime, so introducing maths does not factor in timezone and daylightsaving periods, also your messages are hard-coded which is an internationalization infraction called a "hard-coded string" (meaning it is never translatable),

Many thanks,
Kind regards

Re: Users should not be able to enter a date that is more than one year in the future.

Mark Manders — Fri, 31 May 2024 07:50:18 GMT

Daylight saving is a difference of an hour, how does that relate do a date field? And timezones can be ignored when you are checking on a date to see if it is a YEAR away.

Next to that: a solution was asked, without mentioning it should be translated or anything like that. Of course you don't want hard coded messages when you have multiple languages on an instance, but where was this mentioned to be a requirement? You are making assumptions that aren't based on anything. A solution was asked and based on the given information a possible solution was given. These can (and should) be tweaked to get the perfect solution, but you are getting date/time involved and translations, that were nowhere mentioned.

Re: Users should not be able to enter a date that is more than one year in the future.

Pratiksha Lang1 — Fri, 31 May 2024 12:28:37 GMT

@kevin246her

Simply create UI policy, no need of so much scripting. I have created a UI policy on change request table on planned_end_date field for you reference. give condition as below:

I have given relative after 365 days from now in condition. here in condition instead of 365 days, you can give after 1 years from now and it will be more accurate as it will consider the leap year as well.

Please mark my answer as helpful if it has helped you 🙂