SOW catalog item/task variables are displaying differently than in classic UI

BurtCrepeault-E
Giga Guru

Hi all,

 

We have quite a few catalog items and flows to handle them, some UI policies and client scripts to control what is displayed on the classic forms, where agents do their work.

 

I'm looking into SOW for our service desk, and I've noticed that in SOW (Washington DC version), catalog item and task variables don't seem to obey the same rules about what is visible or not. For example, I have a catalog item that will display certain fields depending on a few user selections, but in the SOW, all fields are visible in the requested item. Furthermore, some fields should be visible on tasks (based on client scripts and selection in Flow), but none show up under SOW.

 

Am I missing something, or is SOW just not that well suited for catalog requests, items and tasks just yet? 

1 ACCEPTED SOLUTION

BurtCrepeault-E
Giga Guru

Ok, i just figured it out, and it was not something I was missing but this here line that made the client script crash:

g_sc_form.setReadOnly('company', false);

Wrapping this in a try-catch block solved the issue.

 try {
  g_sc_form.setReadOnly('company', false); 
 }
 catch(e) { }

 

I just wish there weren't so many ways to reference fields on catalog/classic/workspace forms.

 

Speaking of which, what's your universal formula for writing scripts that work everywhere?

View solution in original post

5 REPLIES 5

BurtCrepeault-E
Giga Guru

Ok, i just figured it out, and it was not something I was missing but this here line that made the client script crash:

g_sc_form.setReadOnly('company', false);

Wrapping this in a try-catch block solved the issue.

 try {
  g_sc_form.setReadOnly('company', false); 
 }
 catch(e) { }

 

I just wish there weren't so many ways to reference fields on catalog/classic/workspace forms.

 

Speaking of which, what's your universal formula for writing scripts that work everywhere?