Due to a recent mishap, our client is requesting that when a Content Author tries to edit an item we first check to see if the item is used as a datasource for any items that the Content Author does not have permission to edit, and deny editing (write/delete/rename) permissions if so.

Does anyone know a good way to do this?

Note: I added my working idea as a possible solution, but I'm not super happy with it right now. It's a lot of effort and I am very concerned about the performance toll that it will take.

Sitecore Architecture

In the Sitecore architecture at a site level, there are two locations where I store rendering datasources:

  • Page Content Library (PCL): under the page item; page-specific datasources that are not used by any other page
  • Shared Content Library (SCL): under the site item; site-specific datasources that can be shared by renderings on multiple pages

Visual Example of the Issue

Consider the following Sitecore tree structure:

|- MySite
|--+- Global Settings
|--+- Shared Content Library
|--|--+- Banners
|--|--+- Headlines
|--|--+- Callouts
|--|--|--+- My Shared Callout       * Dynamically deny permissions to this item
|--|--+- ...
|--+- Home                          * "My Shared Callout" used; no edit permissions
|--|--+- Page Content Library 
|--|--|--+- Banners
|--|--|--+- Headlines
|--|--|--+- Callouts
|--|--|--+- ...
|--|--+- About                      * shared datasource used; has edit permissions
|--|--|--+- Page Content Library
|--|--|--|--+- Banners
|--|--|--|--+- Headlines
|--|--|--|--+- Callouts
|--|--|--|--+- ...
|--|--+--+- ...

Note that the callout component, "My Shared Callout", is shared by a rendering on both the Home page item and the About page item. Note also that in this example, the specific content author doesn't have permission to edit the Home page item but does have permission to edit the About page item.

In this example, in order to allow the Content Author to edit all of the content for the About item, he must have permission to edit shared datasource content in the Shared Content Library. However, if a particular datasource is used by a rendering on a page item that the Content Author doesn't jave permission to edit, then this would mean that the Content Author could edit content for a page that (s)he does not have permission to edit.


One possible solution is to create a rule that runs either on:

  • item:open if user shouldn't be able to read the item if denied editing access
  • item:lock if user shouldn't be able to lock and edit if denied editing access
  • item:saving allow user to make changes but not save if denied editing access
  • etc.

The rule's condition and action logic would read similar to the following (shortened for readability on SSE)

when current item is descendant of item with the Shared Content Library template 
    and when current user does not have write access to all uses of current item
Deny user access to item and display "Editing permission denied..." message

In order to do this, you would need the following:

  1. Event Handler to run the rule
  2. Rule Settings items (with necessary rule context folders, definitions, tag(s), element folders, etc.)
  3. Custom condition to check ancestors of the current item to see if any are "Shared Content Library" items
  4. Custom condition to check datasource dependencies of the current item to see there are any that the user doesn't have access to. There are many ways to do this: you could use a powershell script; you could run the Sitecore.ContentSearch.Pipelines.GetDependencies pipeline (depending on your implementation and version); etc.
  5. Custom action that calls a command to display an error message to the author that explains why they cannot edit the item

Performance Consideration

The biggest problem is that this could seriously slow down the Sitecore Client and heavily impact the Content Authoring experience, so you should should strongly consider caching the output of each of the custom conditions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.