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. Actions - The first thing you’ll see is a tabbed list of the security actions available for the item. Typically, these will be View, Edit and Administrate. You'll set permissions for each of these actions.Item Permissions - The Item Permissions area is a list of the specific permissions defined for the item. If there are no specific permissions set for this particular item, the list will be empty. In these cases, security is being inherited from its parent. But now we’re jumping ahead...Inherited Permissions - Most items don’t have permissions of their own. They inherit their permissions from their parents. For the most part, you’ll only add Item Permissions when you want to increase the security of the item. This is a very powerful concept. It keeps you from having to constantly and consistently tweak the security of each item. It also allows you to change the security of an item and let the change trickle down to all of its children. NoteThe 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: NameAllow / Deny All UsersDeny All StaffAllow 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: NameAllow / Deny All StaffAllow All UsersDeny 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. PersonSearch for the person whose security permissions you want to view.Entity TypeSelect the entity type you want to verify. For example, if you want to view the security on a page, select 'Page'.Entity IDThis field is where you enter the Integer ID or Guid of the entity you want to view. For example, if you want to view the security of the external homepage (which has an Id of '1'), type "1" in this field.Security PermissionsThis is the list of security permissions for the person based on the search criteria.Unlock SecurityThis button allows you to quickly unlock security permissions. 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.