When do we explicitly set CME permissions given OrganizationalItemData attributes?

Question

I'm creating a list of permission settings for an OrganizationalItemData object with the Core Service and am looking for help confirming when to explicitly set permissions in the CME.

Question

Given an organizational item and knowing its shared, localized, and permissions inheritance settings, when do we need to explicitly set permissions for it (in the CME under Properties > Security)?

API Details

Given OrganizationalItemData orgItem I can check the following (with details from the documentation).

• IsShared
  Gets or sets whether the item is shared in the current context Publication.

• IsLocalized
  Gets or sets whether the item is localized in the current context Publication.

• IsPermissionsInheritanceRoot
  true if permissions are specified for item itself; otherwise, false, if item inherits permissions from the parent item.

Example Code

I can use the Core Service to check permission settings in a given CMS. For example:

var CreatedHere = !orgItem.BluePrintInfo.IsShared.GetValueOrDefault();
var IsLocalized = orgItem.BluePrintInfo.IsLocalized.GetValueOrDefault();
var PermissionsFromParent = !orgItem.IsPermissionsInheritanceRoot.GetValueOrDefault();

I'd like to output the permissions for a given Organizational Item, but also instructions for when the CMS administrator actually needs to set properties in its publication. For example I could use a script against CMS Test to show what CMS Production might need.

Scenarios

Here's the truth of it (I think).

Shared  Local(ized)  PermissionsRoot  Set here?
No      No           No               No, set in parent in this Publication.
No      No           Yes              Yes, set in this "local" item.
No      Yes          No               Not possible. Can't localize non-shared item. 
No      Yes          Yes              Not possible. Can't localize non-shared item. 
Yes     No           No               No, set in parent item in higher Publication. 
Yes     No           Yes              No, set in this item but in a higher publication. 
Yes     Yes          No               No, set in parent item in this Publication. 
Yes     Yes          Yes              Yes

I might be wrong in my understanding of these options, but so far it seems we only need to explicitly set permissions for two scenarios:

1. For a non-shared (local) item that is a permissions root (Inherit Security Settings from Parent unchecked)
2. For a shared, localized item that is a permissions root.

Do I have the right scenarios and/or am I missing something in the 2^3 scenarios above?

Answer 1

I think you have it about right Alvin.

First of all, the only place you can ever have permissions is at an inheritance root. Secondly, normal blueprinting rules apply.

I used to draw this as a diagram with a zig-zag arrow, showing the search for permissions:

(Imagine you're a folder trying to figure out stuff)

1. Am I a local inheritance root? No - keep on looking
2. OK - so BluePrinting applies, so maybe I'm a shared folder and I'm an inheritance root via bluePrinting? Nope? OK - keep on looking,
3. So what about that folder above me in the tree? Are there any permissions there? Is it a local inheritance root? Is it an inheritance root by way of BluePrinting? Nope - keep on looking
4. And so on all the way to the top

So looking at your table: Anything where "Permissions root" is false, can't have it's own permissions, so correctly you have either no or not possible for each of these. For org items that are inheritance roots, the next question is are they local/localized or are they shared. Again you seem to have got this correct.

There's only one point of attention that I'd mention, and that is that perhaps "Localized" is the wrong name for your second column. I'd say "local" instead. An item is local if it is not shared, and this can be because it's been localised from a shared item in another publication, or because it's been created locally in this publication. I think you realise that any scripted or programmed approach you take needs to accommodate both scenarios.