How to make date text box Read-Only in Service Portal

Kyu Min · ‎11-09-2017

Hi all,

I'm kind of new developing in SN.

I need to find a way to make read-only the text box of the date variable so force the end user to use the calendar (datepicker) to select the date in Service Portal.

The image is from the standard UI. The text box is disabled but I'm able to select the date with the calendar (datepicker).

So far, I've been able to make it work in the standard UI with this Catalog Client Script:

UI Type: Both

Type: onLoad

function onLoad() {

// Checks if the form is loaded in mobile or desktop

if (window == null) {

// For Service Portal - Currently not working

//g_form.hasField('date_variable').style.backgroundColor = '#F0F0F0';

//g_form.hasField('date_variable').readOnly = true;

document.observe("dom:loaded", function(){

$('date_variable').setAttribute('disabled', true);

});

} else {

// For standard UI

g_form.getControl('date_variable').style.backgroundColor = '#F0F0F0'; // Sets gray color to background

g_form.getControl('date_variable').readOnly = true; // Sets the text box as RO

}

g_form.getControl() does not work in Service Portal.

I've researched all day and still haven't found a way to make it work in SP.

Any help is greatly appreciated.

Thanks!

sndangibbard · ‎11-11-2017

If you only need this on one specific Date variable...

Get the sys_id of the variable

Service Catalog > Maintain Items > [open item the variable belongs to]
Variables (related list) > right-click on the variable > Copy sys_id

Create a Catalog UI Policy

Service Catalog > Maintain Items > [open item the variable belongs to]
UI Policies (related list) > New
- Onload: true
- Run script: true
- Run scripts in UI type: All
- Execute if true:

function onCondition() {

var $ = this.jQuery;

$('input[id*="yourSysIdHere"]').attr('readonly', true);

}

View solution in original post

Dave Smith1 · ‎11-10-2017

I need to find a way to make read-only the text box of the date variable so force the end user to use the calendar (datepicker) to select the date in Service Portal.

Just curious... why force the user to use the date picker?

Surely the form should just be concerned with a date in the correct format, and within a valid range - irrespective of the method?

Kyu Min · ‎11-13-2017

It's because the date conversions are not working well with some dates and sometimes , it bypasses some validations.

Forcing users to use the calendar to select the date, saves me a lot of trouble with date conversions and extra-validations.

Dave Smith1 · ‎11-16-2017

Forcing users to use the calendar to select the date, saves me a lot of trouble with date conversions and extra-validations.

Shouldn't you be designing to save users a lot of trouble, rather than yourself?

That's the point of a user-centric UI experience, after all. You're only going to design and build it once, but it'll be used several times over by the end-user - so good design should prioritise the needs and experience of the consumer over that of the supplier.

Kyu Min · ‎11-17-2017

Hi Dave,

I agree with you that the design should be user centric and it should provide a consistent result every time it is used.

Since the DateTime API is not converting correctly some date formats, it will provide inconsistent results.

For example:

Let's say the system is set with this format: MM-dd-yyyy

If the user types 11-10-2017 (dd-MM-yyyy / OCT 11, 2017) This format is widely used in Latin America (and I have many Latin American users).

SN will convert to 11-10-2017 (MM-dd-yyyy / NOV 10, 2017)

So, forcing users to use the calendar to select date, it will provide consistent results every time and will save them a lot of trouble.

I hope you now understand why I'm trying to set to RO the date text field.

Thanks.

Dave Smith1 · ‎11-17-2017

Let's say the system is set with this format: MM-dd-yyyy

Date formats are a per-user custom setting; hence the system format is unimportant; the user format is.

So, forcing users to use the calendar to select date, it will provide consistent results every time and will save them a lot of trouble.

You also appear to be forcing users to adopt a format without considering what their preferences are set to.

Since the DateTime API is not converting correctly some date formats, it will provide inconsistent results.

Often, the problem isn't the DateTime API, but code that neglects to take into account user-settable preferences when trying to convert a string to a Date object. I've encountered this situation several times when dealing with US-formatted datestamps; the solution isn't about forcing the user to conform to a system standard, it's about designing systems that are sensitive to user needs.

Either way, what you're after is possible. I just hope your users don't share the same frustrations I've encountered at UI rigidity.