Highlighted
Honored Contributor.
Honored Contributor.
335 views

Rule error, known bug?

Jump to solution

Hi,

Wondering if anyone can tell me if this is a known bug, or offer any explanation to the following issue.

 

We have a rule that's been working in Production for over a year.   The rule runs before Transition, and is just doing some basic SQL to populate a hidden field.  Recently a small number of users in South America started receiving an error when the rule should be running.  Worth noting that we don't have any of the language packs installed. 

 

I saw reference to a few fixes that maybe apply, but unsure whether they're the same thing. 

 

Change Request: QCCR1L46470:  Problem with Apply before transition rules in a Request

 

Change Request: QCCR1L48293:   User upgraded from 8.02 to 9.14002. User has a rule in a  request type which compares 2 numeric fields A (editable  field) and B (hidden field): if A < B, then  showMessage('blabla'). This rule worked perfectly in PPMC 8.02, but in PPMC 9.14002, no matter its condition is satisfied or not, the rule  fires.

 

---

 

Below is the error text and exception trace details from the log file.  Note that the SQL statement runs perfectly fine...

 

 

 

GUID     8152476E-727F-FDD5-7E49-CEFC2A9421DF
 
Exception Stack trace

Error in SQL in Rule 20 - {1}:
Select upper(FinHealth), FinHealth from
(SELECT CASE
WHEN NVL('12.8',0) = 0 then NULL
WHEN '12.8' <= 100 then 'Green'
WHEN '12.8' between 100.01 and 110 then 'Yellow'
WHEN '12.8' > 110 then 'Red'
END FinHealth from dual) (KNTA-10521)
    at com.kintana.core.util.FLSRuleUtils.executeRules(FLSRuleUtils.java:673)
    at com.kintana.core.util.FLSRuleUtils.evaluateRules(FLSRuleUtils.java:647)
    at com.kintana.core.util.FLSRuleUtils.handleRulesForFLS(FLSRuleUtils.java:305)
    at com.kintana.core.util.FLSRuleUtils.handleRulesForFLS(FLSRuleUtils.java:62)
    at com.kintana.crt.web.ctrl.RequestUpdateController.update(RequestUpdateController.java:463)
    at com.mercury.itg.servlet.ActionMonitorFilter.doFilter(ActionMonitorFilter.java:87)
    at com.mercury.itg.servlet.HibernateSessionFilter.doFilter(HibernateSessionFilter.java:97)
    at com.kintana.core.web.filter.MLUFilter.applyFilter(MLUFilter.java:115)
    at com.kintana.core.web.filter.BaseFilter.doFilter(BaseFilter.java:68)
    at com.kintana.core.web.filter.stinger.ValidationFilter.applyFilter(ValidationFilter.java:178)
    at com.kintana.core.web.filter.stinger.ValidationFilter.doFilter(ValidationFilter.java:104)
    at com.kintana.core.web.filter.MultipartRequestFilter.applyFilter(MultipartRequestFilter.java:94)
    at com.kintana.core.web.filter.BaseFilter.doFilter(BaseFilter.java:68)
    at com.kintana.core.web.filter.ControlFilter.applyFilter(ControlFilter.java:904)
    at com.kintana.core.web.filter.ControlFilter.doFilter(ControlFilter.java:1462)
    at com.mercury.itg.servlet.I18NFilter.doFilter(I18NFilter.java:46)
    at com.kintana.core.web.filter.SchemeBasedRedirectFilter.doFilter(SchemeBasedRedirectFilter.java:64)
    at com.kintana.core.web.filter.Log4jFilter.applyFilter(Log4jFilter.java:56)
    at com.kintana.core.web.filter.BaseFilter.doFilter(BaseFilter.java:68)
    at com.kintana.core.web.filter.PerformanceFilter.applyFilter(PerformanceFilter.java:60)
    at com.kintana.core.web.filter.BaseFilter.doFilter(BaseFilter.java:68)

 

 

 

