Hiding The Toolbar in Sharepoint 2010

The Toolbar is one of those in-between metaphors in the Sharepoint 2010 environment. It is designed to make things more comfortable for people used to Office 2010, yet it makes using a web metaphor complex and somewhat needlessly difficult. Here is how you hide it.

Why You Want To Hide It But Not Pull It Entirely
Really, Sharepoint is constructed to rely on the damn thing. Unfortunately, if people don't have permission to do shit on your site - and most of your users are readers, not contributors - you don't really want them poking around the various grayed-out links.

1. Pop open Sharepoint Designer and find the site you need to get into.
• Side nav - Master Pages
• Your custom master page from when you wiped the basic sharepoint page.
• Edit file
• Check out the file.
2. Look for this tag: <SharePoint:SPRibbon runat="server" PlaceholderElementId="RibbonContainer" CssFile="">
3. I like to label mine things like <!-- === THE RIBBON STARTS HERE == --> for future reference, but all that should be in your minimal master page.
4. The next thing to do is decide what permissions people should have before they can see your ribbon. I like "edit list items." 
1. <Sharepoint:SPSecurityTrimmedControl ID="SPSecurityTrimmedControl2" runat="server" PermissionsString="EditListItems">
2. every other piece of ribbon content goes in here.
3. </Sharepoint:SPSecurityTrimmedControl>

So how does this work?

Permissioning is still your only job. You now have two groups of users, Everyone, who have read permissions and can't touch anything on the site, and whatever group you assign to have other permissions. In theory, this will work to control the whole site - the ribbon will just not be there when they log in. 

Sometimes You Just Need To Trust People

However, this means that you need to grant pretty high permissions to anyone who wants to edit anything on the site, and that includes things like, say, a calendar. For some reason, presumably because the ribbon is set at the master page level, you can't just issue edit list permissions on a specific list (everything in sharepoint is a list) and have the ribbon load properly on that list alone.

In theory, there is a provision for this by "allowing" people to "hide" or "display" the ribbon.

In practice, for the group you want to be able to edit and access that calendar (or list generally), create a group, give that group Edit List permissions on your site, and trust in the panopticon to let you know who, exactly, fiddled with what. They probably won't, you can definitely see what they did if they do, and turn on version control for the site. Welcome to systems administration, which - much like the future generally - is slightly less than promised.

Audience Settings Hide Things In Plain Sight

In some institutions, the intranet is controlled by a panoply of people. They all have equal permission to ask you to do something, and they all can see what appears to be the full intranet. They do not, however, all do the same work. They do all run out of things to do at about the same time each week. About that time, they start looking for things to do, rather than bunking off work or reading a book under their desk.

Although, as previously established, you don't like your job or anyone who tells you you're lucky to have it, you are proud of your work, and you like letting other people do theirs, too. Mostly the people who control some levels of content are not so tight with the analytics, which routinely fail in Sharepoint 2010 installations anyway.*

*Really, there's no information on the internet as to why they simply crap out, but as a front end administrator you're powerless to fix the problem. Batch start as many jobs as you like, adjust all the timers you want, you're still boned.

 So how can Sharepoint help with office busybodies?

Just as you can set permissions so that people can access a thing, you can set audiences so that their group is the only one to see that thing. Or to not see it. This is usually set in the navigation.

• Open Site Settings, People And Groups.
• No, wait. Open Site Permissions.
• Notice that unless a permission has been explicitly set to a piece of content as a permission within your site, the group you want doesn't show up even if it does exist already.
• Great now People And Groups.
• By default it will open your default Members Group for whatever Site you happen to be on. Misleading!
• Look on the left nav. There will be a thing called Groups. There will be a More link. You want the More link.
• The More link will lead you to People And Groups: All Groups. 
• Due to weird convulsions in Sharepoint's site settings, expectations, team site settings, and pre-loaded "site features," it is entirely possible none of this is real or will work for you.
• All Groups has a list, for editing, of every single group in the entire site and all of its subsites. You can actually see what is going on here, which is why it is incredibly well hidden. It is a feature of use.

In All Groups you can set up new groups and see groups that are not necessarily relevant to specific permissioning, and here is where you will set up your new group, seeHiddenThings.

