How to "bypass" the setAbortAction restriction for scoped applications in a business rule

[Max Grabner]

Initial situation:

• Working in a scoped application
• Using the "OOTB" approval flow to create approvals 
• The Approval table sysapproval_approver is in Global
• Creating a scoped business rule on the approval record with a script that uses setAbortAction() will fail with something like this: "Access to api 'setAbortAction' from scope 'xxxxx' has been refused due to the api's cross-scope access policy"
• Creation restrictions across application scopes : Business Rules: You cannot write scripts and you cannot abort the database transaction.

Of course you can try to create cross scope privileges to achieve this or move the BR to GLOBAL, but the following possible workaround is much easier than that while keeping the BR inside the scoped application:

Possible Solution (while keeping everything in scope without creating cross scope privileges):

1. Move all the logic of the business rules script that would define when to abort the database transaction to a scoped script include (client callable) that would just return true or false if a specific condition is given
2. Create a scoped Business Rule and use the OOTB check box "Abort Action (abort_action)" This will work even cross scope
3. In the "Advanced" section of the business rule add a condition that just calls the script include.

The Script Include:

The Business Rule:

[Martin107]

Max that is an incredible workaround, well done. So simple but easily missed as a workaround. One thing though, I was wondering why the client callable on the Script Include. I tried it without and it and it still worked, is there a reason why you had yours as client callable?

Cheers again

[Max Grabner]

Hi Martin,

well spotted 🙂

I guess you are right. The "client callable" option in this use case is not a MUST.

As far as I remember when I wrote this article, my Script Include "LMRUtils" has some more functions that were also used within some other client scripts.

Cheers

Max

[Martin107]

I was also trying out different flavours to this and discovered a few interesting things. So using the checkbox will only invoke the same action as the setAbortAction(true) but without the benefit of being able to use setWorkflow(false). In fact I found that even when I used the in-scope scripted version using setWorkflow(false) as well, it didn't update the record but still ran the Business Rules after! I would have thought that the following Business Rules wouldn't have ran.

[CJB]

Hi @Max Grabner. Do you have any advice using setAbortAction in a scoped UI action? I'm getting the same "Access to api 'setAbortAction' from scope 'xxxxx' has been refused due to the api's cross-scope access policy" error. Thank you.

[Martin107]

Hiya CJB, 

If you are trying to do this across scopes you won't be able to. Your option is to either do your setAbortAction() in the same scope or use Max's solution above from a different scope. Be advised though, the setWorkflow(false) method is not executed, but I found that in and out of scope.

Martin

[ankit_dubey97]

Hi Max

I have replicated the solution but it's not working for me, as it's still updating the record