How to limit Sitecore Language Write to only certa

Question

In our Sitecore implementation, we have branch editors who will need language write access to both English and their native language (e.g. German). However, we have certain portions of our content tree where the English version should not be editable by those branch editors, but the native language version should.

To give a specific example, if we have a product page that has some global information on it (e.g. a part number), and some localizable information on it (e.g. a description field), we're using field level security to lock down the global (part number) fields, but need a way to ensure that a German editor, for example, can create a German version of the item and put in their translated localizable (description) text, but cannot inadvertently switch to and update the English version of that description.

I understand about setting language read/write on the System > Languages for certain roles. We've got that part covered. What I am wondering about is if there's a way to effectively accomplish the following type of scenario, for a hypothetical content editor who has write access to English and German language versions:

• Home
  • Item 1 (editor has write access to both English and German versions)
  • ...Sub Item 1
  • ...Sub Item 2
  • Item 2 (editor has write access to German versions only)
  • ...Sub Item 1
  • ...Sub Item 2

Thanks in advance for any suggestions.

Answer 1

As far as I know, the native Sitecore security model is deficient in this regard. Language Read/Write access cannot be localized to a given part of the content tree. That is, if you can edit a language, you can do so on all content items for which you have write access.

However, I think you can accomplish your requirements using a combination of the saveUi pipeline and the getContentEditorWarnings pipeline.

saveUi

In this pipeline you'll need a processor that checks whether the user should be able to edit the given content in the current language. I'll leave it to you as to how this is configured / determined (XML configuration? user access to a language-specific item in a branch of the content tree?), but if the user should be denied access, you can prevent the save.

public class CheckLanguageWritePermission
    {
        public string WorkflowStateID { get; set; }

        public void Process(SaveArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            Assert.IsNotNull(args.Items, "args.Items");
            foreach (SaveArgs.SaveItem item in args.Items)
            {
                Item item2 = Sitecore.Client.ContentDatabase.Items[item.ID, item.Language];
                    if (/* user should not have permission*/)
                    {
                        AbortSave(args);
                        return;
                    }
            }
        }

        protected void AbortSave(SaveArgs args)
        {
            if (args.HasSheerUI)
            {
                SheerResponse.Alert("You do not have permission to edit this item in the current language.");
                SheerResponse.SetReturnValue("failed");
            }
            args.AbortPipeline();
        }
    }

getContentEditorWarnings

Since you can't prevent the user from actually editing content with this approach (just saving it), you should probably provide a warning that says as much.

public class CheckLanguageWritePermission
{
    // Methods
    public void Process(GetContentEditorWarningsArgs args)
    {
        Item item = args.Item;
        if (/* user should not have permission*/)
        {
            GetContentEditorWarningsArgs.ContentEditorWarning warning = args.Add();
            warning.Title = "You do not have permission to edit this item in the current language.";
            warning.IsExclusive = true;
        }
    }
}

It is not a perfect solution but it does prevent undesirable edits to content. If versioning/workflow is in play, you might be able to prevent the addition of new versions altogether by overriding the UI commands for item:addversion and item:checkout.

Determining access rights could be tricky, the best way to go about that would depend on your specific business rules.