Idealink's security lets you control who can see specific features or perform actions. You can control access on a global level or within a particular context.
How security works
Idealink lets you create a group of users (or use the existing groups), then specify what that group can see and do. There are two kinds of groups: global groups (like
administrators), and relational groups that only makes sense in a certain context (like
idea-submitter). You can refer to the image throughout the text below.
Each user can be a member of multiple groups, and their permissions are the combination of every permission assigned to each of their groups. When calculating which permissions a user has, the following rules apply:
- If any permission is
Deny, the user is denied.
- Otherwise if any permission is
Allow, the user is allowed.
- Otherwise the user is denied.
For example, John Smith in the above image has three groups:
idea submitter (for the current idea). His actual permissions can be calculated like this:
|Permission||Group permissions||Calculated permissions|
|create idea:||allow||John smith is allowed.|
|edit idea:||allow||John smith is allowed.|
|approve idea:||allow + deny||John smith is denied because one of his permissions are deny.|
|delete idea:||John smith is denied because he has no permissions that allow him.|
(You can skip this section unless you're looking for a more thorough explanation.)
Idealink uses an authorization-based security model, which defines permissions assigned to groups, which contain users. This is a powerful security model and is similar to other models like Windows ACL security, but it can be difficult to understand if you've never configured a security system before.
Every user is a member of named groups like
administrators. This includes two special groups (the
* group includes everyone, and the
users group includes registered users), relational groups (like
idea-submitter for the user who submitted a particular idea), and explicit groups you add members to (like
administrators or custom groups you create.
Each group is assigned permissions. Each permission is a specific feature or action the group can access. For example, you can control who can edit an idea using the
Each permission in turn is assigned a single value:
- Allow: the user is allowed to perform the action or access the feature.
- Deny: the user is prevented from performing the action or accessing the feature.
- Inherit: this setting has no effect (neither allows nor denies).
How to change a permission value
You can configure security permissions through the web UI by visiting the
Admin » Security page. This page lets you edit groups and permissions, including creating custom groups or adding users to groups.
For example, let's say you want to let the idea submitter change the idea status. You can configure it like this:
- Navigate to the
Admin » Securitypage.
- Next to the
idea-submittergroup, click the edit icon.
- Next to the
idea-tools-statuspermission, select the
- Click "Save".