My 1st Blog, An Advanced Access Control Rule

[marcguy]

Hi I'm Marc and welcome to my 1st blog.

I work for ServiceNow professional services in EMEA and I'm going to blog about things that I come across in my every day job of implementing the tool and give examples of where customers require customisations or functionality that I think may be useful to others or may further explain how certain things work in the tool

Disclaimer: I'm not A developer nor would I call myself an advanced scripter but I have been using this wonderful tool for about 5 years (I may have some bad habits by now which you might see below, I can take it 🙂

Anyway to kick off the blog I would like to share an access control rule that I have implemented for a customer using our PPM plug in.

The customers requirement, was to be able to raise RIDAC (Risks, Issues, Decisions, Actions, Changes) against projects, programmes and portfolios and be able to give the correct resources from those PPP records the correct access control dependent on the escalation level (project, programme or portfolio)

We decided to use script in this access control rule as we couldn't use the normal roles type ACLs in this case

This particular rule runs on a Risk table and is a .* write rule which means it will apply to all fields on risk which don't have their own specific ACL rules:
I have put as many comments in as possible to try an explain what each line does....

var user = gs.getUserID(); //grab the current logged in users ID this will be used a lot below to check if they are one of the resources from fields below

if (current.state == 3 || current.state == 4 || current.state == 7){answer = false;} //if the record is closed then nobody can write (except admin because we have ticked the 'admin override' box field on the ACL

else if (user == current.assigned_to){answer = true;} //if this record is assigned to the current user then let them write to it
else if (current.state == -5){answer = true;} //this state is 'draft' which is only used at logging the risk then it goes to a state of validation.

else if (current.state == 0 && current.u_validator.indexOf(gs.getUserID()) != -1){answer=true;} //if risk is in validation state and if the user is in the list of validators then they can write

else if ((current.state == 1 ||current.state == -4) && current.u_escalation_level == 'Project')
//ok now we have an if statement above that says if state is manage or pending close and is a project level risk
//then below we are saying if the current user is either project manager(reference field), assistant project manager(glide_list field) or one of the project support officers (glide_list field) see the difference because 2 of the fields are glide_list field we have to check the user isn't contained in the list of users
{
if (user == current.u_project.u_project_manger ||
current.u_project.u_assistant_project_manager!='' && current.u_project.u_assistant_project_manager.indexOf(gs.getUserID()) != -1 ||
current.u_project.u_project_support_officer!='' && current.u_project.u_project_support_officer.indexOf(gs.getUserID()) != -1)
{answer = true;}}

else if ((current.state == 1 ||current.state == -4) && current.u_escalation_level == 'Programme')
//this is almost the same as above but we are now saying if the risk level is on programme check for programme mgr or programme PSO
{
if (user == current.u_programme.u_manager ||
current.u_programme.u_pso!='' && current.u_programme.u_pso.indexOf(gs.getUserID()) != -1)
{answer = true;}}

else if ((current.state == 1 ||current.state == -4) && current.u_escalation_level == 'Portfolio')
//again if risk is at the portfolio level check the user is portfolio manager or portoflio pso
{
if (user == current.u_portfolio.u_manager ||
current.u_portfolio.u_pso!='' && current.u_portfolio.u_pso.indexOf(gs.getUserID()) != -1)
{answer = true;}}

else
{
answer = false;} //otherwise deny write access to this record.

As you can see this is a very resource specific ACL which I have found in the PMO world is quite a usual thing opposed to the IT world just letting all 'itil' users see all incidents, in PMO world, they don't like others to see or write to their project, programme and portfolio data 🙂

We have implemented similar rule on Project, Programme, Portfolio and all RIDAC tables as well as read rules so that different users can use the PPM application but data on all levels can be secure between business depts.

Finally there is a central_pmo role which has read access to everything as this is the project management office.

anyway, first blog over, as I come across more requirements out there that I think might be useful to others I will post some more.

Thanks for reading,

Marc