Highlighted
Acclaimed Contributor.
Acclaimed Contributor.
781 views

rights\ability to add\edit\delete CI for some operators

How can i limit ability for some operators to 

Add\delete\edit CI only for the specified type\subtype\... (or condition for other fields) fo CI

 

0 Likes
9 Replies
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: rights\ability to add\edit\delete CI for some operators

What version of HPSM are you running?

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: rights\ability to add\edit\delete CI for some operators

9.32

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: rights\ability to add\edit\delete CI for some operators

Some group(s) of operators must be able to edit only some type of CI.

Or another words - the specified group must have access(to edit) only for specified type of CI.

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: rights\ability to add\edit\delete CI for some operators

There's a couple of ways you can solve this.  

In the simplest OOB method, the system uses the user's Configuration Management Profile to determine which CIs they have rights to.  In the 'Device Type Restrictions' tab, you can list out the specific CI Types the operators with that config profile have the rights to update.  This removes some flexibility and can add maintenance to tracking each of the possible config profiles.

The other OOB method is to use a combination of the Configuration Management profiles and some changes to the Object record for the device table.  If you set the 'Update' dropdown in the profile to 'Workgroup' and then set the value of the 'Workgroup' fields in the Object record to something that makes sense (like assignment or support.groups or something like that) then the system will evaluate whether the operator viewing the record is a member of the assignment group listed in the workgroup fields and give (or restrict) rights based on those values.

The more custom method that gives greatest flexibility is to modify the 'am.display.init' Process record and the 'am.view' State record.  In the State record, there's a field 'Input Condition'.  OOB, it should be set to something like:
evaluate($L.tableAccess.update)

You could put code in the am.display.init Process record to populate a variable based on whatever condition you want - something based on the user's assignment groups, capability words, the day of the week; whatever you want - to populate a variable as true or false... like -
if (type in $L.file="bizservice" and $lo.ucapex="ICMAdmin") then ($L.can.edit.this.ci = true)

Then, set the 'Input Condition' in the State record to use your variable instead of the OOB value... 
nullsub($L.can.edit.this.ci,false)=true

As the record displays, the system will evaluate your expressions in the am.display.init Process to set the variable, then use the value in that variable to determine whether to lock down the record or not.

So, depending on the complexity of your need and how fine-tuned you need to set your rights, you've got a couple of options.

Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: rights\ability to add\edit\delete CI for some operators

$lo.ucapex="ICMAdmin"

1) How do i need change this condition to search one value from array of capability words ?

2) Or if i need search whether the operator is in a specified "assignment group" of the array of groups to which his belongs ?

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: rights\ability to add\edit\delete CI for some operators

1) use 'isin' and curly brackets.  Like:
$lo.ucapex isin {"SysAdmin", "ICMAdmin"}

2) $lo.pm.assignments

Using RAD Debugger, you can view variables with the appropriate command - gl for Global Variables (the ones that start with $G or $lo), lo for Local Variables (the ones like $L.file, $L.object, $L.fc, etc) and va for regular variables.  Then, you can examine each one and see what the contents of each variable is

Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: rights\ability to add\edit\delete CI for some operators

 

What is the business logic:

In CI there is field - sub.subtype 

Operators from some assignemt group must have rights to edit CI with some sub.subtype

For example:

- sub.subtype field can have values (to simplify): 1, 2, 3, 4

- There is a set of assignemt groups (to simplify): group1, group2, group 3

Rights1: Operator from assignemt group = group2 must have rights to dit CI only if sub.subtype field = 3

Rights2And operators from assignment group = group1 must have rights to edit CI for sub.subtype = 1 or 2

What i did:

1) create in FC for login.DEFAULT new global variable

$G.ci.s1={3} - this is to store array of value of sub.subtype field for assignment group = group2 (in future i can add, if need, more values)

2) now i must set in PROCESS for am.display.init initial expressions: 

if (index(sub.subtype in $L.file, $G.ci.s1)>0 and index("group2", $lo.pm.assignments)>0 or $lo.pm.assignments="mygroup) then ($L.can.edit.this.ci=true)
if (index(sub.subtype in $L.file, $G.ci.s1)<1 and index("group2", $lo.pm.assignments)<1 or $lo.pm.assignments="mygroup") then ($L.can.edit.this.ci=true)

I (and operators from group2 and others groups) see all CI in read mode.

 

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: rights\ability to add\edit\delete CI for some operators

Well, you have a syntax error in your script; I'm assuming that's just a typo as you have copy/pasted:

if (index(sub.subtype in $L.file, $G.ci.s1)>0 and index("group2", $lo.pm.assignments)>0 or $lo.pm.assignments="mygroup) then ($L.can.edit.this.ci=true)

You're missing a closing quotation mark -  $lo.pm.assignments="mygroup needs a closing quote.

Second, what's the value you've got in the Input Condition field of the am.view States file?  And have you set up the users' profiles correctly so that they have access to the Configuration Management module in the first place?

Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: rights\ability to add\edit\delete CI for some operators

1) Yes, I'm missing a closing quotation mark but only here 🙂 

2) For state i left the old condition and added a new:

evaluate($L.tableAccess.update) and index(type in $L.file, $G.icm.types)=0 and nullsub($L.can.edit.ci, false)=true

3) The user profile is set for a long time and works fine, and only after changes in state and process they get only read access to the record.

 

I even try to set initial expressions before this 2 lines 

$L.can.edit.ci=false

And condition for state

evaluate($L.tableAccess.update) and index(type in $L.file, $G.icm.types)=0 and $L.can.edit.ci

get same result

 

Looks like the value of the variable $L is not passed to STATE

 

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.