Provides more advanced permission management for data objects in SilverStripe.
This module changes SilverStripe's object access module to be locked down
as the default case, meaning that by default, there are NO permissions to
an object except those explicitly granted to a user on a node (or tree), with
the exception of admin users, who always have full access to all objects)
The new model of permission access has a few concepts that are slightly
different to the existing model, and draws off the model seen in Alfresco
In the existing SilverStripe model, Roles and Permissions are high level
concepts without any context to the content in the system. They cover
high level permission concepts such as 'access the CMS'. For node specific
control, there is only explicit support for allowing View or Edit permission.
This new model allows you to specify
much more finely grained access restrictions directly to a node or tree of
nodes. For example, it is possible to specify that a user can perform the
Editor role (giving view and write access) in one part of the tree, but
also Manager access (Editor plus Publish/Delete etc) to another part of the
Additionally, you can explicitly DENY access to a node inside a tree where
the user might already have been granted access at a higher point.
Finally, the new model supports the concept of a content owner, who has
(almost) unrestricted access to content that they themselves have created
within areas that they have been allowed to create within.
The master branch of this module is currently aiming for SilverStripe 3.1 compatibility
Object::add_extension('Page', 'Restrictable'); Object::add_extension('SiteConfig', 'Restrictable'); Object::add_extension('Page', 'RestrictedPage');
AccessAuthorityADD INDEX (
When would you want to use this model?
From an end user perspective
From a developer perspective
To manage permissions using the restricted objects module, there are a few
steps commonly performed
Some default access roles are automatically created when you install the
system. These can be accessed via the Access Roles section.
To define new roles, you simply create a new AccessRole item, and select
the permissions you want to use within it.
Assigning roles are done from the "Permissions" tab of any content item.
You can specify the role to assign for a user or a group, and whether you are
granting or denying that role. You can also choose individual permissions
to apply or revoke.
To define a new low-level permission item, you must define a class that
implements PermissionDefiner (not to be confused with the default
SilverStripe interface PermissionProvider) and return a simple array of
strings in the definePermissions() method. These strings should be the
permissions you check for in
See the (wiki)[https://github.com/nyeholt/silverstripe-restrictedobjects/wiki]
Rather than just providing permission inheritance via a ParentID lookup, in
some cases that there may be situations where there are multiple objects that
would be considered a 'parent' for permission determination. To support this,
the permission lookup mechanism allows developers to define a few mechanisms
for providing this inherited source object
On a data object directly
effectiveParents()that can return an SS_List of parent objects
effectiveParent()that can return a data object directly
Via an Extension subclass
updateEffectiveParents(&$parentNodes)which can add additional nodes
All permissions are cached immediately after lookup, including the result of
any inherited permissions, meaning that subsequent data changes may
change this inheritance structure. To work around this, the system also caches
some key data relationships, namely
Thus following a change to any node in the hierarchy, the cached data for
any dependent node can be immediately purged.
Module rating system helping users find modules that are well supported. For more on how the rating system works visit Module standards
Score not correct? Let us know there is a problem