Permissions on newly created discussion thread

Sep 18, 2014 at 10:26 PM
On SP 2013, I'm using the following code to create a new discussion thread:
$().SPServices({
      operation: "UpdateListItems",
      async: false,
      batchCmd: "New",
      listName: "Document Reviews",
      valuepairs: [["ContentType", "Discussion"],
                        ["Title", newDiscussionTitle],
                       ["Body", "Post comments as replies to this thread after reviewing document. <a href=\"" + newDocURL + "\">Link</a>"],
                        ["BaseName", baseName]],
      completefunc: function(xData, Status) {
            xData_save = xData;
            Status_save = Status;
      }
});
The new thread seems to be created just fine, but when someone else tries to reply to it, they are getting the error message "Access denied. You do not have permission to perform this action or access this resource".

The permissions on the discussion board are the same as the site itself, that all users have contribute access, and checking the advanced settings, the option for Create and Edit access is "Create items and edit items that were created by the user". I believe this was the default setting, which would seem to make sense for a discussion board (you don't want person A to change or delete a posting by person B). And if a new thread is created just using the "new discussion" option, then subsequent replies can be created without error.

So I assume that some way that I'm calling the web service with the code above is missing something which is required when adding to a discussion list, but I really have no idea what that might be.

Any thoughts are appreciated. Thanks in advance.
Sep 18, 2014 at 11:40 PM
If you create the item using the sharepoint list (no SPServices) - does it work?

I do know that discussion list are actually folders with items. But I never really tried to crate an item on them.



--
Paul T.

-- Sent from Mobile

Sep 19, 2014 at 12:24 PM
Yes, as far as I can tell, when you create a new discussion using the native SharePoint option, then others can post replies with no error. A couple of other initial observations which I need to more fully confirm:
  • when users are getting the error, the problem goes away if I change the list setting "Create and Edit access: Specify which items users are allowed to create and edit" to the option "Create and edit all items", which I presume means anyone could edit or delete anyone else's discussion posting. That's obviously not ideal (which is probably why the default option for that is "Create items and edit items that were created by the user"). But if the user is trying to create their own posting, I'm not sure why this setting even seems to have an effect.
  • this is currently anecdotal evidence and I need to test it more carefully, but it seems that if I change the setting above to "Create and edit all items", post a reply to a thread created with my code, then set the setting back to the default, you can continue posting replies against that code-generated thread. Again, I need to confirm this.
I found this article which includes a code snippet for using SPServices to create a new discussion thread, though using a slightly different form (in the section "Create a Discussion in the Discussion List"). I tried this code against my list, but the result is the same (getting an access error when another user trys to post a reply). I thought the part about the FSObjType might be the key:

// Important: FSObjType = 1 means that this is a folder. If this isn't specified SharePoint sometimes create the wrong root level item.

But that didn't seem to make a different (same access error).
Sep 19, 2014 at 12:54 PM
Although in can't prove it, I do think the issue is the create bit having the FSObject. Discussion need to be created with the folder, because that is were the replies go into.
Strange that it continues to error even after you do that. Is the error happening even to those who have full control?

Ps. Thanks for that link. Nice reference.


--
Paul T.

-- Sent from Mobile

Sep 19, 2014 at 8:30 PM
Is the error happening even to those who have full control?
Yes, which is why I didn't notice it at first ... my own account is site collection admin for the site where I'm developing this solution and it was working for me, but then this problem came to light when I tried to have someone reply to one of my code-created threads and they were getting the access error.

Just as a sanity check, I also modified my original code to include a reference to FSObjType: ["FSObjType", 1],
$().SPServices({
      operation: "UpdateListItems",
      async: false,
      batchCmd: "New",
      listName: "Document Reviews",
      valuepairs: [["ContentType", "Discussion"],
            ["FSObjType", 1],
                        ["Title", newDiscussionTitle],
                       ["Body", "Post comments as replies to this thread after reviewing document. <a href=\"" + newDocURL + "\">Link</a>"],
                        ["BaseName", baseName]],
      completefunc: function(xData, Status) {
            xData_save = xData;
            Status_save = Status;
      }
});
Admittedly I'm pretty new to SharePoint development in general and SPServices in particular, so I wasn't sure whether including FSObjType in this form needed a numeric or a string; numeric as above didn't work (though the thread was still created) and I haven't had a chance to try it as a string (whether that makes any difference or not).

Can anyone point me to any documentation on the various parameters each SharePoint web service takes? I wouldn't have known about FSObjType if I had not come across that article, so I have no idea if any other parameters might be required (since I'm just shooting in the dark here).

Thanks!
Coordinator
Sep 21, 2014 at 10:05 PM
FSObjType will be 1 if a item is a folder. It's a weird way to indicate it, but that's the way it's been forever.

Everything that you pass into the SOAP Web Services (all the services SPServices supports) are passed as text; the transport format is XML, so it has to be text.

Discussions are folders and all of the Replies are items within that folder. As you and Paul have speculated, if the folder (Discussion) isn't created correctly, it may not be "healthy" for others to use.

M.
Sep 22, 2014 at 2:06 PM
Edited Sep 22, 2014 at 2:14 PM
Thanks for your response. I think the value for FSObjType is being passed correctly; using the debugger in IE, I captured the XML being sent to the server when UpdateListItems is invoked, and it seems OK (to a neophyte like me):
<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>
        <UpdateListItems xmlns='http://schemas.microsoft.com/sharepoint/soap/'>
            <listName>Test Discussion</listName>
            <updates>
                <Batch OnError='Continue'>
                    <Method ID='1' Cmd='New'>
                        <Field Name='ContentType'>Discussion</Field>
                        <Field Name='FSObjType'>1</Field>
                        <Field Name='Title'>Code method</Field>
                        <Field Name='Body'>Add feedback on this document as a reply to this thread.</Field>
                        <Field Name='BaseName'>Code method</Field>
                    </Method>
                </Batch>
            </updates>
        </UpdateListItems>
    </soap:Body>
</soap:Envelope>
So the '1' for FSObjType is being sent as appropriate XML (I think), and if it were not, I would have assumed it would have resulted in an error.

Is there another parameter which I'm not passing that is required so that the discussion folder is "healthy"? The example in John Liu's article I referenced above (and copied below) uses a different form, but doesn't seem to include any other critical parameters (and I've included BaseName in mine for usability, though removing it doesn't fix the access issue).
$().SPServices({ 
  operation: "UpdateListItems", 
  batchCmd: "New", 
  listName: "Team Discussion", 
  updates: "<Batch OnError='Continue' >" + 
       "<Method ID='1' Cmd='New'>" + 
        "<Field Name='ContentType'>Discussion</Field>" + 
       "<Field Name='FSObjType'>1</Field>" +   // Important: FSObjType = 1 means that this is a folder.  If this isn't specified SharePoint sometimes create the wrong root level item. 
        "<Field Name='Title'>" + escapeColumnValue(title) + "</Field>" + 
        "<Field Name='Body'>" + escapeColumnValue(body) + "</Field>" + 
       "</Method>" + 
      "</Batch>" 
}); 
For now, I've retreated to configuring the advanced settings on the discussion board so that the "Create and Edit access" option is set to "Create and edit all items" (rather than the default choice of "Create items and edit items that were created by the user"). This seems to "fix" the issue but I can't help but see it as a kludge which might come back to haunt me (as I haven't yet determined what the real difference is in these options). But I would prefer to stick with the default setting (I presume Microsoft has a valid reason for which it) than using a wrong security setting just to get around a coding quirk. :-\
Oct 8, 2014 at 9:44 PM
You know... Some of our users are seeing same issue, but we using the out-of-the-box Discussion Board list. And it happens sporadically. I don't ever run into these issues as I have full control of the Farm and Site Collection. Switching the default "Create items and edit items that were created by the user" to "Create and edit all items" and from seems to fix it usually though.

Still looking for a real fix.
Nov 27, 2014 at 5:34 PM
Shawn,
Did you ever find a solution to this? Is it still happening for you?