Filter by management hierarchy



Allow filtering of list items based on the management position of the logon user.


Often organizations need to allow managers to see list items or documents only for their own employees.

SharePoint’s security can use group membership or direct assignment to a user but has no usage to the organization structure.

Some organizations use workflow or event receivers to assign rights to an item when it is added to a list based on a custom process that checks the item’s user, his manager then his manager and so on then give only these users access to the item.

This method is flowed because of 2 reasons:

  1. The hierarchy of managers may change over time so at one point in the future, the rights to the items will not be correct. For example, a new manger will not be able to access an item that was entered for a person that reports to him because someone else was the manager when the item was entered to SharePoint.
  2. Applying detailed rights to each item causes SharePoint to create one user groups for each right and that adds a lot of data about one item which at the end reduces performance.

A preferred method would be to limit access to items based on the current management hierarchy.

Query the management hierarchy:

The assembly “Microsoft.Office.Server.UserProfiles” that works with the “User Profile Service Application” has a GetDirectReports() method in the UserProfile class that returns an array of UserProfile type. Business wise, this is all the known SharePoint users how report to a given user.

In order to get all the hierarchy of people who report to a manager and the people how report to them, we can use this method recursively all the way down to people how have no one reporting to them.

In a big tall Pyramid-type organization, this can be a very long list if we make it for managers close to the CEO level. So we can device a "how deep" parameter, that will limit the level under the person we query. This can be used in a wrapper method like:
				DirectReportsOfUser(string user, UserProfileManager upm, int howDeep, int currentDepth)    
				The method is calling itself until currentDepth = howDeep

The result is a list of "ReportTo" type (string User, int Level)


Using the query to filter a list:

For the filter to work, the list should have a field with user name denoting who the item is about or who created it.

If we want the results to include the logged on person too (not just people reporting to him) we need to add him to the list of “ReportTo“.

For the actual filtering we use CAMAL query syntax (see only we build the “<Value Type=’Text’> Value1</Value>” items with the items in the list of “ReportTo“.

To use it we need to develop a web part to show the filtered items.

If and when SharePoint will evolve to combine user defined or programmed methods in views definitions, the methods will be useful in any view an administrator can come up with less need for a developer.








About Ofer Gal

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s