This image illustrates the relationship among Group, Category, and Object permissions.
In Tiki19, permissions were further improved with better handling of the parent-child concept. Tiki21 introduces Templated Groups and Roles. This is not necessarily reflected in the documentation below.
In what order are permissions settings applied?
It is important to understand that Tiki uses several types of permissions:
Permissions are inherited from from the top-down, but override from the bottom-up.
Tiki's permissions model may look like complex... but is also very customizable.
Consider the following example for a company using Tiki:
You have the groups:
Notice that some groups include other groups. For example, members of the Board of Directors group will include, in addition to their own permissions, the permissions from the Employees, Registered, and Anonymous groups.
You have the categories:
You want to give:
First, you need to define the global permissions for each group.
Now that the Global permissions are set, you can adjust the permissions for each category. These settings will override the Global permissions. The Category permissions can be set for each category from the Settings > Categories (tiki-admin_categories.php) page.
Currently, Anonymous can view press releases, and Employees can edit them (as defined by the Global permissions). To allow only the Board of Directors to edit press releases, you must assign permissions to the category. This will override the default group (global) permissions:
Currently, Anonymous can view Financial Information, and Employees can edit them. But we want only the Board of Directors to have access (both view and edit) to these pages. You'll need to make the same adjustments to the Financial Information category's permissions:
But what if you want one item in the Financial Information category, to be visible to the public? You can override all other permissions, by assigning specific permissions to the object itself. For example, the ABC Company may have a public disclosure form, issued by the government, that it needs to make public (but that only the government can change or update):
Object Permissions can be tricky.
For example using version 10, if you wanted to hide one wiki page made by admin from the Anonymous group you would select the page's permissions (from the admin menu : Wiki/List Pages/then click the Key icon for your page in the list).
Using the object permission page of the wiki page, you turn off the "Can view page/pages (tiki_p_view)" attribute and save.
However, after loging off, and connecting as Anonymous you can still see the page.
It turns out that you have to turn off the "Can view page/pages (tiki_p_view)" AND "Can admin the wiki (tiki_p_admin_wiki)" attributes to hide the wiki page from the Anonymous group.
The interface has three tabs. The first tab is for assigning permissions.
The second tab is to select which groups should be included in the table for assigning permissions, because, when the list of groups is large, assigning permissions could be slow.
The third tab is to filter the number of features that should be shown in the interface. This is specially needed when managing category permissions, to avoid having a list bigger than needed for our purposes in specific cases.
In addition, this new interface to manage permissions includes several features:
Permissions can be restricted via the category feature. Basically, you can already assign all the permissions you need as described above. The full granularity of permissions can be assigned to categories (and thus inherited when objects belong to a given category).
If an object has no specific (object) permissions, then:
For example, if...
... then:
Because adding a category to an object can provide additional rights, it is important to protect who can assign categories to prevent undesired escalation. For example, if the site contains public and private information, someone with access to edit private information should not be able to make it available publicly by changing the categories. To resolve this issue, multiple permissions can be assigned to the categories.
To begin with, tiki_p_modify_object_categories allows to determine if the user is allowed to modify the categories of the object at all. Without this permission, it will be impossible to modify the categories. Typically, it is safe to grant this permission widely.
Then, there is higher granularity available for each category. tiki_p_add_object and tiki_p_remove_object determine if the user can add or remove elements from the category. Categories on which permissions are specified should also specify who can assign to or remove from those categories. When a user has the tiki_p_modify_object_categories permission on an object and modifies that object, but lacks the tiki_p_add_object permission on a certain category, the user will see a checkbox for that category, but the checkbox will be disabled.
Additionally, some category changes may be allowed in certain contexts by defining Category Transitions, which would allow to change a category only from a certain state. A group of transitions create a workflow.
Workspaces further facilitate management of large and complex Tiki sites.
When a group has an admin permission on a feature such as tiki_p_admin_sheet, the group will lost his admin permission for an object with local perms or categories permissions.
Since Tiki19 it is possible to customise and re-order the list of the permissions displayed under Setting => Permissions (tiki-objectpermissions.php). Super user can edit a yaml file located at : tiki-objectpermissions_order.yml.
Some information on this page is from Tiki for Dummies Smarties, copyright (C) by Rick Sapir, published by KeyContent.org, and available under a Creative Commons Attribution-Share Alike License.