In my previous post I wrote about some of the stuff I’ve learned about SPAuditEventType.SecRoleBindUpdate so far. Since then I’ve gained a few more tidbits of info, so I thought I’d share them with you.

I’ve discovered that the following line I provided last time will sometimes throw an SPException:

SPUser eventUser = web.SiteUsers.GetByID(principalId);

This seems to occur when the audit operation happened on a group and not a user, which means the principalId is the ID of an SPGroup in the web.

To handle that problem in your code, simply put a try/catch around the above line and call the following code if it fails:

SPGroup eventGroup = web.Groups.GetByID(principalId);

NOTE: I haven’t yet figured out if the principalId could be something other than a user or a group, but I’ll pass on the info if I find out anything else.

I also learned a bit more about the roleId and how it relates to the principalId…

From what I can tell, the following rules apply:

  • If the operation is “ensure added”, and the principalId is a group, then then roleId will indicate the permissions that were given to the group.
  • If the operation is “ensure added”, and the principalId is a user, then then roleId will indicate the permissions that were given to the user.
  • If the operation is “ensure removed”, and the principalId is a group, then then roleId will indicate the permissions that were removed from the group.

But, strangely…

  • If the operation is “ensure removed”, and the principalId is a user, then then roleId will be -1.

That last rule doesn’t make sense. I’m not sure if it’s just something on my local environment (this was tested on SharePoint Foundation) which is causing the roleId to be -1 if permissions were removed from a user. All I know is that it makes it a little trickier when writing code to display this audit stuff on a page, because you won’t be able to display the permissions removed from a user, but you can display the permissions for every other operation.

Well, that’s all the new info I’ve gained about SPAuditEventType.SecRoleBindUpdate. Who would have thought so much could be said about this little gem?

PS: This is some of the stuff I learned while working on my document auditing add-on for SharePoint 2010. DM me on twitter (@lawrencecawood) if you’d like more details. It will be for sale via Vinewave.