Adding custom role definitions and retrieving again as permissions

For a project I’m working on, I needed to make a distinction between user types. Not the default read / write things, which are default of course, but my own set. So I went looking and found the customizable Role Definitions.

Basically, a custom role definition adds an option to the ‘manage rights’ section of your SharePoint site. So where the default options list the default roles like ‘Limited Read’, ‘Read’, ‘Contribute’, etc, you can add you own option to this. The big advantage is that you can let your site admins take care of setting those rights. No need to create custom groups or things like that.

Ok, so how can we create such a role? Here’s the code:


SPRoleDefinition customRole = new SPRoleDefinition();
customRole.Name = "My custom role";

site.RootWeb.RoleDefinitions.Add(customRole);
site.RootWeb.Update();

Not too bad, right? Make sure you have enough rights to do this, so run in elevated mode when nescessary.

Ok, now you’ve assigned your role to a user or group and you want to check if your user has the permissions needed. This is a bit more confusing, because there are a couple of ways to get the roles and not all of those work like you would expect.

First, theres the SPUser.Roles collection. But that’s deprecated, so there’s no real need of looking into that, apparantly there’s a better way.

Then there’s the RoleAssignments property of a web or list. This contains all the assignments made, and it’s also the place you need when you want to programmatically assign a role to someone. While I’m at it, let’s do some more code for that too:


SPRoleAssignment roleAssignment = new SPRoleAssignment(user);
SPRoleDefinition roleDefinition = web.RoleDefinitions["My custom role"];

roleAssignment.RoleDefinitionBindings.Add(roleDefinition);
web.RoleAssignments.Add(roleAssignment);

Ok cool, so if this adds my user to my custom role, it’s probably also the place to look for the assigned rights, right? Well it may seem so, and this works as long as you’re assigning roles to a specific user and group and querying the assigned roles for that particular user or group. But it fails as soon as you’ve got indirect rights assigned on your site. What’s indirect rights? Well suppose you’ve got an active directory group setup and you assign your custom role to that group. Your user is in the group, so when you query the roles for your user, you expect the custom role to show up. But it doesn’t, since it’s not assigned to you specifically, but to the group you belong to. Those are indirect rights.

So now the final part: how to get the correct set of roles for a user. Check out this code snippet:


SPPermissionInfo info = web.GetUserEffectivePermissionInfo(user.LoginName);
SPRoleDefinition roleDefinition = web.RoleDefinitions[roleName];

foreach (SPRoleAssignment roleAssignment in info.RoleAssignments)
{
if (roleAssignment.RoleDefinitionBindings.Contains(roleDefinition))
result = true;
}

As you can see, there’s seperate method called GetUserEffectivePermissionInfo. This is available on all things with rights involved. This method doesn’t only query you user object, but also handles indirectly assigned rights. But be aware, calling this method requires enough permission to enumerate rights, and default readers or contributors don’t have that permission. So in most cases you probably need to run this code passing an elevated SPWeb object:


/// <summary>
/// Checks is a user is enrolled in a specified role
/// </summary>
/// <param name="user"></param>
/// <param name="web"></param>
/// <param name="roleName"></param>
/// <returns></returns>
public bool IsUserInRole(SPUser user, SPWeb web, string roleName)
{
bool result = false;

SPPermissionInfo info = web.GetUserEffectivePermissionInfo(user.LoginName);
SPRoleDefinition roleDefinition = web.RoleDefinitions[roleName];

foreach (SPRoleAssignment roleAssignment in info.RoleAssignments)
{
if (roleAssignment.RoleDefinitionBindings.Contains(roleDefinition))
result = true;
}

return result;
}

,

Related posts

Long Term Support… or not?

For a project I'm working on, I needed to make a distinction between user types. Not the default read / write things, which are default of course, but my own set. So I went looking and found the customizable Role Definitions.

Basically, a custom role definition adds an option to the 'manage rights' section of your SharePoint site. So where the default options list the default roles like 'Limited Read', 'Read', 'Contribute', etc, you can add you own option to this. The big advantage is that you can let your site admins take care of setting those rights. No need to create custom groups or things like that.

[DevOps] Should you migrate onto YAML release pipelines?

For a project I'm working on, I needed to make a distinction between user types. Not the default read / write things, which are default of course, but my own set. So I went looking and found the customizable Role Definitions.

Basically, a custom role definition adds an option to the 'manage rights' section of your SharePoint site. So where the default options list the default roles like 'Limited Read', 'Read', 'Contribute', etc, you can add you own option to this. The big advantage is that you can let your site admins take care of setting those rights. No need to create custom groups or things like that.

Latest posts

Long Term Support… or not?

For a project I'm working on, I needed to make a distinction between user types. Not the default read / write things, which are default of course, but my own set. So I went looking and found the customizable Role Definitions.

Basically, a custom role definition adds an option to the 'manage rights' section of your SharePoint site. So where the default options list the default roles like 'Limited Read', 'Read', 'Contribute', etc, you can add you own option to this. The big advantage is that you can let your site admins take care of setting those rights. No need to create custom groups or things like that.

[DevOps] Should you migrate onto YAML release pipelines?

For a project I'm working on, I needed to make a distinction between user types. Not the default read / write things, which are default of course, but my own set. So I went looking and found the customizable Role Definitions.

Basically, a custom role definition adds an option to the 'manage rights' section of your SharePoint site. So where the default options list the default roles like 'Limited Read', 'Read', 'Contribute', etc, you can add you own option to this. The big advantage is that you can let your site admins take care of setting those rights. No need to create custom groups or things like that.

Leave a Comment

Leave a Reply

Your email address will not be published. Required fields are marked *