Why is some sharing info missing from the UI?


I’ve seen this question come up on the newsgroups, as well as internally. A user will have access to some particular Account, Contact, etc. when their role doesn’t allow it and neither they nor a team of which they’re a member is listed in the sharing dialog. How can this happen?

Well, it’s not a hole in the security model. This can happen when the reason the user has access to the object is because of cascaded security rights. Scott Colson has an overview of cascading in this blog post: http://blogs.msdn.com/crm/archive/2007/01/17/cascaded-security-privileges-and-sharing.aspx.

In a nutshell, cascading is a property of entity relationships. Cascading shows up in the customization UI on the relationship form:

When an operation, such as Assign or Share is marked as something other than “Cascade None”, it means that in addition to applying to the object on which the action was taken, it will apply to the object’s child objects as well, and the children’s children, etc. – basically the whole object hierarchy. In CRM 3.0, we added more ability to control over which specific child objects get cascaded to. This feature, called Configurable Cascading, is described in this blog post from Naveen Garg: http://blogs.msdn.com/crm/archive/2006/08/01/685573.aspx.

Let’s take a look at an example. Say you have the following simple object hierarchy:

BlogPost2_a.JPG

Let’s assume the default cascading options for sharing for the Account-Account relationship, which is “Cascade All”. Now let’s say Accounts A and B are both owned by Phil Richardson, who shares A to me with “Read” permissions. Let’s say by default I only have “User” level access, which means I can only see accounts that I own or are shared to me or a team of which I’m a member. After Account A is shared, I can see Account A, of course. In the sharing dialog for Account A, you’d see something like this:

BlogPost2_b.jpg

Because the share was cascaded, I can also see Sub-Account B, but the sharing dialog is empty:

BlogPost2_c.jpg

The sharing dialog (obviously) only displays the explicit shares, not the inherited ones. Why is that? One part of the answer is that we store explicit and inherited access information differently. In my last post, I mentioned that the table in which we store all our information about sharing, both explicit and inherited, is called the PrincipalObjectAccess table. The structure of this table has two columns per entry that track sharing rights: “AccessRightsMask” and “InheritedAccessRightsMask”. Based on the names, it should be obvious that “AccessRightsMask” tracks the explicit shares and is what shows up in the sharing dialog for Account A. “InheritedAccessRightsMask” tracks inherited/cascaded rights, which can come from sharing, parenting, or assignment (depending on whether your org setting for “Share to Previous Owner on Assign” is set to true or not). The sharing dialog does not look at this column.

But other than just some limitation of the sharing dialog, there is a reason to not show it: inherited rights can’t be changed. Cascading behavior is defined at the relationship level by the administrator as an organization-wide business rule and should not be overridden by individual users. Additionally, if individual links in an object hierarchy changed their cascading rights, the objects below them would not inherit their rights properly and things could get very out of sync.

Of course, one option would be to do what Windows security dialogs do, which is show inherited rights in a read-only form. What do you think: useful or more confusing?

Jay Grewal

Comments (5)

  1. Very useful posts, this one and the previous one on security and sharing.

    As for your question, I would definitely go for showing inherited rights in a read-only form. I think the fact that this sharing question comes up in newsgroups like you say, indicates that it’s confusing that it’s not shown in the sharing dialog.

    So, implemented in Titan? 😉

  2. Saritha says:

    Very useful info. Thank you.

    As I was reading this post, in my mind I was thinking, why not show the inherited rights as read-only… So, to answer your question, it definitely helps to show the inherited permissions as read only.

  3. Jay Grewal says:

    I’m glad you found the posts useful.  I can’t really talk about what’s implemented in Titan, but it’s good to know that you would find it useful to see the data in a read-only form.

    Let me know what other areas of the security model or platform infrastructure you would like to see discussed more in blog posts.

  4. nb5 says:

    I haven’t actually used Dynamics CRM, so take what I say with a couple of pounds of salt. However, IMHO, I think it’s probably best to make it act like Windows, if only for constitency. So: here’s another vote for readonly rights display.

  5. Dating says:

    I’ve seen this question come up on the newsgroups, as well as internally. A user will have access to some particular Account, Contact, etc. when their role doesn’t allow it and neither they nor a team of which they’re a member is listed in the sharin

Skip to main content