Service Portal Widgets fail when they are in sn_scportal scope due to plugin com.glideapp.servicecatalog.portal loaded too early to install the scoped app


Description

Service Portal Widgets fail when they are in sn_scportal scope. This is due to the plugin com.glideapp.servicecatalog.portal getting loaded too early to install the scoped app.

Steps to Reproduce

1) Open the record sp_widget_69deca02675003004b8d794717415a9b.
Observe the record is in the global scope, even though the com.glideapp.servicecatalog.portal plugin creates a scoped app (sn_scportal). Observe the sys_store_app record for sn_scportal does not exist.

2) Delete the sp_widget_69deca02675003004b8d794717415a9b record from the instance.

3) Delete the sys_update_xml record that got recorded for the deletion of sp_widget_69deca02675003004b8d794717415a9b.

4) Reactivate com.glideapp.servicecatalog.portal. Observe now there is a sys_store_app record for sn_scportal. Observe sp_widget_69deca02675003004b8d794717415a9b is recreated, this time it is in the sn_scportal scope and does not work.

Workaround

This problem has been fixed. If you are able to upgrade, review the Fixed In section to determine the latest version with a permanent fix your instance can be upgraded to.

The pre-Orlando workaround was to clone the OOB widget 'Requests & Approvals' (sp_widget.do?sys_id=69deca02675003004b8d794717415a9b) and change line 212 from Server Script from:

j.variables = new GlobalServiceCatalogUtil().getVariablesForTask(optionsGr, true);

to:

j.variables = new global.GlobalServiceCatalogUtil().getVariablesForTask(optionsGr, true);


Related Problem: PRB1364044