I have created a shared list where members can add new items and edit their own items. These members only have the ability to contribute, and not the ability to manage lists. In the list's advanced settings, under "Item-level Permissions", I have set the "Create and Edit access" to "Create items and edit items that were created by the user". However, I tested this under such a member's session, and I was able to open someone else's item and make changes.

Why is this happening and how do I restrict it properly?

  • 1
    I have seen this in the past where the item level security is enabled after the fact and doesn't apply to previously created items only items created after the configuration change. Commented Oct 15, 2013 at 20:58

3 Answers 3


First, make sure that you aren't testing that with a user that has higher permissions. Since you are posting a question here I'd wager that you are either a sysadmin or a developer, so unless you say otherwise I'll also bet that your account is something between a Site Owner and a Global Admin. So see if your higher permissions are not overriding that. Test with regular members accounts, make sure they don't belong to any groups with extra permissions.

If even with regular accounts that does happen, then we can think of a bug, since the configuration does not behave as per its own description. If you are hosting in Azure/Office 365, I'd open a support ticket with Microsoft.

Otherwise, if you are willing to have a workaround there, you can use an event receiver to cancel the edition in case the current user is not the author of the item being changed.

  • "However, I tested this under such a member's session" - I mean, I did test this under a member who doesn't have this privilege (Contribute only, no admin or designing roles). I also do not use Azure/Office 365. Commented Oct 15, 2013 at 19:44

There is actually no issue here. When a "Contributor" user opens up someone else's item, they are able to press the "Edit" button, and it allows them to edit. But, when they press the "Save" button, it then denies access. I hadn't tested the actual saving of such an item edit. I however would have expected that these users shouldn't even be able to press the "Edit" or "Delete" button in the first place.

A fine example of why you shouldn't jump to conclusions :-)

  • Ah good spot - when I have used it in the past I have also selected that they can only see their own items. Commented Oct 16, 2013 at 8:59

I have used this approach a number of times in 2010 with no problems.

Use check permissions to confirm the permissions of the other user.

How did you log in as the other user? If using sign in as other user this does not always work correctly.

  • I physically went to the computer of that other user. I also did check permissions of that user, and they only have the "contributor" role. Commented Oct 15, 2013 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.