ACL Challenge. A Field read by user's manger, and manger of the user's manager and on

[SamuelTse]

Hi,

I have a requirement to create an ACL on a field (new custom field) in the Users table. This field can only be viewed by the manger of the user, also, the manager of the manger, and keep rolling up until someone has no manager in their user profile. i.e. the field in the user table can be seen from my direct supervisor all the way to the president of the company, but not the mangers in other departments.

I created a script in ACL to loop through the reporting structure in the organization, It works but I find it to be extremely slow when I need to load the user record. I wonder if there is a more efficient way to handle this.

I hope this makes sense.

Thanks,

Sam

[Jon Barnes]

here is another possible solution: You could create a GlideList field on the user profile called "Managers" or whatever you like which would reference the sys_user table. This new field would be invisible to the users, only used by your code, so no need for users to see it.

Then, create a BR (preferably asynchronous) on the sys_user table with a condition like this: current.manager.changes().

in the script, you will run through the hierarchy of managers on that person's profile, and put each user's sys_id in that new glidelist field. You will also have to do this same calculation for any user in the downstream management structure. So, if you change the manager for user A, and user B has user A as a manager, you will need to recalculate the management structure for user A and user B. Does that make sense?

Now in your ACL, you will simply check if the current logged in user's sys_id is contained in that field, if it is, grant access, otherwise deny access.

So essentially you are offloading the calculation of management structure to the time that the manager changes instead of doing the real time calculation, which can be costly to performance.

[SamuelTse]

Hi Nathan,

I actually like your approach. I can see one problem though. If my manager's manger moves to another department, which happens often in our organization, my management structure is no longer accurate and will not be updated since i am still reporting to my manager. Just my manager's manager is changed.

In a sense, I can do a check in your BR. When my manager's manager (John) moves to another department, I will have to check if John is the manager of someone. If so, update those people's GlideList and this will keep going down the org chart until the user is not a manager.

This method may still not work. I can't afford to run it real time in case the CEO is changed, then all 5000+ records will need to be updated.

I think there is a way to get around it though. Maybe I will run a schedule job at night to update the GlideList, only run for the records with the Manager field changed that day. I need to capture this list in a custom table or something.

Great advise though. I will explore that as well

Thanks,

Sam