Differences between Editors and Moderators
MCMS has two built in approval roles: Editors and Moderators. This leads to the common misunderstanding that MCMS ships with two levels of approval - which is not correct! Editors and Moderators are not approving the same things.
To understand the difference we first need to have a look at the underlaying architecture of pages within MCMS.
Postings and Pages
With MCMS 2001 users could see two objects in Site Builder: A Page object holding the content and a Posting object which is actually an object defining at which place in the Channel hierarchy the content of the Page object should show up. For every Page object multiple Posting objects could exist - which allowed to show the same content in multiple places in the Channel hierarchy.
With MCMS 2002 users can only see a Posting object. The Page object is no longer exposed - but it still exists! You can see this when creating a connected Posting: here the same content is shared between all connected Posting. All these connected Postings link to the same Page object. And with different connected templates - which are again linked to the Posting object - the same content (which comes from the Page object) can be displayed with a different layout.
The Page object holds the following information:
- The "Name" property
- The "Description" property
- The Custom Property Collection
- The Placeholder Collection
The Posting object holds all the other information like
- The associated Template object
- The "DisplayName" property
- The "StartDate" property
- The "ExpiryDate" property
- The "IsImportant" property
- The "IsRobotFollowable" property
- The "IsRobotIndexable" property
- The "IsHiddenModePublished" property
- The "Url" property
It is important to understand the fact that every visible Posting also has an underlaying Page object before we cover the side effects of this implementation.
Editors versus Moderators
As we have learned in the paragraph before: every Posting is linked to a Template object and to a Page object holding the content.
- Editor only approve changes to the Page object - not changes to the Posting object.
- Moderators only approve changes to the Posting object - not changes to the Page object.
So whenever either a property of the Page or a property of the Posting object a member of the relevant approval role has to approve it. So if the StartDate is changed a Moderator has to approve the change. If a placeholder content is changed then an Editor has to approve the change.
One interesting aspect is changing the Name property. The Name property is hosted in the Page object - so we would expect that this change only requires Editor approval. Unfortunatelly this is not correct. You will notice that also Moderator approval is required. The reason for this is that the Name property is part of the generated URL of the item. So changing the Name property also changes the Url property and thus requires also Moderator approval.
Why do pages that require Moderator approval go out of production?
This behaviour is a design limitation in the current version of the product. The problem occurs due to the fact that the Posting object is not versioned. So there is only exactly one version of the Posting object. Changing the "IsImportant" property would then require Moderator approval. As the change cannot go live without being approved - and due to the fact that there is no other version of the Posting object holding the old value - the Posting object cannot be live any more. So although the Page object holding the content is approved the Page object cannot be live any more and the Posting is removed from the live site.
Btw: this is also the reasons that it is not possible to have a new revision of a Page with a future StartDate: there is only one StartDate and this is hosted in the Posting object and not in the Page object with the content.
The Page object on the other hand IS versioned. So if the item has been approved before the last approved historical revision will be used on the live site while the working revision is waiting for approval.
Workarounds for this problem
There are two recommended workarounds for this:
- Do not use the Moderator role in an environment where authoring is done on the production system. This should not be to much of a problem as content changes do not require Moderator approval anyway - only changes to the properties listed above.
- Implement a staging environment. In a staging environment it usually does not matter when a posting goes out of production. As Site Deployment does only deploy approved items on the production environment the items would always be visible.
