As functional as Rock is out-of-the-box, for many churches it's missing one important feature: A tool to act as a "portal" for registering new families during check-in -- one that is simple and safe enough to let volunteers use without giving them full access to Rock. We built such a tool for our needs that we call Check-In Central, and it looks like this:

Check-In Central serves as a place to add new people/families (and search for existing ones), launch Check-In Manager, and provides quick access to help and instructions for the volunteers using it... but there are no custom blocks (or magic) here. It's just some new pages, HTML blocks, and proper rights all brought together to create the end result. If you're interested in building your own, the rest of this article will show you how.

This article assumes you're relatively new to Rock's CMS and adding pages, blocks, and rights, and will try to do step-by-step where it's important... but will get progressively less step-by-step as we get further in, the assumption being that you're learning as you move along.

The process can be broken down into several large steps, with lots of sub-steps. We'll need:

• A new role to add the volunteers to that will give them rights to the portal.
• A new top-level menu and set of pages to create the portal.
• Lots of adding/editing of security rights throughout Rock to make it all work.

Add New Role

It might be tempting to head to Admin | Security to add a new role to hold your check-in volunteers, but doing so would involve a Rock Admin every time someone needed to be added or removed from the role. Ain't nobody got time for that! Instead, we'll create a Serving Team group (or whatever kind of group makes sense for you) which has the Security Role option checked. This group will contain the volunteers that need access to Check-In Central, and since it's just a Serving Team, any staff person with proper rights can add/remove members without bugging you, the Rock Admin. Win! If you already have a group that represents your "check-in volunteers", use that group instead.

Once you make your Serving Team group a role, you should see the role under Admin | Security | Security Roles with a name like GROUP - Check-In Central (or whatever group you chose to make a role.) This is the role we will use to assign rights to the portal... but we're getting ahead of ourselves.

Add Menu and Pages

Now we need to add the new top level menu and sub-pages. There are multiple ways to do this, but we'll use the "Pages" page because it's fewer clicks vs. using the Admin Toolbar.

1. Head over to Admin | CMS Configuration | Pages
2. Click Internal Homepage
3. Click Add Page | Add Child To Selected
4. On the Add Page dialog, give your new page the Internal Name Check-in Central or whatever makes sense to you. The Page Title and Browser Title will inherit your Internal Name, which should be fine for our needs, but change them if you really want to.
5. Set Icon CSS Class to fa fa-check-square-o or whatever FontAwesome icon you prefer.
6. Click Save

Here's what it should look like:

At this point you should have a shiny new top-level menu with nothing in it. Notice that the new menu/page is at the very bottom of your sidebar menu, which is probably not where you want it. To fix that, go back to Admin | CMS Configuration | Pages, click Internal Homepage, and click the Child Pages icon that looks like this on the far right. From there, drag your new page to the desired place among your existing top-level menu pages. For volunteers logging into the portal, they will only see this one menu, so the placement wouldn't matter... except that staff and Rock admins who also have access to it will see it among the other menus, which is why you want it to appear in a logical place.

Now we need to add a few more pages, same steps as above. Because the main Rock menu is three levels deep, we need to create another page to act as the "sub menu" page within the top-level menu:

1. Go back to Admin | CMS Configuration | Pages and expand Internal Homepage then click on your new Check-In Central page.


2. Just as before, click Add Page | Add Child To Selected and give the new page an internal name of Check-In Central. If you want your sub-menu to say something else, name it that.


3. No need for a FA icon this time, so just click Save

Hopefully you're starting to get a rhythm now and don't need explicit steps to create a new page. We need to create yet another child page of the page we just created, which will become the homepage of the portal. Go back to Pages, drill down through Internal Homepage and expand your Check-In Central page and click on your sub-menu page (also called Check-In Central). Use Add Child to Selected to add a new page and call it Home. This will be the homepage of the portal and where most of the action takes place. Let's go ahead and get this homepage configured. Adding the Check-In Central Homepage

Configure Homepage

At this point you should be able to click on your new Check-In Central menu and then click the Home menu, which takes you to the new, blank page. Let's configure it:

1. Click Page Properties () in the Admin Toolbar (hover mouse at bottom of page to reveal) then click the Advanced Settings tab and give your home page a pageroute of CheckinCentral.


2. While still in the Page Properties, click the Display Settings tab and un-check Show Title on Page and Show Breadcrumbs on Page then click Save.


3. Click Page Zones () in the Admin Toolbar


