Which roles are required for security incidents table read and write access?

[RD2]

Hi,

We have a web access only user with the admin role selected.

We tried to create a role with access to the following tables only:

1. sn_si_incident.do (read/write access)
2. sys_journal_field.do (read/write access)
3. sys_user_group_list.do (read access)
4. sys_user_list.do (read access)
5. sys_choice.do (read access)

We have created a new user with this role and in the application the admin user works as expected but this one (the new user) does not.

User:

In ACL settings for all tables --> Type: record

In the table “sys_choice” we had the option to add the * and in the table “sn_si_incident” there is not such option.

In the table “sn_si_incident” we received the error message below:

 com.glide.processors.soap.SOAPProcessingException: Field(s) present in the query do not have permission to be read

Further more: Which roles are required for security incidents? There are any other roles required except the "soap" role and the role I have created which contains the tables as described above?

Thanks!

[Manish Vinayak1]

Hi Anna,

I believe security read[sn_si.read] is required for having read access to the security incident table. You can find the details on the different roles on security incident module in the following link:

https://docs.servicenow.com/bundle/geneva-security-management/page/product/planning_and_policy/refer...

Here's the part of the documentation which mentions about role having readonly access:

security read [sn_si.read]

Has read-only access to security incidents.

sn_si_cmdb_read

Hope this helps!

Cheers,

Manish

[RD2]

Hi!

We tried the above but still not working as expected.

We just need to create  a web access only user with minimum access rights in security incidents. We do not want to use admin role or else. We want to create a web access only user with the access below only (minimum access, nothing else):

• sn_si_incident.do (read/write/create access)
• sys_journal_field.do (read/write access)
• sys_user_group_list.do (read access)
• sys_user_list.do (read access)
• sys_choice.do (read access)

Since option 1 (as described in my origin post above) did not work as expected, we have done the below and seems to be working correctly.

We tried the below and it seems to work as expected.

Created a user with roles:

• sn_si.analyst
• soap
• Test_1

These tables are connected with the role "Test_1":

• sys_journal_field.do
• sys_choice.do

By set up all the above, there is no need to setup/connect the tables:

• sn_si_incident.do (read/write/create access)
• sys_user_group_list.do (read access)
• sys_user_list.do (read access)

with the role "Test_1", so we have removed them from the ACL.

--> The question now is what is the difference between the role "sn_si.analyst" and the role "sn_si.basic" ??

Because we tried to use the role "sn_si.basic" instead of using "sn_si.analyst" along with the roles "soap" and "Tes_1" but it does not work as expected.

We just need to create  a web access only user with minimum access rights in security incidents. We do not want to use admin role or else. We want to create a web access only user with the access below only (minimum access, nothing else):

• sn_si_incident.do (read/write/create access)
• sys_journal_field.do (read/write access)
• sys_user_group_list.do (read access)
• sys_user_list.do (read access)
• sys_choice.do (read access)

Thank you in advance.