Best way to allow specific group members to login to Rock and ONLY see specific items?

Question

0

Best way to allow specific group members to login to Rock and ONLY see specific items?

Jim Michael posted 10 Years Ago

I need to know the best strategy for allowing members of a group to log into Rock and see ONLY very specific things... like, the pages within one menu off of the main menu. In order to have a non- staff/staff-like/admin person log in at all, I think I have to give the group rights to the homepage, but this then gets inherited by a WHOLE bunch of other pages... is the correct course to do this, then go to each page that was inherited and add a specific deny for the group? Or is there a better way to let members of a new group log in and see only one menu (essentially)?

Bronson Witting · Accepted Answer · 2016-01-19T09:56-07:00

2

Bronson Witting replied 10 Years Ago

The permission inheritance always works in a top-down fashion. Since the internal home page has the menus as it’s child pages, it’s easy to manage permissions from those menu pages. Here’s an example:

We did this for our check-in volunteer accounts - they need to see some of the home screen, add new families, edit people, and nothing else. So I added View permissions for that group on the home page (and removed it from most of the home page blocks except a check-in specific one) and then specifically Denied view for that group for each menu page under the home page (like the tools menu) - then that deny gets inherited by all of the pages under that menu. So basically that group sees only a stripped down people menu, but can add a new family and search. And adding new pages works great with inheriting the Deny permission for that group!

Example Staff Home Page View:

2016-01-19 11_50_11-Home _ Rock RMS.png

Same page with check-in uesr permssions:

2016-01-19 11_49_37-Home _ Rock RMS.png

Edit Answer

The permission inheritance always works in a top-down fashion. Since the internal home page has the menus as it’s child pages, it’s easy to manage permissions from those menu pages. Here’s an example:

We did this for our check-in volunteer accounts - they need to see some of the home screen, add new families, edit people, and nothing else. So I added View permissions for that group on the home page (and removed it from most of the home page blocks except a check-in specific one) and then specifically Denied view for that group for each menu page under the home page (like the tools menu) - then that deny gets inherited by all of the pages under that menu. So basically that group sees only a stripped down people menu, but can add a new family and search. And adding new pages works great with inheriting the Deny permission for that group!

&nbsp;

Example Staff Home Page View:

&nbsp;

Same page with check-in uesr permssions:

<p>The permission inheritance always works in a top-down fashion. Since the internal home page has the menus as it’s child pages, it’s easy to manage permissions from those menu pages. Here’s an example:</p>

<p>We did this for our check-in volunteer accounts - they need to see some of the home screen, add new families, edit people, and nothing else. So I added View permissions for that group on the home page (and removed it from most of the home page blocks except a check-in specific one) and then specifically Denied view for that group for each menu page under the home page (like the tools menu) - then that deny gets inherited by all of the pages under that menu. So basically that group sees only a stripped down people menu, but can add a new family and search. And adding new pages works great with inheriting the Deny permission for that group!</p>

<p>&nbsp;</p>

<p>Example Staff Home Page View:</p>

<p><img alt="2016-01-19 11_50_11-Home _ Rock RMS.png" src="/Content/RockExternal/Users/bwitting/2016-01-19 11_50_11-Home _ Rock RMS.png" /></p>

<p>&nbsp;</p>

<p>Same page with check-in uesr permssions:</p>

<p><img alt="2016-01-19 11_49_37-Home _ Rock RMS.png" src="/Content/RockExternal/Users/bwitting/2016-01-19 11_49_37-Home _ Rock RMS.png" /></p>

<p>The permission inheritance always works in a top-down fashion. Since the internal home page has the menus as it’s child pages, it’s easy to manage permissions from those menu pages. Here’s an example:</p>

<p>We did this for our check-in volunteer accounts - they need to see some of the home screen, add new families, edit people, and nothing else. So I added View permissions for that group on the home page (and removed it from most of the home page blocks except a check-in specific one) and then specifically Denied view for that group for each menu page under the home page (like the tools menu) - then that deny gets inherited by all of the pages under that menu. So basically that group sees only a stripped down people menu, but can add a new family and search. And adding new pages works great with inheriting the Deny permission for that group!</p>

<p>&nbsp;</p>

<p>Example Staff Home Page View:</p>

<p><img alt="2016-01-19 11_50_11-Home _ Rock RMS.png" src="/Content/RockExternal/Users/bwitting/2016-01-19 11_50_11-Home _ Rock RMS.png" /></p>

<p>&nbsp;</p>

<p>Same page with check-in uesr permssions:</p>

<p><img alt="2016-01-19 11_49_37-Home _ Rock RMS.png" src="/Content/RockExternal/Users/bwitting/2016-01-19 11_49_37-Home _ Rock RMS.png" /></p>

Save Cancel

Jim Michael

10 years ago

Awesome, thanks! I was making it too difficult in my mind, forgetting about the inheritance and thinking I'd have to specifically deny all child pages. Doing it at the top level menu makes total sense.
Jay Greentree

10 years ago

Ever have a moment you don't know you need something until you see it? This is one of them for me.
Ken Roach

9 years ago

Bronson, would you be kind enough to post how you added those buttons on the main page? (Excuse my ignorance.) And the Check-in Documentation links - are they buttons too? Thanks, Ken

Question

0

Best way to allow specific group members to login to Rock and ONLY see specific items?

2