pm_project ACLs

[ashwinipingle]

Dear Developers,

We are using SPM on Washington release.

We have assigned role of it_project_manager to users and what we see is that the users can see all the projects in the system. What we need is that users having a Company code 4xxxx (company code starting with 4) should see only the projects where Internal Company Code is also starting with 4.  Note that both company code fields are custom fields on User and Project tables.

To do this we need to write ACLs. Should it be one ACL for Read, Write and Delete or just creating a Read ACL is fine?

Also we have written ACLs for specific fields of the project - do we have to re-write those?

If someone has already done something similar, please let know.

Best Regards,

Ashwini Pingle

[James Schwab]

Hi Ashwini,

You can do this by adding conditions to your ACL*,

*Be careful to consider the impact of editing ACLs. If you choose to proceed and modify existing ACLs for the it_project_manager role, please keep in mind the different users who may this role present and future.

You can add a condition to your Read Row Level ACL like this, replace Number with your Company Code field:

 
Because you are applying it at the Row Level, you won't need to redo your specific field-level ACLs.

hopefully that helps!

[Tai Vu]

Hey @ashwinipingle 

Let's give my approach a try. To restrict access so that users with a company code starting with "4" can only see projects where the internal company code also starts with "4," you can follow this approach:

1. Define a new Read ACL:
   • Set the Type as Deny Unless.
   • Add the appropriate role (e.g., it_project_manager).
2. Write a script condition to validate the company code association:

Sample.

answer = true; //default answer to provide access for other type of Users 
var userCompanyCode = getUserCompanyCode(gs.getUserID());
var projectCompanyCode = current.company.u_company_code.toString(); //replace your company code field
if(userCompanyCode.startsWith('4')){
	answer = projectCompanyCode.startsWith('4');
}


function getUserCompanyCode(userSysId){
	var grUser = new GlideRecord('sys_user');
	if(grUser.get(userSysId)){
		return grUser.company.u_company_code.toString(); //replace your company code field
	}
	return '';
}

Cheers,

Tai Vu

[Mark Manders]

Your best option could possibly be a Query BR on the project table to validate the company code on the user and the project and only show the projects they are allowed to see. That is, if there isn't any one that should be able to see all projects. Otherwise you need to exclude those as well.

If you have planned the upgrade to Xanadu, I would wait until then. Xanadu introduces 'deny-unless' ACL's which makes it way more easy to deny access to records you aren't supposed to see, even though you have the role to see them all. You can just deny access if the company code is not the same.
If you can't wait and the Query BR isn't an option, then yes, you need to update the existing ACL's. But without a read ACL, you can't write, so updating the read ACL should be sufficient. Just make it an advanced one, checking on the company code.