覆盖SPList.WriteSecurity行为? [英] Override SPList.WriteSecurity behaviour?

问题描述

如 MSDN 所述， WriteSecurity具有3种可能状态中的1种:

As MSDN states, then WriteSecurity has 1 of 3 states possible:

• 1-所有用户都可以修改所有项目.
• 2-用户只能修改那些 他们创造.
• 4-用户无法修改任何列表 项目.

• 1 — All users can modify all items.
• 2 — Users can modify only items that they create.
• 4 — Users cannot modify any list item.

但是，如果我想要表现 nr. 2 加用户可以修改分配给他们的项目吗?好吧，如果我向用户授予列表的完全权限(放入所有者组)，则这些用户可以编辑任何项目(不好).那么，为什么仅通过为AssignedTo用户(好)设置项目级别权限完全控制"呢?我做到了，但这无济于事-访问被拒绝.

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.

感谢您的帮助，谢谢！

推荐答案

您唯一的方法是使用基于项目的权限.例如.让工作流或事件处理程序根据您的要求更改每个文件/对象的权限.

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.

您从其他任务中引用的解决方案只是将SPList.WriteSecurity设置为2，但这仍然无法使用户编辑自己创建的未但已分配给-在这种情况下，您需要授予这些用户权限，例如通过使用事件处理程序(OnItemUpdated)侦听分配给"字段，并给予相应人员所需的权限.
此外，该解决方案还讨论了只为应该始终能够编辑项目(管理员)的用户设置更高的权限，这是一种解决方案，但是在这种情况下您通常没有想要的粒度.

The solution you quote from the other task is simply setting 2 for SPList.WriteSecurity which 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.

这篇关于覆盖SPList.WriteSecurity行为?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！