How to build ACLs for variables in service catalog?

[johannes5]

Hi ServiceNow Community Developers

I am trying to build an access control for variables in the requested item (sc_req_item) table. When I try this out I can see the oob fields but for variables all I see is 'variables' I cannot see the actual variable names that I would like to build acls around. Do you guys know how do I build an acl for each variable within the service catalogue. Please advise.

Thanks,

Johannes

[randrews]

Johannes perhaps it might be a better idea for you to let us know what you are trying to acomplish.. there might be a better way then starting down a long path of having to create a ton of acl's for every item in your catalog....

as an example if your goal is to lock down all variables on the task form unless the user is in the assignment group the task is assigned to i can tell you how we accomplished that...

[johannes5]

Hi Doug,

I am working on sprint story where the request is to allow ess users to update comments on any requested item record not just the one that is requested for them. There was acl on the sc_req_item table that allowed ess users to update the comments field only for their items (condition was Request.Requested For is javascript:gs.getUserID() ) this was at the table level. I took away that condition on the acl so that any ess user can update any requested item record however the problem is that as soon as I did that then all the variables are opened for update i.e. the ess user is now able to update all the variables. The oob fields on this table are still ok they still cannot update them but the problem I have is how do I prevent them from updating the variables while allowing them to update comments. I want all the variables to be locked down i.e. they must not update them.

On the incident record (which does not have 'variables') I was able to do this without a problem but on the service requests i am really having a hard time. Please advise.

Thanks,

Johannes

[randrews]

OK that helps a LOT... first question would be are the customers able to edit the variables on items they requested already.. and if so is that the desired behavior???

assuming it was a table level rule that you disabled... i would recreate it as a field level rule on all fields.. then write a separate write rule on JUST the comments field.. so that ess users are ONLY allowed to edit the comments of the item and no other field...

[johannes5]

Hi Doug,

Yes customers should be able to update variables on items they created however on items they did not create the only field they should be able to update is the comments field, all others variables they should not be able to update.

Are you saying I should write an acl for each variable that what i want to lock down. In the ess portal the customers are able to see most of the variables, they are also able to see other fields (e.g. shrt description , description) from the table but are not able to update those because they don't fall under variables that one creates using a variable editor.

I tried to create an acl for the variables but i cannot see the individual variables just like i would see the individual fields. Would you please give me an example of an acl that would run for a variable called action_item for instance.

Thank you,

Johannes

[randrews]

you can't and don't want to attempt to build and maintain acl's for variables.. it would be a full time job keeping up with just those as you build/modify items in your catalog!!!

i would start with trying to lock down all the fields in other records first at the field level.. try an acl on the table.* for write.. that locks down the fields using the same logic that the table level rule you deactivated used... this SHOULD hopefully   lock down the form for ess users when the item isn't for them.. only at the field level instead of the table level....

once you have tht working you can write an acl that allows write access to the field y ou want only...