Troubleshoot: Illegal attempt to access class 'com.glideapp.servicecatalog.DeliveryPlan' via script.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2023 06:20 AM
Our team has been coming across the following error message while impersonating our test 'enduser' account to submit a specific catalog item:
Illegal attempt to access class 'com.glideapp.servicecatalog.DeliveryPlan' via script.
[Note: this only happens when we're impersonating the 'enduser' account, and ONLY for the catalog item form we're testing out in our non-production DEV environment.]
We've been able to trace the source of the error down to the business rule 'sc_req_item_stageGetChoices', but can't seem to figure out how or what needs to be fixed here in order to eliminate the error. This is what the script currently looks like for us:
/**
* Return the list of stages for a Request Item as a choice list
*
* We first determine if the item has a workflow or a delivery plan. For delivery plans,
* we create the stages from the delivery plan tasks. For workflows, we create the stages
* from the workflow stages.
*/
function sc_req_item_stageGetChoices() {
// Fix for Service Catalog Overview homepage
// We do not have current
/* Paris.SS - STRY0010136.RITM Break Fix -> FD flows should NOT trigger DeliveryPlan */
if (!current || current.cat_item.flow_designer_flow != null) {
answer.add("waiting_for_approval", gs.getMessage("Waiting for Approval")); // always add this
answer.add("closed_incomplete", gs.getMessage("Closed Incomplete"));
answer.add("Request Cancelled", gs.getMessage("Request Cancelled"));
answer.add("complete", gs.getMessage("Completed"));
} else if (current.cat_item.workflow != null && !current.cat_item.workflow.nil()) {
// Create the choices from the workflow stages
var version;
if (current.context) {
// We have already started a workflow for the item, use its version
version = current.context.workflow_version;
} else {
// We have not started a workflow for the item yet (pending request approval) so
// determine the version we will eventually be using
version = new Workflow().getVersion(current.cat_item.workflow).sys_id + '';
}
var wfs = new WorkflowStages();
wfs.setWorkflowVersion(version, current.context + '');
wfs.getChoices(current.stage, answer);
} else {
// Create the choices from the delivery plan tasks
sc_req_item_stage_DeliveryPlanChoices(answer);
}
}
// Choices include the Delivery Plan steps if a DP is specified
function sc_req_item_stage_DeliveryPlanChoices(answer) {
answer.add("waiting_for_approval", gs.getMessage("Waiting for Approval")); // always add this
if (current.cat_item != null && !current.cat_item.nil()) {
// there is a catalog item
var planID = Packages.com.glideapp.servicecatalog.DeliveryPlan.resolvePlanID(current);
var plan = Packages.com.glide.execution_plan.AbstractExecutionPlan.get(planID);
if (plan != null) {
var tokens = plan.getSortedTokenList();
for (var x = 0; x < tokens.size(); x++) {
var tt = tokens.get(x);
answer.add(tt.getName(), gs.getMessage(tt.getName()));
}
}
}
answer.add("closed_incomplete", gs.getMessage("Closed Incomplete"));
answer.add("Request Cancelled", gs.getMessage("Request Cancelled"));
answer.add("complete", gs.getMessage("Completed"));
}
- Labels:
-
Service Catalog

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2023 07:34 AM
I am assuming that this error doesn't come for the Admin users and only triggers in case of the end user, this leads me to believe that this issue could be associated with ACL.
Since there are a few of script includes being used in this business rule, could you check if the end user role is added in the ACL of respective script includes.
An ACL for a script include should look somewhat similar to the following.
Add your end user role in the SI ACL and check if it fixes the issue.
Hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2023 07:36 AM
Hi, thanks for the response! Will check this as well just in case, but it turns out that the issue may have come from our workflow instead (as we had used custom stages). Thanks again!