4. Add a new HTML Content block to the Main zone (make sure you're on the Page tab), give it a name like Main Content, and click Save then done.



5. Edit your new block ( in the Admin Toolbar, click the flyout in the Main zone, click edit HTML ).


6. Add the following content to your block and save it:

<img src="/assets/images/Check_In_Central.png" class="img-responsive" width="650px">
<br />
<h4><strong><span id="clockbox"></span><span> | {{ CurrentPerson.FullName }}</span></strong> is currently logged into this station.</h4>


<h2>Check-in Options</h2>
 <div class="btn-toolbar">
 <a href="/checkin" target="_blank" class="btn btn-success btn-lg" role="button"><i class="fa fa-group"></i>&nbsp;&nbsp;Add Person / Family
 <a href="/checkinmanager" target="_blank" class="btn btn-primary btn-lg" role="button">&nbsp;&nbsp;<i class="fa fa-line-chart"></i>&nbsp;Check-in Manager&nbsp;&nbsp;</a>
 </div>
 <br /><br />

A few notes about this content:

• You will see a broken image because you need to provide your own image and put it on the file system in that location. Use whatever branding and size looks good to you, or put it in a differnet location if you want... just make sure the img tag matches.
• The current time on the 'Logged in user' line will be missing, because we haven't added the Javacript to make it work, yet.
• My apologies for the total hack of using all the   codes to sort-of make the buttons all the same width and have the text sort-of centered within. I don't have the Bootstrap chops to make a btn-toolbar class have horizontal buttons all the same width with centered text. If you do, let me know! That said, this ugly hack works for us.

Let's go ahead and add that Javascript to make the clock work. Edit your content block again, but this time click the icon to edit the block settings. Click the Advanced tab and add the following code to the Post HTML section, then save the block:

<script type="text/javascript">
tday=new Array("Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday");
tmonth=new Array("January","February","March","April","May","June","July","August","September","October","November","December");

function GetClock(){
var d=new Date();
var nday=d.getDay(),nmonth=d.getMonth(),ndate=d.getDate(),nyear=d.getYear();
if(nyear<1000) nyear+=1900;
var nhour=d.getHours(),nmin=d.getMinutes(),nsec=d.getSeconds(),ap;

if(nhour==0){ap=" AM";nhour=12;}
else if(nhour<12){ap=" AM";}
else if(nhour==12){ap=" PM";}
else if(nhour>12){ap=" PM";nhour-=12;}

if(nmin<=9) nmin="0"+nmin;
if(nsec<=9) nsec="0"+nsec;

document.getElementById('clockbox').innerHTML=""+tday[nday]+", "+tmonth[nmonth]+" "+ndate+", "+nyear+" "+nhour+":"+nmin+":"+nsec+ap+"";
}

window.onload=function(){
GetClock();
setInterval(GetClock,1000);
}
</script>
<div id="clockbox"></div>

Reload the page, and you should see the real time clock!

At this point you should have the whole portal created. You should have:

• A top-level Rock menu () with Home menu that takes you to Check-In Central./li>
• Clicking Add Person/Family from the Home Page should open a new tab to a browser check-in kiosk. This kiosk must have Registration Mode enabled to be able to add/edit Families. If you don't already have this set up, keep reading and I'll show you in a bit.
• Clicking Check-In Manager from the Home page should open a new tab to the existing Check-In Manager page.

Rights, Rights, Rights... right?

While you now have a working portal, it's not terribly useful since volunteers still can't log in and use it. Let's fix that. First, from this point on you will want to have a test user/login created who only belongs to that Check-in Central Serving Team group we created way back when. You will use this person to test the portal from a volunteer's perspective and you will want to log in as this person from a different browser than you're using as a Rock Admin, or use an Incognito window. Go ahead and add that test person/login now if you don't already have one, and make sure they have NO roles assigned except GROUP - Check-In Central, which they get by adding them to your Check-in Central Serving Team.

If you try to log in with this test user now, you will (hopefully) get a Access Denied error, because the Security Role assigned to this user has no rights to Rock at all, yet.

1. Go to Admin | CMS Configuration | Sites and click the securituy () icon on the far right of the RockRMS site. You should see existing roles like RSR - Staff Workers already added here. This is where "base" roles get their rights to the internal Rock site, and yep, we're gonna add our role here as well.


2. Make sure you're on the View tab and click Add Role, then choose GROUP - Check-in Central from your list of roles, then click Add


3. The role you just added will end up below the existing All Users - Deny entry, so drag your GROUP - Check-in Central role to be above it. It should look like this when you've done it correctly:

Your test user should now be able to log into Rock and see pretty much what any person with RSR - Staff Workers role would see, which doesn't seem like what we want (and it isn't), but here's the deal... the reason we added our Check-in Central role at the Site level is because by doing so, a bunch of "stuff" (like Search and Person Profile) is automatically "wired up" for us that would otherwise be a pain to configure from scratch. Thus, our strategy going forward will be to selectively remove the excessive rights our role now has from various menus and functions, with the end result being our role only has the exact (and minimal) rights it needs to do the job.