• Click New at the top of the page. There's also a settings link where you can make the left nav of people and groups more useful.
• Name your new group.
• Populate your new group with people you want to be able to see whatever link to whatever thing.
• Leave people and groups and go to Site Settings, Site Navigation.
• Set up your new link to whatever. 
• Note that, although Sharepoint nominally inherits things from one stage to the next, it has trouble tracing where you actually are within its file structure. Have an ominous sinking feeling about that, which you will not address for some time to come.
• On your New Link, set your Audience to your new group. Note that you can set the Audience for this link to be whomever you like - anyone in Active Directory, any pre-existing group.
• It is, however, much easier to just remember that Group Linkname can see and access Link In Question.

Boom. People not in that group cannot see that link. Unless you named yourself to that new group, you can't see that new link. No-one can see it but the people in the group.

If you were extra smart, it is a link to a private list or library, too.

Permissioning Is Your Only Real Job

Permissioning is keeping things private while waving them about in public. Once you've branded your Sharepizzle installation and gotten the hang of hitting the "create subsite" and "activate site feature that really should already be active" buttons, your entire world will compress to permissioning. It is best to get it right from the start.

Permissioning is really, really handy in Sharepoint. I will go so far as to say it is one of perhaps two things they have mainly gotten right. It applies to everything in a sharepoint install, at every level, and you can control it for real. You can always tell what parts of the enterprise software are actually valuable and which are colossal wastes of time and funding by what's fixed from install to install. Permissions have been tightly controlled from the start, yet managed to improve in 2010. Surprise. I am actually surprised.

Your ability to control permissions, and break them horribly to do things they were never intended to support, is one of your great powers. If you were a good IT Person,* you might plan for their inheritance and carefully sort through the benefits and disadvantages of a coherent permission approach.

*You aren't a good IT person. If life were a Choose Your Own Adventure novel, you would be one bad move away from being eaten by Ant People. The bad move was choosing this book to begin with.

Permissions have a bunch of levels. Here's some key theory:

• You can use permissions to hide things, both in inline code/layouts and with the various Audience Settings.
• This includes the hateful Ribbon metaphor.
• Initial Sharepoint access and accounts are set, usually, through your institution's Active Directory.
• As addressed previously, this makes individual user accounts mostly not your issue.
• Sharepoint groups by default tend to have one of three permission levels, Full Ownership, Contribute, or Read. These are mostly what you need. People can Contribute, or Read.
• Individuals can have individual permissions set per site or list
• Groups hold individual accounts and are strongly preferred for setting permissions.
• Groups cannot contain other groups, ever, for any reason.

Group Permissioning Is Preferred. But Why?

Ideally, all permissions for all subsites and lists on your Sharepoint site are inherited. That is to say, you set them at the top, and like Republican wealth, they trickle down. In reality, as in reality, they do no such thing: you will be breaking permission inheritance for people from Day One, because people do not actually want to share on these sites, but that is the theory.

When you set individual account permissions, they get written to somewhere other than the Active Directory. The account lives on regardless of whether the individual still works in the building, and sometimes regardless of whether their AD account still exists in the system.

Ghosts in the machine will therefore lard your site like fat in bacon. You will not be able to get them out without an overview of every employee in the company. It is therefore best to keep them inside of groups, where the general group has the permissions, rather than trying to keep tabs on who's been hired or fired this week.

Why Can't Groups Contain Other Groups?

This prevents permissioning recusion and inheritance attacks, in theory, where a group set to full control in one place is nested in a Contribute somewhere else. That was a guess. I have no idea, because sometimes groups which explicitly have one level of permission (Full Control) still don't have Full Control over sites or objects they nominally Control The Fullness Thereof.

This sort of weird inheritance problem happens a lot with this software. It is normal. It makes the line of the Bourbon Kings look clean and straightforward.
The Bourbon Kings have nothing to do with alcohol per se, and don't we wish we could say that about you once you're done sorting this garbage out.

How many levels of permission can I set?

You can set specific permission levels on anything in Sharepoint. Each subsite, each list, each folder and item can have independent permissions set. This is valuable because those permissions are largely effective. You set them explicitly and name the accounts with permission, and those accounts can see pretty much exactly that thing you shared with them, and nothing else.

Problematic in that sometimes this means they can't see the inheritance breadcrumb or suckerfish menu to get to that site, useful because they are going to just check their Outlook for the link every time anyway.