Core Docs - Core Concepts - Handle Permissions

Rock Version: v19.0
Last Modified: 2025-10-23 12:28 PM

Wherever you see the ti ti-lock icon you can manage the security of the item being displayed. Clicking the icon will bring up the Security Editor shown below.

The Inherited Permissions list tells you which parent item has set the security. This allows you to easily find the parent and fix any incorrect security.

Setting Permissions

When setting permissions, you'll add either an individual or, more commonly, a security role to the permissions list with either Allow or Deny access. The order of these permissions is very important. The way the system works is that it starts at the top and works its way down the list looking for a matching rule. The first rule that matches the logged in individual will be implemented, either granting or denying access. Crafting the order of these permissions is important.

Let’s look at an example. First, we’ll look at a case where a page should only be viewed by staff members (and not volunteers or other individuals accessing Rock).

Incorrect Permissions:

The above setup might look correct at first because both roles exist with the proper access. It’s true that staff should have access and other non-staff users should be denied. However, remember that Rock works through security from the top down. Because Staff are also Users, the system will stop at the “All Users | Deny” level and won’t allow access.

Correct Permissions:

Now the logged in staff person will match on the first rule and be granted access. Processing of the subsequent rule won't occur for this person, so even though the staff person is also in All Users, they will still be granted access. An individual without the All Staff role will cause the system to keep checking down the list, where it will find a match at the All Users level and deny access accordingly.

Verifying Permissions

There may be times when you want to view a quick snapshot of a person's security permissions. You can do this in the Verify Security block, found in Admin Tools > Settings > Inspect Security.

This snapshot view allows you to do a couple of handy things.

First, it allows you to view the source of a person's effective security permissions. If, for example, someone should have access to a particular page or function but doesn't, the Verify Security block allows you to quickly view where the Deny rule is coming from. Keep in mind that the security permissions of particular entities (e.g., pages, groups, etc.) not listed here may cause additional limits to the person's access.

Second, and perhaps more importantly, it allows you to restore your own permissions when you accidentally lock yourself out. Don't be embarrassed; it happens to everyone. The Verify Security block allows you to quickly unlock your access without having to go into the database. Simply click the ti ti-lock button.