Why Doesn't Mandatory Property Apply to Variable with Widget in Service Catalog?

[jmiskey]

We are building a Service Catalog for the Service Portal.   We have a Multiple Choice Variable where the user selects a Telecom Service.   One of these services is a new Mobile Device.   We have a Variable in our Catalog Item for the user to select which Mobile Device they would like.   We originally set it up as a Multiple Choice Variable, but that was rather ugly, since many (but not all) of the options have verbose descriptions.   So we instead created a Widget, that lists each option, and has the description indented under each one.

While this looks great, we have encountered an issue.   The Variable itself is not visible until the user selects the New Mobile Device option (from the Telecom Service Variable).   We have a Catalog UI Policy which makes this New Mobile Device Variable (with Widget) visible if this option is selected.   In the same Catalog UI Policy which makes these Variable visible, we also set the Mandatory property on it to be True.   While this worked when the Variable was a Multiple Choice Variable, now that it is Widget (Macro with Label Variable), the Mandatory property does not seem to do anything.   The user can make can submit the request without actually select a New Mobile Device option, and it incorrectly accepts it.

Why doesn't the Mandatory property work for these Variables with Widgets?   How can make this Mandatory?

Thanks

[jmiskey]

Thanks for the reply.

We have long moved on from this (I had posted the question back in November, I was simply responding to the question Mandar posted this morning).   The workaround we used was sufficient for us.

Quite frankly, moving from Service Catalog to Service Portal was a very painful process!   A lot of functionality was lost, and had to be re-programmed.   And working with Widgets is no easy task!   We now try to avoid them whenever possible.

[arthurcheung]

EDIT: So it would seem updating the field type impacts the rendering. There is a switch in the template that would render according to type. So if you change the type to string, for example, it's going to render a string field. So take the instructions below as for demonstration purposes only!

So the answer to the question "why" can be found in js_includes_sp.jsx file (you can have a look at this via devtools).

 function isMandatory(field) {
               switch (field.type) {
                       case 'widget':
                               return false;
                       default:
                               return !field.readonly && (field.mandatory === true || field.sys_mandatory === true);
               }
       }

The function above is called at various stages (including when the page loads) by the function "populateMandatory" (which can be found in the same file). This function maintains a list of the mandatory fields. As you can see in the function above, whenever the field is of type "widget", it will return false.

So with that in mind, we can make the service catalog widget validate our widget/macro field by "tricking" (or hacking, if you prefer) the type within our widget. To do this, simply add the following line to your client script code in your widget:

// Trick platform into thinking this field is string so that it validates
$scope.page.field.type = 'string';

  However, while this will get your validation working, it will not render your widget. This same attribute is used in the template. So this one is purely for academic purposes!