Obstacle: Limiting accessibility and viewable content by user permissions

If a client’s website is built using SS CMS, the developer may wish to limit what the client has access to and/or what they can see in the CMS.

Current permissions (Who can edit this inside the CMS?) operate by “graying out” pages only, but allow viewing.

Solution Needed: Expanded permissions through modification to current build that would hide pages in the Site Map Tree.

Suggested Customization: When a user logs in with EDITOR PERMISSIONS they would see a different “stripped-down” version of the CMS (see Fig. B). Note, many of the tabs have been removed along with buttons above the Site Map Tree and Top Nav elements. Fig. B is the CMS View while logged in with EDITOR PERMISSIONS.

This permission can be controlled when logged in with ADMIN PERMISSIONS under the Access Tab (see Fig. A). Note the addition of "Who can edit & VIEW this page in the CMS".

If any one has any insight on how to make these changes, I'd be grateful if you could post.

Thanks!

I like the idea of a more robust security module like this one. The security settings is one thing that I find lacking in most cms's.

pureprop, you got your figure a and b mixed up in your explanation there. Fig B is the stripped down one.

Fixed. Thanks!

I really like the idea of limiting the site tree view to only pages that you have permission to edit as well as hiding tabs, it would make it a lot more user friendly to those people who might be intimidated by so many places to click.

nice one pureprop :) does anyone know how difficult this would be to implement?

EDIT: I have an idea how to hide the tabs, will get back when i 've tried it out

Ok, I've found a way to remove unwanted tabs from the CMS Main area if you are not logged in as an admin:

function getCMSFields() {
		$fields = parent::getCMSFields();
if(!Member::currentUser()->isAdmin()){
					
			$fields->removeByName("Access");
			$fields->removeByName("Behaviour");
			$fields->removeByName("To-do");
			$fields->removeByName("Reports");
			$fields->removeByName("Meta-data");
			
		}
return $fields;	
	}
		

Nothing ground breaking, but it seem to do the trick. Also if you set the permissions to be 'LeftAndMain in CMS' & 'Main in CMS' then you will only have the 'Site Content' tab at the top and then if you add 'asset admin in CMS' then you will get the 'Files and Images' tab too.

If you want to do this based on a group, you can change the if statement to be if(!Member::currentUser()->isInGroup(groupID)) and replace groupID with the ID of the group you want to remove the tabs for.

Anyway that gets up part of the way there, now does anyone know about hiding site tree objects? :D

I looked into this. Looks like the DataObjectSet::getChildrenAsUL() is the key method. It doesn't do any permission checks when it builds out the list, which seems surprising to me.

They solution would be to decorate the DataObjectSet class and use a custom getChildrenAsUL() method, but it seems that decorators don't override methods unless their owners grant them the extend() method. Seems weird. I'm sure there's a way to do it. I'll make another post.

Thanks for the input thus far. I have the developer I work with looking into this as well.
He's good at figuring this stuff out so I will let you know what he comes up with.

Does anyone know if something like this will be included in the next build?

to expand a bit on the "why" of pureprop's suggestion:

first,
when we developed our client's website using the cms, we went above and beyond our initial commitment of adding a cms to only one section of client's website, assuming that they would want a cms added to more sections as they became proficient in using it.

the dilemma, once we added the additional cms areas, was that the client could SEE that we had worked ahead, and therefore the impression would be that we were billing for work that was already done - an easy assumption since it appeared to the client that it all was part of our "phase 1" - even tho we were simply working ahead.

second,
our client is a large firm with multiple admin levels. therefore, no one person can draft & publish content. for this reason, we need permissions that reflect a chain of command, ie:
- super admin
- client admin
- editor
- user

super admin is the creators of the site & cms (us)
client admin is our client's IT department, or the client themself
editor is in charge of approving content and authorizing publication
user is responsible for writing content and saving as draft for editor's consideration

usergroup systems like this exist in cms/blog software such as Serendipity (s9y.org). i dont see how we can utilize SS CMS in a corporate environment unless we have a function such as this.

removing the tabs is helpful, but the real dilemma is hiding the site content & publication rights (and for me, currently, if i am signed in as a user without editing permissions, i get kicked out instead of being told 'you dont have permission to do that").

i do hope this is something that can be added to the current build, because other than this issue, overall the SS CMS is perfect for many of my clients' needs!