List permission for user to add attachments

%3CLINGO-SUB%20id%3D%22lingo-sub-64753%22%20slang%3D%22en-US%22%3EList%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-64753%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20created%20a%20custom%20permission%20level%20by%20making%20a%20copy%20of%20the%20%22Contribute%22.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20left%20everything%20as%20is%20except%20for%20unchecking%20the%20%22delete%20items%22%20and%20%22edit%20items%22%20on%20the%20list%20permissions.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20idea%20would%20be%20that%20a%20user%20can%20add%20and%20item%20to%20a%20list%20but%20not%20edit%20or%20delete.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EEverything%20works%20as%20expected%20except%20that%20when%20the%20user%20tried%20to%20add%20an%20item%20with%20attachments%20they%20get%20an%20%22access%20denied%22.%20If%20I%20go%20back%20in%20the%20permission%20level%20and%20check%20%22Edit%20Items%22%20they%20can%20add%20attachement%20to%20the%20item.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EJust%20wondering%20is%20there%20anyway%20around%20this%20to%20allow%20the%20user%20to%20add%20(%20with%20attachments)%20but%20not%20edit%20or%20delete.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECheers%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-64753%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3ELists%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EPermissions%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-179703%22%20slang%3D%22en-US%22%3ERe%3A%20List%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-179703%22%20slang%3D%22en-US%22%3E%3CP%3EIs%20there%20any%20solution%20for%20this%20yet%20%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-65006%22%20slang%3D%22en-US%22%3ERe%3A%20List%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-65006%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20to%20all%20for%20the%20suggestions.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20will%20give%20me%20something%20to%20move%20forward%20with.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECheers%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-64829%22%20slang%3D%22en-US%22%3ERe%3A%20List%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-64829%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20only%20way%20I've%20seen%20this%20accomplished%20is%20through%20workflow.%20%26nbsp%3BUsers%20either%20add%20an%20item%20to%20one%20list%20where%20they%20have%20RW%20access%20and%20then%20a%20workflow%20copies%20it%20to%20another%20list%20where%20they%20have%20RO%20access.%20Or%20users%20add%20an%20item%20to%20the%20list%20and%20then%20have%20a%20workflow%20change%20the%20item%20permissions%20to%20RO.%20%26nbsp%3BBut%20there%20is%20no%20way%20to%20do%20this%20using%20permissions%20alone.%3C%2FP%3E%3CBLOCKQUOTE%3E%3CHR%20%2F%3E%3C%2FBLOCKQUOTE%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-64803%22%20slang%3D%22en-US%22%3ERe%3A%20List%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-64803%22%20slang%3D%22en-US%22%3Eobfuscation%20is%20not%20...%3CBR%20%2F%3E%3CBR%20%2F%3E%3A)%3C%2Fimg%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-64787%22%20slang%3D%22en-US%22%3ERe%3A%20List%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-64787%22%20slang%3D%22en-US%22%3EMaybe%20consider%20this%20(hacking%20together%20a%20solution)%3CBR%20%2F%3E%3CBR%20%2F%3EGive%20the%20user%20edit%20rights%2C%20when%20a%20new%20item%20is%20created%2C%20run%20a%20workflow%20to%20change%20the%20content%20type.%20Have%20one%20content%20type%20show%20the%20fields%20the%20user%20can%20enter%2C%20have%20the%20second%20content%20type%20show%20only%20calculated%20fields%20displaying%20the%20values%20selected%20by%20the%20user%2C%20or%20maybe%20just%20merge%20the%20fields%20into%20a%20%22multiple%20lines%20of%20text%20field%22%20that%20gets%20regenerated%20every%20time%20the%20item%20is%20edited.%20In%20the%20second%20content%20type%2C%20set%20all%20the%20fields%20to%20%22hidden%22.%20And%20turn%20off%20%22quick%20edit%22%20on%20the%20list.%3CBR%20%2F%3E%3CBR%20%2F%3EThis%20would%20prevent%20them%20from%20changing%20what%20they%20initially%20entered%20on%20the%20new%20form%2C%20but%20still%20having%20the%20ability%20to%20add%20attachments%20and%20not%20delete.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-64786%22%20slang%3D%22en-US%22%3ERe%3A%20List%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-64786%22%20slang%3D%22en-US%22%3EGonna%20have%20a%20tough%20time%20splitting%20that%20%5Bpermissions%5D%20hair%20based%20on%20the%20way%20SP%20manages%20attachments%3A%20they%20are%20added%20as%20uploads%20to%20a%20folder%20related%20to%20the%20parent%20item.%20Believe%20a%20reference%20to%20the%20attachment%20folder%20is%20made%20in%20a%20column%2Fcell%2Fvalue%20on%20the%20parent%20item%20row%20in%20the%20process%2C%20hence%20why%20they%20still%20need%20to%20edit.%3CBR%20%2F%3E%3CBR%20%2F%3EI%20would%20look%20toward%20creating%20a%20related%20library%20for%20the%20item%20rather%20than%20using%20attachments%20for%20this%20use%20case.%20Modifying%20the%20parent%20item%20form%20with%20a%20view%20of%20the%20related%20child%20items%20and%20adding%20some%20JS%20to%20assist%20in%20the%20child%20item%20linkage.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-64783%22%20slang%3D%22en-US%22%3ERe%3A%20List%20permission%20for%20user%20to%20add%20attachments%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-64783%22%20slang%3D%22en-US%22%3EI'm%20afraid%20there%20is%20not%20workaround%20here...if%20that's%20the%20combination%20of%20individual%20permissions%20that%20works%20for%20you%2C%20then%20you%20are%20done%3C%2FLINGO-BODY%3E
Highlighted
Frequent Contributor

Hi,

 

I created a custom permission level by making a copy of the "Contribute".

 

I left everything as is except for unchecking the "delete items" and "edit items" on the list permissions.

 

The idea would be that a user can add and item to a list but not edit or delete.

 

Everything works as expected except that when the user tried to add an item with attachments they get an "access denied". If I go back in the permission level and check "Edit Items" they can add attachement to the item.

 

Just wondering is there anyway around this to allow the user to add ( with attachments) but not edit or delete.

 

Cheers

7 Replies
Highlighted
I'm afraid there is not workaround here...if that's the combination of individual permissions that works for you, then you are done
Highlighted
Gonna have a tough time splitting that [permissions] hair based on the way SP manages attachments: they are added as uploads to a folder related to the parent item. Believe a reference to the attachment folder is made in a column/cell/value on the parent item row in the process, hence why they still need to edit.

I would look toward creating a related library for the item rather than using attachments for this use case. Modifying the parent item form with a view of the related child items and adding some JS to assist in the child item linkage.
Highlighted
Maybe consider this (hacking together a solution)

Give the user edit rights, when a new item is created, run a workflow to change the content type. Have one content type show the fields the user can enter, have the second content type show only calculated fields displaying the values selected by the user, or maybe just merge the fields into a "multiple lines of text field" that gets regenerated every time the item is edited. In the second content type, set all the fields to "hidden". And turn off "quick edit" on the list.

This would prevent them from changing what they initially entered on the new form, but still having the ability to add attachments and not delete.
Highlighted
obfuscation is not ...

:)
Highlighted

The only way I've seen this accomplished is through workflow.  Users either add an item to one list where they have RW access and then a workflow copies it to another list where they have RO access. Or users add an item to the list and then have a workflow change the item permissions to RO.  But there is no way to do this using permissions alone.


Highlighted

Thanks to all for the suggestions.

 

It will give me something to move forward with.

 

Cheers

Highlighted

Is there any solution for this yet ?