The other day we received a complaint from a user, stating he cannot edit a specific list in the Datasheet view, although he had no such problem with other lists. Whenever he would have liked to edit a task list in SharePoint using the Datasheet view he was prompted for his credentials repeatedly, even though he had write permissions on the list and was able edit the same items using the standard web forms. The problem occurred not immediately when he switched to the Datasheet view, but only when he was to insert data copied from an Excel sheet or was to edit the data in the view otherwise. When he clicked Cancel in the authentication dialog, IE became unresponsive and must have been restarted. Other users had no such problem.
My first intention was that it may be caused by using wrong (e.g. 64-bit) version of Internet Explorer or some issue with the local Office installation. This theory was proved to be wrong after the issue was reproduced by the same user on a workstation where the other users were able to edit the list.
As a next try, I captured the network traffic by Fiddler for both the problematic user and for another user, who had no issue with the editing. Analyzing the results I found that in the background the Datasheet view calls the Webs and Lists SharePoint web services. The only difference I found between the traces was that in the case of the problematic user there was two 401 – Unauthorized HTTP response when calling the Lists WS. The first 401 response was simply to force authentication of the client application, and could be found in the normal case as well. The other request that resulted in the second 401 response contained the following body:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body> <GetListItems xmlns="http://schemas.microsoft.com/sharepoint/soap/"> <listName>UserInfo</listName><query><Query><Where><Membership Type="SPGroup" ID="3"><FieldRef Name="ID" /></Membership></Where><OrderBy><FieldRef Name="Department"/></OrderBy></Query></query><viewFields><ViewFields><FieldRef Name="ID"/><FieldRef Name="Department"/></ViewFields></viewFields><rowLimit>10000</rowLimit><queryOptions><QueryOptions><ViewAttributes Scope="RecursiveAll"/></QueryOptions></queryOptions></GetListItems> </soap:Body></soap:Envelope>
From this request it is obvious that a list called UserInfo is queried, however there was no list with that name on the site. One might think that it is about the hidden user information list of SharePoint, but it is not the case. In fact it is a virtual list that refers to the members of a group in the case of a Person or Group field. At that point it was already obvious, that the Assigned To field of the task list was configured to enable selection of users from a specific group (in this case group with ID = 3), and the problematic user was neither member of the group nor a site collection administrator, so he had no permission to query the membership of the group.
The solution for the problem was to enable non-group members to see the members of the group as displayed below:
