Permissions

The PostNuke Permissions system is basically a hierarchy. Each permission setting is entered into an ordered table, and the upper entries have precedence over the lower ones. A pair of groups that on paper have relatively equal access to different areas of a site are ordered after they are added to the Permissions system. That way, should there ever be a possible conflict, the permissions for the groups can be compared to determine the resulting abilities of group members.

The reason for the hierarchy is that user accounts can be added to multiple groups and given different sets of permissions. An account can also have custom permissions assigned to just one user. Having an ordered precedence system eliminates any rights conflict.

Default Settings

Return to the main Administration page and select the icon labeled Permissions. You are now presented with the PostNuke permissions table shown in Figure 9.6. The system has a bit of a reputation for being difficult to manage, but the confusion lies more with its appearance than any real design problems.

Figure 9.6. Default PostNuke permissions.

The table has seven columns. The first simply displays the sequential order of the permissions. The column is especially important when you use the filter feature above the table to limit the number of rows being viewed at a time.

The second column allows you to change the order of the entries. PostNuke permissions are evaluated from the top of the table down. When trying to determine the rights for a resource, PostNuke stops looking after it finds the first match. So, for example, if two permission settings exist, with the first permission granting total access to an item and the second restricting access, as long as the grant access is higher in the table, the second entry is ignored.

The Group column names to which group the permission entry applies. The User Permissions table is identical to the Group Permissions except for this column. Notice the two other possible entries in addition to your established groups: Unregistered and All Groups.

Nine different types of Permissions Level rights can be individually assigned to a given group or user entry. The levels and type of rights are detailed in the following list:

• None No access is granted for the resource. The resource and links to it do not appear to users.

• Overview The resource appears to the user, but read access to the content within the resource is not granted.

• Read The user is granted read-only access to the resource.

• Comment Resource content can be read, and the user can add comments regarding the content, but additional content cannot be added.

• Moderate This right grants the ability to moderate a resource that has a moderation feature.

• Edit The user can read and edit existing content in a defined resource. New content cannot be added.

• Add This right provides access to add and approve additional content for a given resource.

• Delete This right grants the ability to remove existing content from the resource.

• Admin The user is given full administrative rights to the resource.

The Operations column has three clickable buttons for each permissions entry. The far-left button with an arrow on it inserts a new permission into the table. The new permission is placed above the line whose button you click. Entries added using the New Group Permission link above the table appear below all entries. The middle button with "ab" written on it edits the given line. Finally, the last button marked with an "X" deletes the permission setting. There is no confirmation when deleting a permissions entry.

Components and Instances

Most PostNuke users who have problems with the permissions system get hung on the Component and Instance settings for a rights entry. A Component is the physical coded resource, like a module or a block. An Instance is the live example of the Component. For example, Menu is a core block type. Go into the Blocks Administration screen. It's possible to create as many instances of the Menu block as you want. Notice that both Main Menu and Incoming are both Menu blocks. Menu is the Component, and Main Menu and Incoming are Instances.

When referencing both Components and Instances, you can see in the Permissions table (in Figure 9.6) that both colons and asterisks are used. The period/asterisk is a wildcard that signifies "everything." When being more specific, you must use the colons to separate references. Both Components and Instances can be detailed with three terms, which are separated by two colons. If one term is specific enough, the rest are also assumed to mean "everything," though the wildcard is not required.

For example, this entry: .* means the same thing as: .*:.*:.*. If you are referencing a resource in the same way, this entry: Menublock:: is identical to Menublock:.*:.*. The shorthand of removing the asterisks in specific references and colons in global references is what can be confusing.

Now to explain the specific references, look at lines two and four in the default settings. Line two reads like this:

 Menublock::    Main Menu:Administration:    None 

This means groups have no access to the link named "Administration" in the instance of "Main Menu," which comes from the Component "Menublock."

Line four has these settings:

 Menublock::    Main Menu:(My Account|Logout|Submit News):    None 

The permission is identical to the preceding one, except multiple links in the Main Menu Instance are referenced. They are grouped inside parentheses and separated with the vertical pipe character. You can make complex but easy-to-manage rights entries using the grouping controls.

In addition, it's easy to determine how to reference specific Instances and Components because PostNuke provides them all for you. Notice the links in the table heading; both Component and Instance are clickable. Each link pops up a table dynamically generated from the current system. PostNuke determines every Component or Instance currently available and lists them for you.

Setting Permissions By Group and User

The vast majority of the time, you should be setting permissions by group. It saves management time and is absolutely essential for sites with large numbers of users. The filtering feature is also only available for group settings. But should you need to single out a user, the settings for Components and Instances are identical to the group permissions.

User permissions are also checked before group permissions. This is key because user permission settings should be the exception to the group rules. Having user entries checked first allows the exceptions to take place first; PostNuke stops looking for rights access after finding a setting in user permissions.

An example of how this might work is a problem user on your site. Suppose you have a user who continually posts off-topic content on your site. If you need to temporarily restrict the account's posting abilities, a quick user exception rule does the trick. It's easy to remove the user setting later, and you do not need to touch the group table.