SharePoint性能和使用工作流设置项目权限

If you create your solutions on SharePoint sooner or later you will come upon a request to set  permissions of the item depending on some of the item's meta-data - the author, people assigned as approvers, divisions, categories etc.

如果您迟早在SharePoint上创建解决方案，则会要求您根据项目的某些元数据（作者，分配为批准者的人员，部门，类别等）来设置项目的权限。

The most natural way to tackle such request would be to have a event-handler or a workflow running when item is created or modified and modify current item's permissions. It very simple with any workflow solution - you just need to use the "set item permissions" activity.

解决此类请求的最自然的方法是在创建或修改项目以及修改当前项目的权限时运行事件处理程序或工作流。 任何工作流程解决方案都非常简单-您只需要使用“设置项目权限”活动即可。

If you deploy it on some small list (up to 50 items) with small number of users (4-5) then everything will work fine. If you try to implement it on larger list (few thousand items) with larger number of users then you may run into serious performance issues. You can experience long page load times, very high load on the SQL processor, timeouts for queries, IIS and OWS Timer unresponsiveness and workflow crashes.

如果将其部署在用户数量较少（4-5）的一些小型列表（最多50个项目）上，那么一切都会正常进行。 如果尝试在具有更大用户数量的更大列表（几千个项目）上实现它，则可能会遇到严重的性能问题 。 您可能会经历较长的页面加载时间，SQL处理器上非常高的负载，查询超时，IIS和OWS计时器无响应以及工作流崩溃。

The information about unique item permission limits can be found:

可以找到有关唯一项权限限制的信息：

- here for 2007 - http://msdn.microsoft.com/en-us/library/cc287790%28v=office.12%29.aspx

-2007年-http://msdn.microsoft.com/zh-CN/library/cc287790%28v=office.12%29.aspx

- and here for 2010 - http://msdn.microsoft.com/en-us/library/cc262787.aspx 

-此处为2010年-http://msdn.microsoft.com/zh-CN/library/cc262787.aspx

(look for the "Security scope") but it's worth clarifying what it exactly means.

（寻找“安全范围”），但有必要弄清楚它的确切含义。

For both SharePoint 2007 and 2010 there are limits of 1000 unique security scopes for a list. Microsoft defines a security scope as a "security boundary for a securable object and any of its children that do not have a separate security boundary defined".

对于SharePoint 2007和2010，列表的限制为1000个唯一安全范围 。 Microsoft将安全范围定义为“安全对象及其未定义单独安全边界的任何子级的安全边界”。

In other words this is a single entry of a permission level-user(group) pair for a single item. If you do not break the inheritance for any item, the total number of scopes for the list will be equal to the number of scopes for the list itself (you can view it by going to list permissions page). If you break inheritance for 2 items then the total number of  scopes for the list will be then number of scopes for the list itself + the scopes for each item. And if you set permissions on user levels, then the list will automatically get new scopes for each user with the "Limited access" permission level, which then can be inherited by items that have their permission broken and before you know you end up with not 1000 but 50.000 security scopes.

换句话说，这是单个项目的权限级别-用户（组）对的单个条目。 如果不中断任何项的继承，则列表的作用域总数将等于列表本身的作用域数目（您可以通过转到列表权限页面进行查看）。 如果您中断2个项目的继承，则列表的范围总数将是列表本身的范围数量+每个项目的范围。 并且，如果您在用户级别上设置了权限，则该列表将自动为具有“受限访问”权限级别的每个用户获得新的作用域，然后这些权限可以由权限被破坏的项目继承，并且在您不知道之前1000但50.000安全范围。

The cause of the problem is laying in the way SharePoint tackles the permission settings.I guess that when the SharePoint team has designed this functionality they did not think that people would break the inheritance this much. Having a workflow do it automatically for you can get you very quickly past the recommended limits.

问题的原因在于SharePoint处理权限设置的方式。我猜想，当SharePoint团队设计了此功能时，他们认为人们不会这么大地破坏继承。 有了工作流程，您可以自动完成建议的限制。

What's worth mentioning is that Microsoft states that in case of exceeding the limits the impact of the performance degradation will be the entire farm not only the list where the security scope exist! This is something I can confirm because we have found out this problem on our own while deploying a solution for our customer (This limitation was documented only in the second half of 2010) - when our farm started to run terribly slow we started looking for the cause and after analyzing all the queries and SQL tables we saw what has happened.

值得一提的是，Microsoft声明，如果超出限制，则性能下降的影响将不仅是存在安全范围的列表， 还将是整个服务器场 ！ 我可以肯定这一点，因为我们在为客户部署解决方案时就独自发现了这个问题（此限制仅在2010年下半年才得到记录）-当我们的服务器场开始运行非常缓慢时，我们开始寻找原因并分析了所有查询和SQL表之后，我们看到了发生了什么。

There is no good workaround for this problem.

此问题没有好的解决方法。

One of the solutions could be using folders - you can set up permissions for few folders and then put items in those folders based on their parameters. The benefit from this solution is that permission inheritance is broken only on the folder level, so even if you have few thousand items in each folder, they all inherit permission scopes from the folder, so the number of scopes does not rise with each new item.

解决方案之一可能是使用文件夹-您可以为几个文件夹设置权限，然后根据其参数将项目放在这些文件夹中。 此解决方案的好处在于，权限继承仅在文件夹级别被破坏，因此，即使每个文件夹中有几千个项目，它们也都继承了该文件夹的权限作用域，因此作用域的数量不会随着每个新项目的增加而增加。

This solution has few downsides - you need to have a limited number of security combinations (like only A, only B, only A&B, only A&B&C, only B&C, etc), because if you would like to have a separate folders for all possible combination for 100 users then you will get nowhere. Second problem is that SharePoint does not allow you move an item into a folder - you need to create a new one in the folder and delete the existing one. And once you do it you loose your workflow, workflow history, change the item ID and link to it and will need to tackle it as well.

此解决方案的缺点很少-您需要具有有限数量的安全性组合（例如，仅A，仅B，仅A＆B，仅A＆B＆C，仅B＆C等），因为如果您想为所有可能的组合使用单独的文件夹100个用户，那么您将无处可寻。 第二个问题是SharePoint不允许您将一项移动到文件夹中-您需要在该文件夹中创建一个新项并删除现有项。 完成后，您将失去工作流程，工作流程历史记录，更改项目ID并链接到它，并且也需要解决它。

Other solution is to remove everyone's permission to such list and create your own web parts that will run with elevated privileges and will take care of the presentation of the list and it's items and restricting permissions. This means that SharePoint list would serve only as a database and you would need to code all other functionality (list views, display and edit forms, web services, etc) yourself.

另一种解决方案是删除每个人对此类列表的许可权，并创建自己的Web部件，这些Web部件将以提升的特权运行，并将负责列表及其内容和限制权限的显示。 这意味着SharePoint列表仅用作数据库，您需要自己编写所有其他功能（列表视图，显示和编辑表单，Web服务等）的代码。

Hope you will benefit from this Article and look forward to your comments.

希望您将从本文中受益并期待您的评论。

翻译自: https://www.experts-exchange.com/articles/4782/SharePoint-performance-and-setting-item-permissions-with-a-workflow.html