Security in rockumentation follows the precedence set forth by Sites
and Pages in Rock. As a refresher of that concept, the root page
inherits security from the site and child pages inherit security from
their parent page.
In our context, the Book is the main security force. All book
Version's inherit their security from the Book. Underneath the version
comes the root article, which inherits it's security from the version.
Finally, any child articles inherit security from their parent article.
What this means, is that you can secure individual articles or entire
trees of articles. On top of that, you can lock down a single version
of a book. For example, when you publish a new version of a book, you
might decide to lock down the prior version so your normal editors can
no longer edit.
When you install the plugin, two security roles are added for you.
The first is the
RSR - Documentation Administrator role.
This role is granted access to create, edit and administrate
documentation. Generally speaking, this role has access to do anything
with books, versions and articles.
The second role is
RSR - Documentation Editor. This role
is granted limited access to make changes. Generally speaking, they are
only allowed to edit existing articles. They cannot create new books,
versions or articles.
In the following sections you will learn how the security model works
with the different entity types. With this knowledge you can begin to
customize the security to create your own security roles with specific
In all cases, view access follows the normal View security permissions.
To create new books, you must have Administrate access to the
DocumentationBook entity type (this can be set under Security, Entity Administration).
In order to delete existing books, you will need Administrate access to the book you are attempting to delete.
If you want to edit an existing book, you also need Administrate access to the book in question.
This is a deviation from the normal need of Edit access. This is done because editing a book is considered an administrative change, and also to allow for easier security inheritance
To add a new version of a book, you must have Administrate access to the book that will contain the version.
Deleting an existing version of a book will require that you have
have Administrate access to the specific version you are deleting.
In order to edit an existing version, you also need Administrate access to the version in question.
This is a deviation from the normal need of Edit access. This is done because editing a version is considered an administrative change, and also to allow for easier security inheritance.
Creating a new article requires Administrate permission on the parent article that will be the parent of the new article.
If you attempt to delete an article, you will need to have Administrate permission on the article to be deleted.
In order to edit the contents of an article, the user must have Edit
access. In addition, to edit other aspects of the article (such as
title), the user must have Administrate access to the article.