Prevent Before Query Business Rule from firing

[Jeff316]

I have a Before Query Business Rule on the task table. It works great for the use case. We have a custom role called fnf_assigned_to. The person with that role can only see 'query' task records where they are in the assigned_to field. They only one these people to see task records assigned to them. This works but now, when these users click on the UI Action "Request Approval" for a change request, the change workflow moves directly to Scheduled and skips Authorize. The approvals actually generate but does not stop in Authorize state. I thought the easiest fix would be to not let the business rule run when the form they are looking at is change_request and the State is Assess. If the BR doesn't run then the change will move to authorize. I cannot find anything I place into this BR will prevent it from running when they go to use the UI Action "Request Approval".

(function executeRule(current, previous /*null when async*/) {

if (gs.hasRole("fnf_assigned_to") && (!gs.hasRole("admin")) && gs.isInteractive() ) {
var u = gs.getUserID();
var qc = current.addQuery("assigned_to", u);
}
})(current, previous);

I've tried adding conditions such as when state is not assess. current table is not change_request. when state changes to authorize

[Michael Fry1]

This is limiting results returned when querying tasks but you're saying it's affecting Approvals? If you disable this rule, do the approvals come through? Do the approvers have the approval_user role?

[Jeff316]

The approval WF works fine, has for years. It this new small BR that runs before query to only allow the users with this role to see/query task where they are in the assigned_to field. That part works. I was surprised to see when this user then tries to "request for approval" on a change request UI action the WF not behave correctly. I don't see the connection. 

It's only when I gave one user this added role that only makes this BR  query fire. When that user clicks "Request for Approval" UI ACtion on the change request. The approvals generate but the WF doesn't wait for the approvals it moves onto the WF activity to move the state to Scheduled. Rather than trying to make this WF accommodate one user since the WF has worked for years, I thought I would try to Not have the BR fire when this user needs to "request for approval". I can't even see a way to modify the WF to work for this one user when it already works so well.

[Jeff316 · Accepted solution]

I found the answer through some trial and error if anyone needs to invoke a similar business rule to restrict the logged on user from seeing task not assigned to them.

[danr2c2]

Would you mind sharing your solution?  I'm facing a similar problem and would like to know what worked for you.  Thanks!