Data barriers and Software boundaries, limits for SharePoint


Software boundaries and limits for SharePoint 2013
30,000,000 per list,
You can create very large lists using standard views, site hierarchies, and metadata navigation. This value may vary depending on the number of columns in the list and the usage of the list.

Security scope
50,000 per list
The maximum number of unique security scopes set for a list cannot exceed 50,000.
For most farms, we recommend that you consider lowering this limit to 5,000 unique scopes. For large lists, consider using a design that uses as few unique permissions as possible.
When the number of unique security scopes for a list exceeds the value of the list view threshold (set by default at 5,000 list items), additional SQL Server round trips take place when the list is viewed, which can adversely affect list view performance.
A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to SharePoint Server 2013. The members of an ACL for a scope can include Windows users, user accounts other than Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.”


Data Barriers

SharePoint: Easy Row Level Security
“1) Create SharePoint Groups, 2) The Lookup List, 3) The Target List, 4) The Workflow, 5) Test”
How to restrict user to see only few rows in a list
“If is only about viewing, then you should probably consider Views or go for Target Audience (this is will hide items from view automatically without changing permissions – does require User Profile)
If you really need permissions than try building a workflow on particularly those conditions so that everytime a new list item gets added permissions are set”



Simultaneous Editing in SharePoint
“Early versions of SharePoint allowed only single-user editing of a document while other users had read-only access until the document was checked in. SharePoint 2010, however, has taken document collaboration to the next level. No more waiting for a document to be checked in before you can begin editing. This new functionality is ideal in an environment where people must work collaboratively on a single work product, such as a proposal or agile development. This collaboration feature creates zones in a document so authors can work on different areas of the document concurrently. To start editing documents collaboratively in SharePoint, you must update configuration settings for permissions, versioning and check-in/checkout capabilities.”
How do I handle concurrency problems related to event receivers?
“I’ve always had to handle the concurrency issues. On SP 2010, I’ve done these things:
1) Set the Synchronization property of your receiver to SPEventReceiverSynchronization.Synchronous.
2) Disable event firing within the receiver methods e.g. this.EventFiringEnabled = false;
3) When working with Properties.ListItem object, check if it’s not null before doing any processing.
4) Check if the item updated event was not caused by a check-in, using the following code:
if (properties.AfterProperties[“vti_sourcecontrolcheckedoutby”] == null && properties.BeforeProperties[“vti_sourcecontrolcheckedoutby”] == null) { }”