OpenWGA 7.5 - OpenWGA Concepts and Features

The fields pagereaders, pageeditors and childeditors can be used to effectively set authorisations for complete page branches and determine rights in a way that is inherited hierarchically. This chapter outlines the exact way these fields work and shows usage scenarios.

The pagereaders field, titled with "Who may read this page and subpages" in Content Manager, reduces the visibility of pages of a branch to the users, groups and roles contained in the field. This includes the visibility of all content documents on this page and subpages in any state.

When the field is empty then the readers settings of the parent document are inherited, this being the "pagereaders" field of a parent page or - when on a root page - the "readers" field of the website area.

Page reader fields reduce visibility in an "additive" way down the hierarchy. This means that visibility restrictions determined for one struct entry add up to the restrictions already determined on some parent entry up the hierarchy. Or said another way: A page is visible to a user when its readers field allows read access (so is either empty or contains an entry of one of his user names, groups or roles) and also do the reader fields on all parent entries up the hierarchy, independently from each other.

It is impossible to loosen visibility constraints "down the hierarchy". When a page is invisible for some user then also all of its child pages are.

An example

See the following example hierarchy:

The website area in this example reduces visibility to the group "staff-members", meaning that all content inside this area will only be visible to members of this group (although not all of this content necessarily is visible to all members).

Documents "Home" and "News" have readers field empty, so they inherit their visibility from the area.

Document "Accounting Information" reduces visibility to two groups: "Accounting-members" and "Management". But as we said, reader fields work additive in hierarchy, so this means that the restrictions of the area are still in effect here. To now effectively express in a concise boolean rule what people are able to see this document we may follow these rules:

• All entries in one readers field are connected via "OR" to a reader field rule
• The rules of the reader field from the page (if filled) and all pages up the hierarchy are enclosed by brackets and by connected via "AND" to a complete visibility rule

Regarding document "Accounting information" this means users owning the following users/groups/roles can see the page and its content:

("Staff-members") AND ("Accouting-Members" OR "Management")

Document "Management" further reduces the visibility of itself to group "Management". So the rule for this document is:

("Staff-members") AND ("Accouting-Members" OR "Management") AND ("Management")

Effectively this annihilates the "Accounting-Members" group authorisation, determined by the parent page, for this page. So this could be shortened to the effective rule:

("Staff-members") AND ("Management")

Usage scenarios

The hierarchical page readers functionality is designed to be a secure and dependable way to reduce accessibility to certain ranges of content. Because of this there is no way to modify the reader settings done on some page for any subpage.

While it may be difficult to explain the exact impact of certain hierarchical reader field scenarios the results that emerge from the way these fields work is mostly what is expected and practical. The page hierarchy in OpenWGA Content Stores normally is organized in a way that represents the problem/responsibility domains of the stored data. When this is given then the readers field of each page can simply include the users, groups and roles of the people of that individual domain, so their content remains visible only to them.

As page branches deeper down the page hierarchy normally should represent even smaller sub-domains of their parent pages the readers fields additive nature is ideal to further reduce the visibility of these pages to the smaller group of people responsible here.

The pageeditors field, titled with "Who may edit this page" and the childeditors field, titles with "Who may create childpages" in Content Manager, reduce the rights to edit pages of a branch to the users, groups and roles contained in the field. 

When any of both fields is empty then the settings of the parent document is inherited by it, this being the "childeditors" field of a parent page or - when on a root page - the "editors" field of the website area.

When editor fields are filled they normally completely determine editing rights for that page and make all settings of parent documents ineffective for it.  A person has the right to edit a page when:

• Either the "pageeditors" field of that page contains names which explicitly allows it
• Or the "pageeditors" field of that page is empty and:
• Tthe "nearest" filled "childeditors" field on the parents up the hierarchy explicitly allows it
• There are no filled "childeditors" fields up the hierarchy and the "editors" field on the area explicitly allows it or is empty

By editing a page is meant: Edit the page and its properties and also edit any content document on it.

The "childeditors" field also controls the right to create subpages for a specific page. A person has to right to creae a page when:

• Either the "childeditors" field of the parent page contains names which explicitly allows it
• Or the "childeditors" field of that page is empty and:
• Tthe "nearest" filled "childeditors" field on the parents up the hierarchy explicitly allows it
• There are no filled "childeditors" fields up the hierarchy and the "editors" field on the area explicitly allows it or is empty

This way of work allows the combination of "childeditors" and "pageeditors" field in a hierarchy to either reduce or extend editing rights down the hierarchy. This differs from "pagereaders" which always works additive and can only reduce rights down the hierarchy.

An Example

Here we show the editor fields of the example page hierarchy. The website areas "editors" field allows only "Chief-Editors" to edit the base structure of the website, including documents "Home", "News", "Accounting Information", "Communities", "Downloads" and "Sitemap". This is to protect this structure which hardly ever changes from being accidental corruption.

On some of those subpages you see that that the "childeditors" field is modified to effectively give the responsibility of that page branch to another group. Group "News-staff" may create and edit pages below "News" (but not page "News" itself), group "Moderators" may do the same below "Communities" and group "Uploaders" below page "Downloads".

On some specific pages the "pageeditors" field is modified to allow certain groups editing of this very document, but not allow them to create or modify any subpages. Document "Management" may be edited by group "Management", also document "Markering" by group "Marketing" but both cannot create new pages below those respective pages or could edit existing ones.

Note that every set child/page editors field here also removes editing rights for "Chief-editors", because they are no more included. To keep rights for this group it should be added to each field as additional group.

Usage scenarios

On most occasions a website may want to protect its basic structure from illegitimate corruption, so mostly the editing rights on the highest document levels are the most restrictive. This can be accomplished by specifying those rights right on the area. 

On lower page levels the editor fields can be used to loosen or delegate editing rights to certain responsible groups, either for a subpage branch via "childeditors" or for a single page via "pageeditors". However what should be protected how much always depends on what the website shows. Editing rights may need to be extended or reduced down the hierarchy which is both possible with these editor fields.