Calculate Risk BR

[Community Alums]

In our Rome instance when a user initially saves/submits a change the Calculate Risk BR triggers and assigns risk based on risk conditions. We are upgrading to Tokyo and seeing that this BR does not fire. The condition does not seem to be met. 

****CONDITION****

gs.hasRole('itil,sn_change_write') && gs.getProperty('glide.ui.risk_calculate_rule') === "business_rule" && !new RiskCalculator(current).showRiskAssessmen

The portion that fails is the !new RiskCalculator(current).showRiskAssessment() term. I am not 100% certain what this is checking for but it appears as though it may be looking to see if com.snc.change_management.risk_assessment plugin is installed. It is installed in both of our Rome and Tokyo instances. Would like some insight in what this condition is looking for.

showRiskAssessment: function() {
// Risk Assessment plugin active
if (GlidePluginManager.isActive(RiskCalculatorSNC.CHG_RISK_ASMT_PLUGIN))
return new global.ChangeRiskAsmt(this.changeRequestGr).showRiskAssessment(); //Not sure what this does???
else
return false;
},

If I remove this term altogether from the condition the BR will fire but then I get an error stating that the Risk Assessment has to be completed first. Almost like it's not taking into account the risk conditions. In our Rome instance I can remove this from the condition and it works just fine. 

Part of me wonders if a bug has been fixed in Tokyo that was allowing this to work in Rome because the BR has comments stating: This Business Rule only supports Risk Conditions. If Change Management - Risk Assessment [com.snc.change_management.risk_assessment] plugin is installed it will be deactivated. Now these comments have been there for a long time and I have never seen this BR get disabled. Even if you create a new developer instance and install the noted plugin the BR is still active. 

[Bert_c1]

I would remove the condition, and in the script set variables to each, then use gs.info() to log the values or gs.addInfoMessage() to show those on the form. Once you determine any problems, restore the condition.

On differences between Roma and tokyo, you can review the Release Notes. A Support Case may also help in learning how the feature changed.

[Bert_c1]

I tested in my Tokyo instance, it is this part of the condition that doesn't return true:

gs.getProperty('glide.ui.risk_calculate_rule') === "business_rule"

See: 

https://[instance].service-now.com/sys_properties_list.do?sysparm_query=GOTOname%3Dglide.ui.risk_cal...

and that has Choices:

None=none,Business Rule=business_rule,UI Action=ui_action

I guess if you update a change request via the form, it is considered a "UI Action".

I get "UI action" when I update a change request record.

[Chris Doernbra1 · Accepted solution]

I had to turn on the debugging for the various script includes as well as reach out to SN. Turns out we were just getting lucky and it was working in Rome because of an issue with the OOB script include. That script include has since changed and was the reason why we didn't get the expected result. To get the expected behavior we had to create a BR.

[Jeff Boltz1]

You had to write a custom BR to fix, or did the OOB script include (which one) get fixed?