Sometimes you might want to define permissions
specific to an element. In other words, you might want to break the
default security inheritance. To do this, open the Manage Permissions
page, and then click Stop Inheriting Permissions. You see a dialog box, as shown in Figure 1, informing you that you are about to break inheritance for this specific document.
Note
Notice that this is called a document
even though we are still working with a data source. This is because
all items stored in a document library are ultimately considered to be a
document.
After you break the inheritance, the yellow status bar informs you that you are applying unique permissions to this document.
Here is what happens when
we apply unique permissions on a data source. In this example, we work
with a data source called The Green Orange. The permissions inheritance
has been broken, as explained earlier. An account called BizSharp User 2
has been added with Restricted Read permissions only, as shown in Figure 2.
If we log on to the site
using the BizSharp User 2 account and open the The Green Orange data
source context menu, we can see that because we have only restricted
read permission, there is no option to edit properties (see Figure 3). However, we still have an Edit in Dashboard Designer option.
If we choose this option,
the The Green Orange data source opens in Dashboard Designer. From
there, we can look at all property settings, the connection string,
comments, and other settings. If we try to make changes and then try to
publish the data source back to SharePoint, by right-clicking the data
source and then select Save, we get the error message shown in Figure 4.
This error message occurs here because BizSharp User 2 has restricted read permission only.
Caution
Users can save any changes they make to a local
workspace. This can sometimes be confusing when users think they have
published their changes back to SharePoint. Even though the error
message provides a warning, users must be educated about how changes are
saved and published.
As demonstrated in this
section, you can apply permissions on the top-level site collection or
you can apply specific permissions on a list or list item. This allows
the flexibility of assigning permissions and explicitly specifying what a
user can do when creating and viewing PPS elements. Remember that even
though this example worked with setting permissions on a data source,
the same concept applies to any PPS element. Also remember that a child
item will always inherit permissions from its parent unless the
inheritance is explicitly broken.
