![[Show/Hide Right Column]](pics/icons/orightcol.png "[Show/Hide Right Column]"){kind=icon}
Permissions Settings
Table of contents
Understanding Tiki Permissions
After setting the features, setting permissions is the most important part of Tiki administration. This page describes the basic concepts in Tiki's permission system and how they interact. A complete list of permissions can be found on the Permissions List page.How Permissions Work
- Administrators can create and edit a Groups.
- Each Group can have a fully customized access to all site features.
- Users can be assigned to one or several groups.
- Groups can have subgroups.
- Permissions are assigned to Groups, NOT users.
- Administrators can create and edit a Category.
- Objects (after 1.9) can be added to categories.
- a category can then be assigned to a group.
- category based permissions give members of the Groups the right to view, the right to edit category contents (introduced in Tiki >1.10) or the right to manage the category (or any combination of them).
- Individual objects can have permissions applied to them directly
- If no permissions are specified for a Groups or category universal permissions apply.
When Tiki is installed, there are at least two pre-defined groups:
- Anonymous: Users that are not logged automatically belong to the anonymous group.
- Registered group: Users logged in automatically belong to this group.
What order are permissions settings applied?
It is important to understand that Tiki uses several types of permissions:
- Global permissions: Each site visitor belongs to a Group (such as Anonymous or Registered). The permissions you assign to the group define the global permissions for that user.
- Category permissions: These permissions define the actions that users can take for objects in a specific category.
- Object permissions: These permissions define the actions that user can take for an individual object.
Permissions are inherited from from the top-down, but override from the bottom-up.
This image illustrates the relationship among Group, Category, and Object permissions.
Tiki's permissions model may be very complex... but it is also very customizable.
Starting with Release 4.x, Tiki has a dramatically different (and friendlier) method of assigning permissions than earlier versions.
Permissions Example
Consider the following example for a company using Tiki:You have the groups:
- Anonymous
- Employees
- Board of Directors
The Groups for ABC Company
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:
- Financial Information
- Press Releases
You want to give:
- Everyone permission to read most pages
- Employees permission to edit most wiki pages
- Board Members only, access to the company's financial information.
Global (Group) Permissions
First, you need to define the global permissions for each group.
Defining the Global permissions for each group.
Anonymous
- To let the general public (that is, anonymous visitors) view wiki pages, assign tiki_p_view to Anonymous.
Employees
- The Employee group includes the Anonymous group (that is, everyone) and Registered group (that is, users who are logged in). Therefore, the Employee group inherits the tiki_p_view permission from these groups.
- To let employees edit pages, assign tiki_p_edit to Employees.
Board of Directors
- The Board of Directors group includes the Anonymous, Registered, and Employees groups. Therefore, the Board of Directors group inherits the tiki_p_view and tiki_p_edit permission from these groups.
This group does not require any additional permissions.
Category Permissions
Now that the Global permissions are set, you need to adjust the permissions for each category. These settings will override the Global permissions.Press Releases
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:- For the Press Releases category, remove tiki_p_edit from Employee. Now only the Board of Directors group can edit wiki pages in the category.
- Anonymous visitors (and all groups that inherit the Anonymous group's permissions) can still view the pages.
Defining the Category permissions for the Press Releases category.
Financial Information
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:- Remove tiki_p_edit from Employee. Now only the Board of Directors group can edit wiki pages in the category.
- Remove tiki_p_view from Employee, Registered, and Anonymous. Now only the Board of Directors can see the pages.
Object 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):- For the individual item, remove tiki_p_edit from the Employee and Board of Directors group. Since this form is issued by the government, no one should be able to change it.
- Anonymous visitors (and all groups that inherit the Anonymous group's permissions) can still view the pages.
Assigning object-specific permissions to the PublicDisclosure page.
Managing permissions
Warning
While entering a filter, JQuery will rebuild the list. Do not press enter or you'll start all over.
In this new interface there are three tabs. The first one to allow assigning permissions.
the second tab is to select which groups should be included in the table for assigning permissions, since when the list of groups is too big, assigning permissions could be too slow.
File is not an image.
The third tab is also 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 far bigger than needed for our purposes in specific cases.
File is not an image.
In addition, this new interface to manage permissions includes several features:
|
|
|
Permissions by section
| Name | Description | Permissions | Can override global permissions? |
|---|---|---|---|
| User notepad | Users can write, upload, download and read notes. Notes can be read as raw text files or as Wiki pages interpreting the Wiki markup syntax. The user-quota that admin can control is used to set the maximum size that user notes can take. | tiki_p_notepad | N/A |
Demo site for testing
Login here: (user: admin / password: demo) to test giving permissions:http://demo.opensourcecms.com/tiki/tiki-assignpermission.php?group=Registered
Category permissions
There is also a new feature in Tiki 1.9.x to restrict permissions via the category feature. Basically, you can already assign all the permissions you need as described above. However, permissions via the category feature is just to make it faster to assign permissions. This feature is little tricky to understand. We are working to improve it. There are only two levels ("view" & "admin") in Tiki 1.9.4, and the third level ("edit" category contents) has been introduced in starting from 1.10.Starting in 3.0, category permissions are in addition to Groups permissions. So if tiki_p_read_categorized allows reading items which are in a category, the user must also be in a group which allows reading the specific kind of object. The category can not grant access to an object which the user's groups do not give him access to.
In Tiki4, the full granularity of permissions can be assigned to categories (and thus inherited when objects belong to a given category). The permissions granted to objects are the sum of all the permissions granted to categories in which they belong.
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 or remove those categories. When the operation is not available, the checkbox will be marked as 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. Note that until Tiki6, category transitions are only available through Profiles.
Workspaces
Workspaces are coming to Tiki4 to further facilitate management of large & complex Tiki sites.Admin permissions and special permissions
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.Note
Some information on this page is from TikiWiki forAlias
- ACL
- ACLs
- permission
- perm
- perms
- right
- rights
- global permissions
- global permission
- object permission
- object permissions
- privilege
- privileges
,
,
,
,
,
,