覆盖 SPList.WriteSecurity 行为？
正如MSDN所述，那么WriteSecurity有1可能有 3 种状态：
- 1 — 所有用户都可以修改所有项目。
- 2 — 用户只能修改符合以下条件的项目 他们创造。
- 4 — 用户无法修改任何列表 物品。
但如果我想要行为nr。 2加上用户可以修改分配给他们的项目？ 好吧，如果我授予用户列表的完全权限（放入所有者组），那么这些用户可以编辑任何项目（不好）。 那么为什么它不能通过仅为AssignedTo 用户设置项目级别权限“完全控制”来工作（好）？ 我这样做了，但这并没有帮助 - 访问被拒绝。
我想要的功能正是问题“
- 每个用户（主管和团队成员）都可以查看任何任务。
- 主管可以编辑任何任务
- 团队成员只能编辑自己的任务（分配给他们或由他们创建的任务）
但尽管答案已被接受，但该解决方案没有为用户提供编辑分配给他们的项目的方法 或由用户创建的项目。
感谢您的帮助，谢谢！
As MSDN states, then WriteSecurity has 1 of 3 states possible:
- 1 — All users can modify all items.
- 2 — Users can modify only items that
they create. - 4 — Users cannot modify any list
item.
But if I want behavour nr. 2 plus users can modify items that are assigned to them? Well if I grant a user full permissions (put in owners group) for list, then those can edit any item (not good). So why wouldn't it work by setting item level permission "full control" just for AssignedTo user (good)? I did, but that didn't help - access denied.
I want exactly the functionality as stated in question "Automatically set list item permission, after new item is created", quoting:
- Every users (Supervisor and team members) can see any tasks.
- Supervisors can edit any tasks
- Team members can only edit their own tasks (tasks that were assigned to them, or created by them)
but although answer has been accepted, the solution does not provide a way for users to edit items assigned to them or items created by user.
Help is appreciated, thank You!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
执行此操作的唯一方法是使用基于项目的权限。 例如，让工作流或事件处理程序根据您的要求更改每个文件/对象的权限。
您从其他任务中引用的解决方案只是为
SPList.WriteSecurity设置2，这仍然无法让用户编辑他们不的内容创建，但被分配给 - 在这种情况下，您需要授予这些用户权限，例如通过使用事件处理程序 (OnItemUpdated) 侦听“分配给”字段并授予相应人员所需的许可。此外，该解决方案讨论了为始终能够编辑项目的用户（经理）设置更高的权限，这是一个解决方案，但在此类情况下您没有通常需要的粒度。
Your only way to do this is using Item-Based Permissions. E.g. have a Workflow or Event Handler change the permission on each file/object based on your requirements.
The solution you quote from the other task is simply setting
2forSPList.WriteSecuritywhich still doesn't give users the possibility to edit something they have not created, but were assigned to - in this case you will need to give these users permission, e.g. by listening on the "Assigned To" field with an Event Handler (OnItemUpdated) and give the respective person the needed permission.Furthermore the solution talks about just setting higher permissions for the users who should always be able to edit items (managers), which is a solution, but you do not have the granularity you usually want in situations like these.