ACL Script help

will_smith
Mega Guru

Hello, I am needing some help with an ACL on a custom table. I have a UI action that is ran from the incident table that shows the u_temp_credential table and writes some fields to it. Then ONLY the logged in user should be able to see the u_temp_credential table to see the username that was created just for them. When I impersonate the user I get a security constraints error. I appreciate all of your help from the start, as I'm learning ACL's - they remind me of Windows server group policies, ugh!

For an ACL, is a record type the same as a field on a form?

ACL-WESCODEV - ServiceNOW.png

answer = ifScript();

function ifScript(){

  //gs.log('ACL: sys_class_name is ' + current.u_parent.sys_class_name);

  if(current.u_parent.sys_class_name == 'sc_req_item'){

  //gs.log('ACL: table is sc_req_item');

  if(current.u_parent.u_requested_for == gs.getUserID() || current.u_parent.opened_by == gs.getUserID()){

  return true;

  }

  } else if(current.u_parent.sys_class_name == 'incident') {

  //gs.log('ACL: table is incident');

  if(current.u_parent.caller_id == gs.getUserID()){

  return true;

  }

  }

  return false;

}

1 ACCEPTED SOLUTION

You need two read ACLs...


1. Table level (u_temp_credential.)


ACL1.png



2. Record level (u_temp_credential.*)


ACL2.png


To put security on individual fields, then you need to put the appropriate type of ACL on the field (u_temp_credential.u_password).



Type should always be Record (for what you are doing).


Operation should determine what they can do (Create, Read, Write, Delete)



If the table was created and a role was associated with it (typical action) and you over-wrote the original read table ACL, then you will want to remove the role associated as the ACL requires the script to be true, the user to have the role, and the condition to be true.



To make this easier (now that I have more time), you can do this all using the condition builder instead of writing a script (my example is based on the incident table)


ACL_Conditions.png


View solution in original post

43 REPLIES 43

Did you insert a new or overwrite the existing. You need both.


will_smith
Mega Guru

new - which is write, which I don't have. It's tarting to make sense, thanks Mike.


You need two read ACLs...


1. Table level (u_temp_credential.)


ACL1.png



2. Record level (u_temp_credential.*)


ACL2.png


To put security on individual fields, then you need to put the appropriate type of ACL on the field (u_temp_credential.u_password).



Type should always be Record (for what you are doing).


Operation should determine what they can do (Create, Read, Write, Delete)



If the table was created and a role was associated with it (typical action) and you over-wrote the original read table ACL, then you will want to remove the role associated as the ACL requires the script to be true, the user to have the role, and the condition to be true.



To make this easier (now that I have more time), you can do this all using the condition builder instead of writing a script (my example is based on the incident table)


ACL_Conditions.png


I am just now going through these ACLs and I have some follow up questions for anyone with a few minutes. I have the following criteria, and I want to make sure my ACLs don't conflict....



  • Add an ACL for Write, restricting it to admin
  • Add an ACL for Create for ITIL role


I have the following ACLs created (non-field specific):


  1. Read on the table. (u_temp_credential)
  2. Read on all fields with role admin. (u_temp_credential.*)[admin]
  3. Read for all fields for all users. (u_temp_credential.*)
  4. Write for all fields, with role admin. (u_temp_credential.*)[admin]



A few questions so far, since I have admin overrides for all of these:


  1. Would 2 and 3 be duplicates, and couldn't I remove # 2?
    1. Or, does the requires role add some additional specificity?
  2. Would the read for all fields and the write for all fields conflict?


Thanks again in advance, these ACLs and their nuances can be tricky!


1A. Yes. Unless you want to specifically make action against a table or record controlled by an admin, you do not need to add a rule for admin access. That can be controlled by using the "Admin override" boolean value on the ACL. In this instance, you have stated that all users (regardless of role) can read, so that should be sufficient.



2A. No. To be able to write, there needs to be access to read (even if the read is more generic and of a broader scope).



Just to clarify your items above (based not having scripts or conditions)


1. Allows all access to read the table and records


2. Not necessary if employing number 3 and utilizing the "Admin override" functionality


3. Allows users to read the records associated to them only (if you are stating that they can only read their records based on our previous conversations).


4. Allows admin access to write to all records