A long while back I typed up a post about test environments. For the same reasons, I need to explain how you can help prevent giving yourself and your users some headaches. Another contractor working SharePoint—I’d rather not call him a SharePoint developer even though it is his title—with a client has a production version of his application on an existing 2010 farm, but it isn’t functioning yet on Office 365 because of all of his coded customization (stuff we should have done out of the box with SharePoint). People continue to hit the site and request elevated rights over the read rights they already have. If they had no rights to the site, this would not be a problem.
The permissions mess is a much longer post, but I need to explain how you build your sites and apps. I immediately remove all permissions from a site, list, or library when I create it to give me time to build it correctly before exposing it to the rest of the users. Why?—
- People shouldn’t see anything under construction, especially when there is a production version running elsewhere. It leads to mass confusion.
- It allows you to screw everything up without others noticing. No one knows everything when it comes to SharePoint, and you may want to try a web part you haven’t used before. Do you really want everyone else to take notice that your web parts are all funky?
- Rarely, should you have the exact same permissions on a site, list, or library that mirror the parent exactly, so you should be breaking inheritance anyway. Like all other basic IT security rules you should know, we want to grant rights based on the on the principle of least privilege. That means that you trim away access for people who don’t need it. People could need contribute rights to all of the other lists on a site, but if their role determines they should not be adding to the list you are making, you grant only read to the role they are in.
- It really can help with testing purposes. You might need to cycle your testing folks through different permission groups separately before you go live, and it is just way easier to kill all of the other permissions until you are ready to go.
So please just stop. Think about what you are doing. Every setting in your list should have been addressed, and you should have made a conscious decision as to how you would configure that setting before you allow anyone access.
I was working with a group of folks the other day who wanted to redesign the site. They had a lot of ideas for one page. They had no ideas for the data that supported what they wanted to present on that page. The site collection already has very poor architecture. When one goes to the root site to the site collection, that person gets two redirections to the final page on a subsite. Whoever created it that way caused all of the lists and libraries on the root site to go untouched for about a year.
In my discussions with them, I had to give them the analogy of a kitchen remodel. One doesn’t just put in a new kitchen. You need plans. You need to do demolition work. You need to account for the electrical, gas, and plumbing that you cannot move. You also need to figure out what you are going to keep from your cabinets. They had a good 30 or more lists and libraries that hadn’t been touched. I’m not going to just leave those defunct lists and libraries there. A new page would be a mere façade over a weak structure.
Over the coming weeks, they are to look at the existing content and identify what they are going to keep and what they want to kill. This is always the first step in redesign work with SharePoint: Knowledge Curation. It could be information curation, but we need to identify why and they are vetting the value of the information, so I elevate this to knowledge. They aren’t just checking to see if something is properly tagged. They are doing more than content management, and it is grunt work because no one had previously built the tools for them to sift through it more easily. To learn more about knowledge curation, here is an article I looked up from KM World.
The next step will be to identify the data definitions of those things they would like to present on the page like pictures on a carousel. I’d rather them not need to do a lot of work to keep their content there, so they need to identify what determines whether or not a picture will be displayed, how they want to add a new picture, if they link, etc.
We will go about creating their content management plan and will have a section for knowledge curation. It should be a continuous process, not something you do once a year. It is like brushing your teeth daily versus getting a scaling once a year by your dentist because the plaque looks like you have fused your teeth together. At some point, your dentist will recommend pulling your teeth and getting you dentures. This is why you see so many people start over with SharePoint sites. They neglect them for so long, they would rather just build a new one. It takes discipline, and it takes a plan.
Scott Brewster works for Data Analytics Solutions. He is got his Certified Knowledge Manager (CKM) credentials through the Knowledge Management Institute (KMI), and he has been working on both the farm administration and front end solution architecture of SharePoint since 2008.