The term Permissions is used in multiple places, with different meanings
Item Level Permissions:
Set in: List Settings -> Advanced settings:
(note: you CAN set this for Libraries, not through the UI, only with code)
Item Level Security
In many blogs (like this one) this IS called Item Level PERMISSIONS
Set in: List Settinngs -> Permissions for this List
- Break Role Inheritance on a List/Library
- Assign (custom) Permission Profile
documentated limitations (Item Level SECURITY):
(march 2013) Software Boundaries and Limits: Unique Permissions
(october 2015)Thresholds and Metadata
From Office Support:
Question
With List Settings->Advanced Settings->Item-Level Permissions you do NOT BREAK inheritance of permissions
Does using these Item Level Permissions have influence on the 50,000 threshold?
does this setting (ILPermission, not ILSecurity) create a "Security Scope"?
https://technet.microsoft.com/en-us/library/cc262787.aspx?f=255&MSPPError=-2147217396
says:
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.
In my understanding
ILP is just like a View with a [Me] filter, the setting only ensures queries by a user (other then the Owner of the List) can never get/set other then his own Items.
The Item itself is not secured (the Note "Users with Cancel Checkout permissions can read and edit all item" is a clear indication)
The List (and not the Item) IS the Security Scope.
Since it its a similar concept like the [Me] filter I would assume it has nothing to do with Security or Threshold values.
List Settings -> Advanced settings -> Item-level Permissions
settings are implemented internally, and always thought of them like of some kind of UI trimming mechanism - like[Me]
filter, as you said. I have an installation with a list that has around 20000 unique item permissions defined - should setRead access
toRead item that were created by the user
and see if SQL queries change. Should be able to do this week.Unique permissions limit
(50000) getsReadSecurity
changed. IfReadSecurity
counts against that limit, I'll get an error, right? Also there are some potentially useful SQL queries at reality-tech.com/…