Let us help you turn routine policies and procedures in SharePoint into a compelling user experience.
It can be very frustrating sometimes, not being able to access certain content in SharePoint for an end user. To avoid this, basic understanding of permission levels is crucial. Permission levels are used throughout the entire SharePoint organisation to provide access, from an item level all the way up to a site collection.
Most of the time if you’re not getting access to specific content, it’s because of the permission level that you’ve been provided.
I will try to explain how SharePoint permission hierarchy works in a very simple way to give some understanding from an end users point of view. This will also give you some understanding of the SharePoint structure as well. You may have already been granted permissions to a certain subsite and may be wondering why you still cannot access to another level or subsite within the same site collection.
SharePoint permissions work like Windows folder and file permissions
Like Windows files and folders SharePoint objects inherit permission from parent to child. Permission hierarchy starts at the top of the site collection. So, if we have multiple site collections, each site collection has its own individual permission levels to work with which by default are inherited from the top level to the item level.
Permission inheritance traverses all the way down through the permission hierarchy
As seen in the diagram within the site collections, we have subsites. Within subsites, we have list and libraries. Within lists and libraries, we may have folders, and in folders, we may have list items or documents. By default, we have permission inheritance that is carried from site collection to the list items/documents level.
Site collection determines what permission levels are available at the different levels.
What happens if anywhere along this hierarchy we break the permissions?
If we have created unique permissions (as in SubSite 3 in the diagram) means we’ve actually broken the inheritance, meaning all other subsites/lists/libraries underneath will inherit from this. So we’re no longer inheriting permissions from the site collection level.
What happens next? SubSite 4 is now inheriting the permissions that we defined at SubSite 3, which means folders, lists and libraries under SubSite 4 are inheriting from SubSite 4.
It’s a permission hierarchy that continues from top to the bottom level unless you break the inheritance. So, you may be in one of the Sub Sites, then all of a sudden, you try to go to a list or a library and you can’t access it. Well, it’s because you don’t have the appropriate permissions because someone has broken the inheritance.
How do I get an access to a certain library?
When you’re trying to work with content in SharePoint, if you’re not getting access to this specific content, now you know it’s because of the permission levels. As an end user in a collaboration environment, there is not much you can do about this other than sweet-talking site owners or site collection administrators into giving you permissions to that list or library as they are the ones who control the level of inheritance and permissions.
A word of warning: Too many unique permission items at the same level can slow things to a halt.
12 Jan 2017
From a client-side point of view, SharePoint offers a lot when it comes to resources that can be leveraged from frameworks such as Ember or Angular.
SharePoint offers the following services:
- Document libraries
- A robust security model
- User profile store
- Extensive REST API and much more…
SharePoint developers (SharePoint farm solutions developers) have been leveraging successfully of these resources to build enterprise systems for many years. This has had sometimes not so good results due to the fact that these solutions can sometimes affect the whole SharePoint server farm in a way that is detrimental to anything else running in that server farm.
The solution for this as dictated by Microsoft with the introduction of the app model is to make more use of the “platform” personality of SharePoint. This allows effectively to write code that does not run within the same process as SharePoint code does and helps to avoid (most of the times at least) the common pitfalls of SharePoint farm solutions.
Sample customer ordering system built in combination with SharePoint + EmberJS
Here is a good example of such use of SharePoint by employing Ember JS coupled with a few lists in SharePoint to build an order management system.
The ingredients for this hypothetical system are:
- Two SharePoint lists (Customers and Orders with the required metadata)
- EmberJS used to provide front end and business logic
- SharePoint JSOM / REST API to allow Ember to work with list data
- A Single Html Page (or SPA) containing css references and handlebars templates for use in the system
- app.js referenced within the html page
- A document library to host the page and its client resources
The following is sample code used in app.js
Note: In the code snippet above SPData represents an abstraction to using a combination of SharePoint rest services or simply JSOM.
The advantages of building your business app this way are multiple: Easy to change and quick to adapt without lengthy deployments and the guarantee of no custom code being executed with your SharePoint process.
In conclusion; the use of sophisticated client-side frameworks combined with SharePoint web services can provide an ideal environment for your next business application.