Sitecore Corner

Sitecore Tips and Tricks

Permissions Required To Edit Rendering Parameters

Recently we faced a problem in which we needed a role that had to be able to edit the content and the presentation details of an item in the content tree. For authoring usually the sitecore\Author is the way to go (if you don`t have any specific multi-site or language specific rules) and the obvious choice for designing is to use the built-in sitecore\Designer role. But as it seems the designer role has Read, Write, Rename, Create and Delete permissions on almost everything which is located under the /sitecore/layout and /sitecore/templates folder as it can be seen on the screenshot below.

Sitecore Designer Permissions

This was a bit too much for our needs as we were not going to use this role for creating and designing renderings or setting presentation details on template level, but we needed it just to be able to edit the presentation details of an item.

The next possible resolution was to use the sitecore\Sitecore Client Designing (or give our custom role the necessary permissions to access the designer tab and edit the sublayouts) as it already had permissions to edit the presentation details of an item. Everything seemed to work fine until we tried to set the datasource of a sublayout in the Content Manager and saw that the role lacks the necessary permissions to edit the parameter template fields.

Parameter Template No Permissions

The first confusing part was that the role had permissions on the Caching section – which might actually be a bug in Sitecore.

The second confusing part was that the role had Field Read and Field Write access on the affected fields as seen on the screenshot below:

Field Write Enabled

So after some deep diving in the Sitecore.Client and the Sitecore.Kernel Assemblies I found that the actual rendering of the field happens in the RenderField Method of the EditorFormatter class.


    public virtual void RenderField(System.Web.UI.Control parent, Editor.Field field, bool readOnly)
      Assert.ArgumentNotNull((object) parent, "parent");
      Assert.ArgumentNotNull((object) field, "field");
      Sitecore.Data.Fields.Field itemField = field.ItemField;
      Item fieldType = this.GetFieldType(itemField);
      if (fieldType == null)
      if (!itemField.CanWrite)
        readOnly = true;
      this.RenderMarkerBegin(parent, field.ControlID);
      this.RenderMenuButtons(parent, field, fieldType, readOnly);
      this.RenderLabel(parent, field, fieldType, readOnly);
      this.RenderField(parent, field, fieldType, readOnly);

The moment when it is decided if the field can be modified is the check for itemField.CanWrite. Which leads to:

    public bool CanWrite
        if (AuthorizationManager.GetAccess((ISecurable) this, (Account) Context.User, AccessRight.FieldWrite).Permission == AccessPermission.Deny)
          return false;
        if (this.ID == FieldIDs.Security || this.ID == FieldIDs.InheritSecurity)
          return this.Item.Access.CanAdmin();
        return this.Item.Access.CanWrite();

As can be seen from the code above the access for fieldwrite is taken into account is only when the permission is set to Deny. So the actual check that is happening is if there is write access on the current item (which is actually the _standard values of the /sitecore/templates/System/Layout/Rendering Parameters/Standard Rendering Parameters template).

All that said, after we gave write permissions on the _standard values of the standard rendering paramaters template – everything started working !

TL; DR  🙂

Give Write Access to /sitecore/templates/System/Layout/Rendering Parameters/Standard Rendering Parameters/_Standard Values

7 responses to “Permissions Required To Edit Rendering Parameters”

  1. Thanks! We just had this exact problem. You think it might be a bug… did you contact Sitecore about this?


    1. Hi Daniel !

      I think it might be a feature, rather than a bug.


  2. Exactly what I was looking for. Nice post Nikola!


    1. Glad it helped ! 🙂


  3. Thanks man


  4. Thanks a lot. We faced the same situation.


  5. 3.5 years later and we had this issue! Thanks for the post!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: