Highlighted
Super Contributor.. Super Contributor..
Super Contributor..
206 views

Eliminate 'Case-Sensitivity' on HPSM Approval Records

Jump to solution

I have a situation where an approval record is generated with all lowercase letters in the userid.  But, when the actual user gets logged in, they may have the user ID either in Caps or partial mix of capital and lowercase letters.  Is there any way to have Service Manager ignore the case sensitivity in the userID's

0 Likes
1 Solution

Accepted Solutions
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Eliminate 'Case-Sensitivity' on HPSM Approval Records

Jump to solution

Actually, the issue he's describing is not the case on a field; it has to do with the intersect rtecall and the index() function.

There's a documented enhancement request for this (not sure of the number off the top of my head) but the issue is in the 'approval.init' RAD application, the rtecall("intersect") function:

$L.void=rtecall("intersect", $L.err, $L.approval.intersect, $L.groups, current.pending.groups in $L.approval+future.groups in $L.approval)

So, the undocumented rtecall("intersect") is supposed to take a set of arrays and compare the results of those arrays.  In the RAD function, the first parameter, $L.err, is for any error code from the rtecall.  The second parameter ($L.approval.intersect) is an array that, after the function runs, will return a list containing the entries that are in both of the remaining parameters - $L.groups (the change groups this person can approve for and the operator() function) and the joined current.pending.groups and future.groups in this particular approval record.

You can try it out yourself using the RAD debugger with the following:

x $L.arrayOne = {tolower(operator())}
x $L.arrayTwo = {tolower(operator())} + $lo.pm.assignments
x $L.void=rtecall("intersect", $L.rc, $L.retVal, $L.arrayOne, $L.arrayTwo)

After running that, the value of $L.retVal should be the same as {tolower(operator())}

But, if you change it and try the following:

x $L.arrayOne = {toupper(operator())}
x $L.arrayTwo = {tolower(operator())} + $lo.pm.assignments
x $L.void=rtecall("intersect", $L.rc, $L.retVal, $L.arrayOne, $L.arrayTwo)

The value of $L.retVal will be {}, because the intersect function is case sensitive.

The index() function has the same problem.  Using the RAD Debugger, try:

x $L.array = {toupper(operator())}
d index(tolower(operator()), $L.array)

Right now, as I said, there's an enhancement request, but as of 9.3x, this hasn't been resolved.  I don't know about 9.4x and 9.5x

View solution in original post

2 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Eliminate 'Case-Sensitivity' on HPSM Approval Records

Jump to solution

Hello Jtonn,

hope you are doing fine.

According to your description I believe on Service Manager is not possible to ignore the case sensitivity, this only applies for BD oracle when is needed,

"Case insensitivity applies to the data, not the field names."

The fields always have a default value on this cases.

 

Carlos Villalobos R
Customer Support Engineer
If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Eliminate 'Case-Sensitivity' on HPSM Approval Records

Jump to solution

Actually, the issue he's describing is not the case on a field; it has to do with the intersect rtecall and the index() function.

There's a documented enhancement request for this (not sure of the number off the top of my head) but the issue is in the 'approval.init' RAD application, the rtecall("intersect") function:

$L.void=rtecall("intersect", $L.err, $L.approval.intersect, $L.groups, current.pending.groups in $L.approval+future.groups in $L.approval)

So, the undocumented rtecall("intersect") is supposed to take a set of arrays and compare the results of those arrays.  In the RAD function, the first parameter, $L.err, is for any error code from the rtecall.  The second parameter ($L.approval.intersect) is an array that, after the function runs, will return a list containing the entries that are in both of the remaining parameters - $L.groups (the change groups this person can approve for and the operator() function) and the joined current.pending.groups and future.groups in this particular approval record.

You can try it out yourself using the RAD debugger with the following:

x $L.arrayOne = {tolower(operator())}
x $L.arrayTwo = {tolower(operator())} + $lo.pm.assignments
x $L.void=rtecall("intersect", $L.rc, $L.retVal, $L.arrayOne, $L.arrayTwo)

After running that, the value of $L.retVal should be the same as {tolower(operator())}

But, if you change it and try the following:

x $L.arrayOne = {toupper(operator())}
x $L.arrayTwo = {tolower(operator())} + $lo.pm.assignments
x $L.void=rtecall("intersect", $L.rc, $L.retVal, $L.arrayOne, $L.arrayTwo)

The value of $L.retVal will be {}, because the intersect function is case sensitive.

The index() function has the same problem.  Using the RAD Debugger, try:

x $L.array = {toupper(operator())}
d index(tolower(operator()), $L.array)

Right now, as I said, there's an enhancement request, but as of 9.3x, this hasn't been resolved.  I don't know about 9.4x and 9.5x

View solution in original post

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.