I have a list with two content-types. I only want the user to be able to edit or delete listitems created from only one of the content types in SharePoint 2013.
On a quick side note… Â Using unique permissions on each item can lead to problems with performance as each individual item has to have it’s ACL tested as opposed to permissions at a list level.
Keep this in mind… Â You need to have a strategy for handling archive on lists like this if you have any serious numbers of items. Â The numbers probably reached the problem stage with around 8,000 items in a list. Â This was a time tracking solution and the requirement was that regular users could not see each other’s time sheets.
Ah, that’s another way to do it that I hadn’t considered. I’m not a fan of item-level permissions, but sometimes it is the only way.
Paul,
Thanks for the feedback and suggested solution. Â Yor are right about permissions being associated with the items and not the content type. When I started looking at the problem, I thought there might be a way with content types to do this. However, the read-only in content types only applies to who can edit the content type. Â
We are avoiding Event Receivers in favor of something easier to install. The way that we handled this problem was to use a Nintex Workflow for that Content Type.Â
The workflow was written to handle a new item or an item modification.
Once the item is set to that content type, regular members can no longer edit the record.  Until I “anded” in the additional condition to allow owners Full Control, I found myself unable to change the permissions on the item.
Thanks for your help. It’s been an interesting project using content types for conversion and regular list processing.
?width=721?width=721
Marta,
Thanks but we’ve been trying to avoid feature recievers that have to be installed.Â
Permissions are on the items themselves, not the content type. However, Â you could fake it by making custom New and Edit forms for the read-only content types that either redirect to the Display form or simply render the same read-only controls as the Display form. This isn’t true security as the user, technically, still has write access to the list.
Marta’s suggestion about an event receiver is the truly secure option. You could also add some security-checking code in the code-behind for the custom forms I mentioned above. These options require custom development, and they may not be available for use on SharePoint Online.
Another option would be to use workflow in place of the New/Edit forms on that list. You would need to modify the content types’ schemas to disable New and Edit forms. You would also need to modify the UI to provide users a convenient way to start the workflow. Workflow doesn’t happen as immediately as the New/Edit forms, so you would need to either provide additional UI/code to make that flow properly or train users on it. This is certainly a complex undertaking, but it can be done with some PowerShell and SPD.