Thanks-

Danny

 

 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Honored Contributor.
Honored Contributor.

Finally decided to login with the user from my machine... and the error did come up on page load.  I was incorrect when I said the rule was running before Transition.

 

However, it's the same issue.  The SQL is valid in the error. 

 

Since I can now reproduce it, that would rule out regional settings being the cause.

View solution in original post

0 Likes
48 Replies
Highlighted
Absent Member.. Absent Member..
Absent Member..

Hi Danny,

 

I am wondering if you can send me the whole serverlog where this error is shown.

 

Best regards,
Randall

-- Remember to give Kudos to answers! (click the KUDOS star)
"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Contributor.
Contributor.

Hi Danny,

 

I believe you are running in to the same issue described in KM00729820 .

 

Check the Field Level Security on any Table Component as it relates to the Users in South America.

 

The workaround is to remove the Field Level Security (the User does not have Edit permission to update the Field) or use "Apply on field change" Rule instead of "Apply on Save" Rule.

 

-Mike

 

_________________________________________

Defect QCCR1L45150 - "Before Save" rule in a request type sometimes produces an error "Failed to execute Rule #":


- QCCR1L45150 will cause errors for users "Failed to execute Rule#...", though there is nothing wrong with that rule
- QCCR1L45150 affects only "Before Save" and "On Page Load" rules in request type; if you change the rule type to "On Filed Change" for example issues will not occur;
- QCCR1L45150 is related to field level security in request type - if there is only a single field (not related to the rule at all) in the request type with FLS defined, to which the current user does not have access to modify it, errors will occur;
- issues will not occur for users which have field level security

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Thanks for the info Mike.

 

Worth adding that the rule is not running against a table component, but there is field level security on the hidden field getting updated.

 

Sounds like it could definitely be the same issue though.  We will look into the workaround options you noted.

 

 

Is there any good explanation though why only South America users would get the error?

 

 

Danny

0 Likes
Highlighted
Contributor.
Contributor.

I was thinking they had different Security than the other other Users.

 

Like may be the Security was based off of Security Groups and they are in the "South America Users" Security Group.

 

What kind of Security is on that Field?

 

-Mike

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

 

Security on the field = viewable by Admin group only.

0 Likes
Highlighted
Contributor.
Contributor.

Oh ok, so it is just the Admins. Strange some Users would be affected and others not.  Is there a STAGE environment where Users have access to and can test there?

 

Would be good to get the issue reproduced and then make that Field Visible/Editable to see if that is indeed the issue.

 

Are the South American Users in any individual Group that may be assigned to any of the other Fields' Security?

 

-Mike

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Nope, nothing special or unique about the South America users.   We can't reproduce the problem... it seems only these users can.

0 Likes
Highlighted
Contributor.
Contributor.

If possible:

1) Give them an account that is working fine that you are testing with

2) Login with their account on your Client Machine and test again

 

See if it is actually an issue with their account or their Client Machine (may be a Regional Setting throwing something off).

 

-Mike

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

 

Reading some cases with similar issues, looks like it is related to the defect QCCR1L45150. There is one case that only the Admin user doesn't have the issue and they concluded that the issue was related to this defect.

 

Best regards,
Randall

-- Remember to give Kudos to answers! (click the KUDOS star)
"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Finally decided to login with the user from my machine... and the error did come up on page load.  I was incorrect when I said the rule was running before Transition.

 

However, it's the same issue.  The SQL is valid in the error. 

 

Since I can now reproduce it, that would rule out regional settings being the cause.

View solution in original post

0 Likes
Highlighted
Contributor.
Contributor.

I think it is due to the fact that the Field is hidden.

 

In the DEV/STAGE environment, try making it Visible and Editable to see if that helps.

 

What I belive is happening is that since the Field is hidden, there is no reference in the page to the Field, so when the Rule runs, PPM does not know what to do as the Field is not present.

 

-Mike

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.