UpdateListItems required permissions to add items

May 10, 2013 at 4:26 PM
Edited May 10, 2013 at 4:27 PM
Hello, first thanks for creating this library, it's been a great experience so far and has made MOSS 2007 form customization much more intuitive.

My team's site setup is based on MOSS 2007 and has an Owners group with Full Control and a Members group with only list write capability, but no edit capability.

I recently implemented a custom, jQuery driven, form using the UpdateListItemstems to add information as a new item in a custom list ( Note: I'm using the valuepair notation approach similar to the last example on the API page https://spservices.codeplex.com/wikipage?title=UpdateListItems ). But in order for the information to populate the list, I have to grant the Members group the Managed List permission, along with their existing write permissions.

I don't want them to have this level of access and was wondering if there's a workaround or maybe some other parameter or setting I'm missing. The Owners group obviously has no issues adding new items, since they already have full control permissions. Your input is appreciated.
May 10, 2013 at 5:23 PM
Usually the Members group would have Contribute permissions, which would take care of it. The Web Services run under the credentials of the current user, so they can only do things that they can do through the UI.

May 10, 2013 at 6:22 PM
Edited May 10, 2013 at 6:23 PM
Thanks for the quick response sympmarc, going over it again I'm thinking the permission assignments for the Members group are the issue. I created the custom Fake permissions level for testing purposes, the additional permission levels were assigned by default when I first picked up this project. I'm guessing the Read and View Only permission-level assignments may be what are preventing Members from committing new form information to my custom list. I won't get a chance to test it until this afternoon, but I'll try removing those permission-level assignments and the Managed Lists setting in the Fake and see if that allows Members to update the list.

Member Group Permissions Assignments

Custom Fake Permission Settings


May 10, 2013 at 10:03 PM
Edited May 10, 2013 at 10:44 PM
Ok, I stripped out all permissions from the Members group except the Fake permission set I defined. I also removed the Manage Lists setting , so it seems like they should have basic Contribute permisssions at this point, please correct if I'm wrong. Afterword, I tried to enter an item through the form, but the information still fails to get submitted properly to the list. The debug output below shows the return result after it tries to commit, of course when I get redirected to the Calendar view I defined for the list, the item is not there.

All permissions removed except custom Fake permission set

Custom Fake Permission Set

Chrome Debugger output

Might not be obvious from the pic , the error reported in the return is 0x80070005
May 10, 2013 at 10:22 PM
Edited May 10, 2013 at 11:49 PM
Hi sympmarc, I'm a novice and must not have a good enough idea about how permissions work in MOSS 07. I checked the permissions for the Test user account I'm using, could Limited Access permissions be what's preventing the Test account from adding items to the list? From what I've read this permission level is automatically assigned when permissions are broken on a site.


At this point, I'm not sure what else it could be. I've now given formal contribute permissions to the Members group based on the Contribute column settings described in the MOSS documentation below, but I still must give Managed Lists to the group in order for members to to update the list.




May 11, 2013 at 1:29 AM
Edited May 11, 2013 at 2:17 AM
From what I've read, 0x80070005 is an access denied error. I'm still not exactly sure why this permission is required to update a list. I've gone through the list and group permission settings several times over, but nothing else stands out to me. The only other documented case I've seeing of this issue is from the following Stack Exchange discussion from 2011. Seems they were also having a similar permissions issue, but a resolution was never reached unfortunately. The user Adam B suggested enabling Use Remote Services, as you can see above, that's already added in my case, Contributors still must have Managed Lists enabled in order to update lists.


I read a couple of posts that suggest the Alternate Access Mapping Collection may contribute to this specific error and could be resolved as follows

Go into SharePoint Central Administration
Go to Operations
Under Global Configuration, select Alternate access mappings
Choose your Alternate Access Mapping Collection from the dropdown (e.g. SharePoint - 80)


I don't have access to our main MOSS server to test this out, unfortunately, so it's hard to say if this is related or not...
May 15, 2013 at 12:10 AM
Hi Marc, just an update, I was finally able get Members to inject data into my test list. I ended up creating a new list from scratch, I left the list settings at their default and only added the required columns and the SPServices-driven custom form. After some initial tests, I was able to update the list without requiring users to have Managed Lists permission level.

I'm not sure exactly what the root cause of the error was in the first test list I created, I had made modifications to the list settings throughout my testing of custom forms, so I'm guessing one or more of those settings may have messed up the permissions on that list. In any event, the issue appears to be resolved, thanks for the input and again thanks for providing this excellent library.
May 15, 2013 at 1:04 PM
Great! When you stray too far from the default permission roles (Full Control, Contribute, etc.) things can get a bit messy.

Glad you worked it out.