How can a script adding users to the watcher list

[colinmorgan]

Good day all,

I am looking for a bit of advice/help with a script as I am pretty clueless with scripting; here is some context for what I am after:

We are using Service Now in a multi-tenanted environment where our customers are a range of different organisation with a number of users in them who use the self service portal to log incidents and interact with us.

In this scenario, all users within an organisation are separate and can only see their own incident records. Most of our organisations include a number of users who work together and need to be able to collaborate on Incident records. Service Now has the concept of watchers which would do the trick however I cannot make that function available to customer users as they can potentially lookup all of our users across all organisations which is something that we can't have happen.

What I would like to achieve if have a boolean field in the user records that determines whether that user wants to see all tickets across the organisation or not. If they chose to see it all, I would like a business rule to add all those users to the watcher list upon the creation of the incident.

Setting this up is pretty straightforward up to the point of the script bit which would have to lookup the users assigned to the organisation   that have that flag active and then add them to the watcher list.

Has anyone done something like this or maybe has an easy alternative i have not thought about and could share their ideas?

Many thanks in Advance!

Colin

[enigmagope]

Hi Brian,

If you could help please guide me to a create role and ACL for the following scenario.Since I'm very new to ServiceNow I don't understand how roles and ACL works. I'm not sure if it is possible or not. Help me to create role as follows

1. Creating a role for normal user:

Where user should have Read_only view to the request raised by them, also the corresponding task of the request   raised by user from "sc_task" table.

2. Creating a role for Supervisor:

In this if Supervisor has 5 team members. He should have Read_only   view   to the request raised by his team members along with the request he has raised, also the corresponding task of their request from sc_task table.

Regards,

Gope

[Brian Dailey1]

Hi Gope,

Sorry for the delayed reply, I've been out for a bit.   To give you an (extremely) simplified explanation of how roles and ACLs are used, you could think of it this way...

1. ACLs are what define the conditions needed to get permission to access to something (e.g., to a request record)
2. Roles are an object that you can assign a grouping of permissions to that have a common purpose (e.g., the permissions necessary to manage Service Catalog items/categories/etc. are granted to the catalog_admin role)

In that way, roles act as an intermediary for assigning permissions.   You define the ACLs/permissions on a table/field/etc to grant permissions to it, and then can add required roles to that ACL.   Those roles can then be given to groups or individual users to pass along those permissions.

To address your specific questions:

1. A "normal user" is one that usually does not have any roles assigned to them, but the conditions in an ACL still allow you to identify them.   The access you are looking to grant already exists... Take a look at the out-of-box security rules (ACLs) on the [sc_request] table, you should see one with a name of just "sc_request" and a condition of:
   
   opened_by=javascript:gs.getUserID()^ORrequested_for=javascript:gs.getUserID()^EQ
   
   This allows read access if the current user opened the request or if they are the "Requested for" user.   You can create a similar rule on [sc_task] by simply changing the condition to include the relationship from the Task through it's parent Request to the same user fields (opened_by and requested_for), e.g.:
   request.opened_by=javascript:gs.getUserID()^ORrequest.requested_for=javascript:gs.getUserID()^EQ
   
   
2. This is a little more complex, but similar exercise... it would depend on which field you are using to identify what constitutes a *team*.   For example's sake, let's assume this would be the user's department field.

• You could create a role for Supervisors.
• Grant this role to those users who in charge of a team.
• Setup an ACL for read access:
  • Set the ACL's condition to make sure the current user's Department is a match to that of the opened_by or requested_for user:
    
    opened_by.department=javascript:gs.getUserID().getDepartmentID()^ORrequested_for.department=javascript:gs.getUserID().getDepartmentID()^EQ
    
  • Add your Supervisor role to the required roles for the ACL

When both of these items (condition and role) are met, the person should be able to read the record.

Hopefully that helps you get started.

Thanks,

-Brian

[enigmagope]

Hi Brian,

Thank you for spending time on giving me such an explanation. I understood it very well now.

Will try this out and get back to you

Regards,

Gope

[Brian Dailey1]

Glad to help.  

-Brian.