Sitecore Corner

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.

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.

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:

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)
        return;
      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);
      this.RenderMarkerEnd(parent);
    }

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

    public bool CanWrite
    {
      get
      {
        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