Redirect Block

1. This might seem odd at first, but add a Redirect block to the Section B zone on the Rock homepage, name it Redirect to check-in central, and set its Redirect URL to /checkincentral


2. Edit the rights on this redirect block to give view rights to only your GROUP - Check-in Central role, followed by a All Users - Deny. This trick has the effect of only redirecting people in that specific role to your Check-in Central homepage, giving them the illusion that it is the homepage of the internal Rock site.
   
   
   Go ahead and try logging into Rock as your test user to see what I mean. Clever, huh?


3. Yes, a side-effect of this is that you, as a Rock Admin, will forever see this red block on the Rock homepage, which is why we put it way down low. There is a way to do this redirect with Lava instead of this block (and you wouldn't see it), so feel free to research and implement that if you want to, but I prefer to have the red redirect block staring me in the face as a reminder of how I have things set up.

Top Level Menus

Now that we have our new role set up with View rights to the Rock site, we need to remove those rights from various places they will inherit-to, starting with the other top-level menus.

1. Head back to Admin | CMS Configuration | Pages and expand Internal Homepage.


2. Click Intranet and then click Security () on the far right, and notice how GROUP - Check-in Central has inherited view rights to this page via the rights we gave it at the Site. We will override that by adding a DENY rule for GROUP - Check-in Central role, like this:


3. Repeat step 2 for the People and Tools menus (and any other menus you may have added to Rock that you don't want this role to see.) You can skip Finance and Admin Tools as there is already a All Users Deny rule on those that prevents our role from seeing them.


4. Go to http://[YOUR SERVER]/page/89 and edit the security on that page to allow View to your Check-in Central role. This gives our role rights to the Person Search (search results) page.

Attribute Rights

As part of registering a new child, volunteers will presumably need to fill in some attributes about the child related to check-in, so we need to give our Check-in Central role rights to edit these attributes.

1. Go to Admin Tools | General Settings | Person Attributes and filter for the Childhood Information attribute category. If you're exposing other attributes in other categories to the Check-In registration process, you can select those, too.


2. Modify the security on each attribute you want the Check-in Central role to be able to edit, like this (make sure you're on the EDIT tab!)

Be sure to give Edit rights to all attributes you want this role to be able to edit.

Searching

While logged in as your test user, try to search for someone. Hmmm... not working? To fix this, we need to "pop the hood" and look at Rock's engine.

1. Go to Admin Tools | Security | Entity Administration
2. Find Rock.Model.Restcontroller and give our Check-in Central role view rights to this Entity.
3. You should now be able to search when logged in as your test user! For the curious, know that Rock uses its own APIs to accomplish certain things (like search) thus the need to grant our role rights to use those APIs.

Person Profile

Even though the Registration Mode on a kiosk gives the volunteer much power to add new families, there are still some things (like Editing a Known Relationship) that you can only do on the Person Profile page, thus we need to give our role access to it.

1. Search for anyone in the db to get to the Profile page.
2. Edit the Bio block and give Edit rights to Check-in Central role. This lets us edit the person.
3. Go ahead and Edit a person to get to the Edit Person page. On this page, edit the Edit Person block and give Edit rights to the Check-in Central role. Note that Edit rights will let this role edit all person properties. Rock v7 introduced more granular rights on this block that let you control things like Edit Record Status and Edit Connection Status. Feel free to use these to tailor more specific access to your Check-in Central role if you prefer.
4. Back on the Profile page, edit the Family Members block and give Edit rights to the Check-in Central role.
5. Edit a family, and on the Edit Family page modify the security on the Edit Family block and give Edit rights to Check-in Central role.

Known Relationships

Another task a Check-in Central volunteer must be able to do is set Known Relationships, to create a realtionship between (for example) an existing person and a friend or relative they have brought to church, who isn't in their family (this can be done via the registration mode on the koosk when adding a new person, but not after the fact). But right now, when logged in as your test user, you're probably seeing a blue "You do not have enough rights..." box on Known Relationships. Here's how to fix that.

1. Edit the Relationships block on the Profile page and give Edit rights to the Check-in Central role
2. Go to Admin Tools | General Settings | Group Types and edit the rights on the Known Relationship Group Type and give View AND Edit rights to the Check-in Central role.

Misc cleanup

Back on Person Profile, when logged in as your test user you will notice that some things are still showing that you don't want a Check-in Central volunteer to see (remember, we only want to give them the minimum necessary to do the task of editing people, most of which can be done in the Kiosk Registration Mode). From this point on, the decisions are yours, as only you can decide what you want your volunteers to see and what you don't. That said, I will give you a few suggestions:

1. Click the Groups tab on the Profile page and edit the page rights to DENY Check-in Central
2. Do the same for the History page.
3. Do the same on the Timeline, Bookmarked Attributes, and Connection Requests blocks. Bookmarked Attributes may seem like one you want to allow volunteers to use, but it's dangerous... this is because by default, many Person Attributes have All users View rights, which means a volunteer could create a Bookmarked Attribute for any attribute they have rights to, even if you're not showing them on the Profile page. This is why we chose to simply hide that block from that role. The alternative is to go through every person attribute in your system to deny the Check-in central role from the ones you don't want them to be able to bookmark or otherwise see.
4. Consider denying view rights to the Badges blocks on the Profile page.
5. Deny view right on any Attribute Values blocks on the Extended Attributes page you don't want your volunteers to see. As a volunteer, our Extended Attributes page looks like this Like I said, they only see what they need to see ;-)

Loose Ends

Kiosk Registration Mode

As of Rock 8.7 there is a new Kiosk Registration Mode which allows volunteers to register new families much easier than the prior need to give them access to the Add New Family block in Rock. It's important to understand that while this new Registration Mode is part of the kiosk it is NOT meant to be used on unattended (aka "self serve") kiosks, as it would be dangerous to give any random person the ability to search the database and add people to it. Thus, this mode is meant to be used on "registration machines" that are attended by Staff or trained Volunteers.

Rather than just repeat what's already documented, I'll point you to the documentation on how to set up a kiosk device for Registration Mode. Read about using registration mode here. Read about configuring registration mode here.

I suggest created registration-specific Kiosk Devices just for this purpose. If you're a multi-site church, you would want one Kiosk Device (with registration mode enabled) per campus. Once you have the kiosk devices set up and configured, from your Check-In Central portal you just need to click the Add Person/Family button to launch the /checkin URL. Once there, you simply need to select your desired Kiosk from the drop-down, which will be remembered from then on. You would repeat this process for each Registration Kiosk you have at other campuses.

Staff Rights

The entire point of this article is to create a check-in registration portal for volunteers in your organization. By default, your Staff will also see the new Check-in Central menu, too. If you do not want this, just deny that menu from your RSR - Staff Workers (and Staff-Like) roles.

If you only want some staff to have acces to it, just make another Security Role named something like RSR - Staff Check-in Central and let it have access to the new menu, and only add the staff you want to that role. You've come far enough that you don't need step-by-step instructions for that... I'm sure of it.

Check-in Manager

We never got around to granting our Check-in Central role rights to use Check-in Manager. Oops!

1. Browse to /checkinmanager as a Rock admin.
2. Edit the page rights on the /checkinmanger page to add View rights to Check-in Central role.

Accordions

You may have noticed on the very first screen shot in this article that our Check-in Central homepage has several accordions that provide quick access to instructions for volunteers using the system. I didn't provide a step to add them earlier to prevent muddying the waters, but if you want to add them, here ya go:

1. On the homepage, add another HTML Content block below the existing one in the Main zone, or add it to the Section A zone
2. Add the following code to the block:

<div class="col-md-8">
{[ accordion firstopen:'false']}
    [[ item title:'Adding a Person/Family' ]]
       Add your instructions for adding a family here!
    [[ enditem ]]
    [[ item title:'Searching for People' ]]
        Add your instructions for searching for people here!
    [[ enditem ]]
    [[ item title:'Adding a Friend/Visitor' ]]
     Add any special instructions for adding visitors here!
    [[ enditem ]]
      [[ item title:'Troubleshooting' ]]
        Add your troubleshooting steps here! This is a good place to put info on troubleshooting issues with kiosks (ipads or Win clients) as well as printers.
    [[ enditem ]]
{[ endaccordion ]}
</div>




Conclusion

Hopefully this article has given you a working Check-in Central portal that you can use as a starting point for your needs. It should come as no surprise that this is not a 100% complete solution, as there are 1000 different ways to approach it and this is just one way. There are things we didn't get into like preventing volunteers from seeing most Workflows via the Actions menu on the Profile, and I leave fixing that kind of thing to you, since it's such a church-specific decision (hint: you need to modify the rights on any workflow you don't want seen by denying the Check-in Central role view rights to that Workflow Type.)

If you have better ideas for your portal, please go for it! There is no single "right way" to do this, so take this idea and run with it however you want to.