OpenWGA 7.9 - OpenWGA Concepts and Features

For website areas

There are two authorisation fields on website area documents that influence access to the contained pages:

• The metadata field "readers" contains users that are allowed to generally access content data inside the website area page, including read and write access. An empty readers field means that anyone can access the area, but once the readers fields is filled all users that are not contained in it - either directly by username or indirectly as group or role - will not be able to see its content data. For these users OpenWGA will behave like the content data of this area does not exist. This right may be further restricted by the pages in the page hierarchy.
  
  
• The metadata field "editors" specifies users who generally are allowed to create, edit and delete struct entries content content documents in the given area. This right may be further restricted or loosened by other pages in the page hierarchy.
  
  

For a detailed explanation of the role of these fields in hierarchical authorisations see Using hierarchical authorisations.

When one of this field is empty it allows the respective right to everyone generally owning this right on application level.

Editing rights cannot be effectively issued to people that are excluded an areas readers field.

Both fields are available in OpenWGA content manager on the editor for website areas:

For pages and page hierarchies

The authorisation fields that control access for a page are stored internally on the struct entry document.  Three security related metadata fields are available here:

• The metadata field "readers", titled in content manager "Who may read this page and subpages", contains users, groups and roles that are allowed to access the content data of the page generally, including read and write access. An empty readers field means that anyone can access the page, but once the readers fields is filled all users that are not contained in it - either directly by username or indirectly as group or role - will not be able to see the content data. For these users OpenWGA will behave like this content data does not exist.
  
  The reading restriction is effective for:
• All content documents on the page that has the restriction set
• All content documents of the page hierarchy below that page. This includes child pages that have their own read restrictions. Read restrictions can only be reduced down the hierarchy, never loosened.
  

• The field "childeditors", titled in content manager "Who may create childpages",contains users, groups and roles that are allowed to create, modify and delete struct entries and content documents that are in the hierarchy below the current struct entry. When the fields is empty then it inherits this setting of its parent document, either from the field "childeditors" of a parent page or the field "editors" of its area if it is a page at root. That way a setting on a special struct entry can be inherited down the hierarchy until it is redefined on some special lower struct entry.
  
  
• The field "pageeditors", titled in content manager "Who may edit this page" contains users, groups and roles that are allowed to create, modify and delete the current struct entry and its content documents. When the field is empty it also inherits the setting from the parent pages "childeditors" field or the "editors" field of its area if it is a struct entry at root.

For a detailed explanation of the usage of those hierarchical authorisation fields see Using hierarchical authorisations.

Editing rights cannot be effectively issued to people that are excluded by a readers field of any page up the page hierarchy or the area.

In OpenWGA Content Manager all three fields are available in the page properties editor (Button  on the left explorer panel): The field "readers" as "Who may read this page and subpages", the field "childeditors" as "Who may create childpages" and "pageeditors" as "Who may edit this page":

The editors for each field are enhanced, so that an author may choose predefined settings from a list box while the content manager application fills the fields with the right contents for each setting. For example: Choosing "inherited" from the list box will automatically store the respective field with empty content. Choosing "only defined users" will show a detail field where those user/group/role names that are allowed can be specified.

Editing rights special features

When the fields for editing rights are not empty they normally completely redefine those rights. This may be a reduction or an extension to those rights inherited from parent documents. A special string "#inherit-and-reduce" can be used as first entry of these fields to also let them reduce the rights inherited from the parent document (just like the "reader" fields works). Documents whose editing field features this first entry will only be editable for users who are included in the field "childeditors/editors" from the parent document AND in the further entries of the current documents field.

Imagine a parent page having the following entries in field "childeditors":

• accesslevel.manager
• #maintenance

This reduces the editing rights to all parent pages to people either being of access level "Manager" (see Virtual user groups) or having the role "#maintenance".

A child page may have the following entries in its field "pageeditors":

• #inherit-and-reduce
• Administrators

The special first entry "#inherit-and-reduce" triggers the reducing behaviour. To edit this child page both fields, the one of the parent and the one of the child, need to allow you to. You need to be either manager or have role "#maintenance" AND you need to be in the group "Administrators".

This usage mode is especially applicable for data-driven applications like those of the HDBModel framework, as here it is typical to further restrict access down the hierarchy.

For individual content documents

The content document features the following authorisation fields:

• The content document also owns a metadata field "readers" that contains users, groups and roles that are allowed to access the content document generally, including read and write access. This field is regarded obsolete since the reader field on the page is available and is not modifiable by content authors, unless the application is configured to use them. An empty readers field - as is default - allows everyone read access unless restricted otherwise.
  
  
• The fields "author", "owner" and "coauthors" all three contain users, groups and roles that are granted "authoring rights" on the content document. Authoring rights are only effective for users of access level "Author", who generally are able to edit content documents but only those that they have authoring rights on. If an "Author" level user is not contained in any author field he may not edit the document.  The three fields have the following separate purposes:
  
• The readonly metadata field "author" contains the user that created the current version of the content document. 
• The metadata field "owner" originally contains the user that created the first version of the content document and is inherited to further versions. Its content may be changed to transfer ownership to another author.
• The metadata field "coauthors" contains users, groups and roles who should also have authoring rights on the content document. In that case an empty field does NOT allow anyone authoring rights but instead allows no additional authors beside "author" and "owner".

Those latter three fields are available in OpenWGA Content Manager for every single content version in the content properties editor, section "content properties". The "author" field however may not be modified: