Disclaimer: this is not a comprehensive solution. Think of this as a locked door that keeps an honest man honest. We're looking to prevent our brothers and sisters from stumbling into information inadvertently. A dedicated member of RSR - Rock Administration will be able to access any information in your system if they put their mind to it. For obvious reasons, we will not enumerate workarounds here.

Rock has a robust security model, and as a Rock admin you can be very granular about the permissions that an individual has by placing them into security roles.

Frequently we hear about a desire for churches to be able to grant certain database workers all of the permissions of the RSR - Rock Administration role, but without the ability to see giving information. This is possible to do with a solid understanding of Rock's security model. Spark Development Network and Sparkability Group use similar methods for our own workers to protect information about community contributions while allowing access to configure our own Rock instance.

What we're going to do is create a separate, Non-Finance Admin role. This role will be used to deny permissions, rather than to grant them. 

The first step that we take is to create our Non-Finance Admin security role. For our purposes, we will refer to it as RSR - Non Finance Admin. Begin by navigating to Admin Tools > Security > Security Roles. Add a new security role using the 'Add' button on the right side. Do yourself a favor and include a description of the role. For our purposes, we will add pastor Pete Foster to the role. We will also add Pete to the RSR - Rock Administration security role.

RSR-Non-Finance-Admin.png

Now we need to set specific permissions on this security role. We don't want our non-finance admins to be able to easily disable their limits.

Add the RSR - Non-Finance Admin Role to both the 'View' and 'Manage Members' security verbs, setting the action to 'Deny'. RSR-Non-Finance-Admin-Deny-View.png

Next, we're going to start locking down the various pages associated with finance. First, we'll navigate to the Internal Site on the Admin Tools > CMS Configuration > Pages control, and select the 'Finance' page tree, and start setting permissions with the padlock icon.

Add the RSR - Non-Finance Admin security role to the 'View' verb, setting the action to 'Deny'. Make sure that this is the very top permission in the stack. As a review, Rock evaluates permissions from the top down, so members of that role will be denied view permissions and kicked out of the page (or not shown the icon in menus) before their membership in RSR - Rock Administration would be evaluated.

RSR-Non-Finance-Admin-Deny-Finance.png

Next, we will lock the non-finance admin out of the person contributions page. We can get to this page by visiting any person profile, and selecting the contributions tab. It is also available via the Pages control at Internal Homepage > People > Person Pages > Contributions. In the same way as the finance page, we are going to add the RSR - Non-Finance Admin role at the very top, denying them view permissions.

RSR-Non-Finance-Admin-Deny-Contributions.png

Let's look at Pete's Security Roles on his person profile page, as the Alisha Admin user:

RSR-Non-Finance-Admin-Pete-Roles.png

If we log in as Pete and view our own profile, we see what a non-finance admin would see: the admin toolbox, the admin bar at the bottom of the screen to manage features like blocks, the Security tab on a person page, etc. However, also notice that the finance menu is hidden from plain view, as well as the contributions tab on the person profile. If Pete were to navigate to the security tab on his own page, he would see all of his security roles, except for the RSR Non-Finance Admin. Since he can't see this, he can't easily remove himself.


RSR-Non-Finance-Admin-Pete-Login.png

You may also elect to deny view permissions to various attributes, benevolence features, etc. if you so choose. The main thing to remember is to ensure that your RSR Non-Finance Admin security role is at the top of the permissions stack, with Deny View set.