Online Help

Understanding Default Permissions

Both Admin and User Security Groups have a Permissions tab that allows you to view and edit the permissions for that group. With User Security Groups you are primarily concerned with what you want to permit the group to see. Permissions for Admin Security Groups, on the other hand, can be more complex, as there are many parts of the product and many activities that you might like to differentiate. For example, you might like one group of junior administrators to help with PageBuilder pages, while another group composes the email newsletters (but can’t send them without your permission).

For each part of the product, we have established certain Default Permissions that is, permission sets, arranged in a hierarchy, that define roles that you can assign to an Admin Security Group. You can view the Default Permissions that are available on the Group Permissions tab of any Admin Security Group.

In the illustration below, we have chosen to view the various roles (permission sets) that are available to an Admin Security Group for Events Management:

Note that the available roles—the Default Permission sets—increase in privilege from bottom to top; that is, the least privileged role in regard to Events Management is explicitly No additional permissions over those of a registered user (who cannot see administrative content at all!). This is followed by the ability to View Event Reports, and finally, the full responsibility to Manage Events (which includes the ability to view event reports). Similar roles are available to Admin Security Groups for other parts of the product.

In the above illustration, we could assign this group permission to Manage Events on our site by checking the appropriate radio button and saving our changes. This would give members of this group the ability to manage all events on our site—which may be the desired goal. However, if we wanted to allow them to manage only certain events, we could place those events in a special Security Category (such as Spring Fundraisers) and deny the group the ability to manage events in general, but add an override that allowed them to manage the events in that Special Category, as shown below:

It is important to note that this group does not have permission to Manage Events in general because we did not select the Default Permission that would give them this privilege. However, through an override, the group does have permission to manage events that are placed in the Spring Fundraisers Security Category. (Note that we have the same roles available when creating an override -- we are simply limiting those roles to the objects placed in certain Security Categories.)

Because granting the correct permissions to a Security Group is important, we have prepared a separate document called Managing Security that explains, with detailed examples, how to use Security Groups, Permissions, and Security Categories to get the results you want when assigning permissions to Admin and User Security Groups.