使用BreakInheritance和处理ACL的SharePoint

Question

我正在使用一些需要细粒度列表项权限的文档库，其中一些组可能会看到某些列表项，而其他组则不能。显而易见的解决方案似乎是打破列表项的继承，并单独分配权限。问题是其中一些库的大小约为10,000个列表项目，而且还在不断增长。据我所知，这可能是为这么多项目分配权限的一个大问题。

据我所知，每次在给定的作用域(作用域是站点级别、列表、列表项等)上的继承被破坏时，都会创建一个访问控制列表(ACL)。因此，如果我中断了10k列表项的继承，我就创建了10,000个ACL，这是SP在屈膝之前可以存储的限制，并抛出一个错误(参见：http://blogs.msdn.com/b/willstan/archive/2009/03/03/the-attempt-to-release-mutex-not-owned-by-caller-exception-what-is-it-and-how-to-avoid-it.aspx)。这一切看起来都很糟糕。显然，有一个知识库可以消除这个错误(http://support.microsoft.com/kb/968859)，但如果它生成如此多的ACL，这种技术似乎仍然值得怀疑。

对此有何看法？

Answer 1

是的，你不仅会遇到这个问题，而且维护也会成为一场巨大的噩梦，因为你不知道哪个项目是为谁许可的。打破每个库的权限并移动项目要好得多。

虽然从一开始就很难移动具有历史等内容的文档，但在持续的痛苦和痛苦中节省的成本是巨大的。

您可以使用内容two部件合并这两个文档库。

否则，您可以通过这种方式创建文件夹和权限。

因此，我的2美分价值是为您需要的每个主要的不同权限级别创建一个库或文件夹，并创建一个脚本来移动内容。

对我来说，文件夹不是很好，但优点是它们确实将所有内容都保存在一个列表中。

还要注意，SharePoint有5000 items per query的限制，因此您可以通过稍微分隔列表来获得一些值。