Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am working on a system in SharePoint 2010 where we have many (>40) custom content types, all derived from Document Set. The system also has some strictly defined user roles, so we have set up our own custom permission level definitions. Now I'm seeing some strange behavior where for a few of the content types, I'm getting an "Access Denied" error at the point where the form is generated for entering the metadata for a new document set folder.

To try and make this more clear, here's the procedure: I log in with an account that has Add Items and Edit Items permissions (should be enough to create a new doc set). I follow the procedure of the system to create a new folder. This involves selecting the content type from a list box, and pressing a "Create Folder" button (we are not using the Ribbon). The "Create Folder" button basically opens the default NewDocSet.aspx page, passing the content type ID of the selected content type. For the vast majority of the content types, the correct new item form is generated, and I am able to enter information for the fields and press "OK" to create the document set. However, for a few of the content types, before the new item form is displayed, I get an "Access Denied" error.

This problem was occurring in a couple test environments. In one of them, I logged in using an account that has Site Admin privileges. I went through the procedure again, and all the forms generated correctly. Then I logged out and logged back in using the user account that was experiencing the problems. Then, when I went through the procedure again, the forms that were previously giving the error generated successfully. It's as though they needed to be generated once by someone with the correct privileges, and then they were available.

So my question is -- what's going on behind the scenes when a new item form is generated that requires special privileges (or at least, higher privileges than the account I was using, which should have enough privileges to create a new document set)? And more than that, why would I encounter this error for only a few of my content types, and not all of them?

Thanks,

  • Dylan
share|improve this question
add comment

2 Answers

I have experienced this as well, though in a different way than you describe.

The problem, like you describe does not occur when using a site admin account. But does occur with other lower priviledged accounts.

I have decompiled the DocumentSet dll, to find out where the error comes from. What I found, and what you have not been able to see, is that it actually stems from a Com Exception happening in the DocumentSet dll.

The error seems, from my thousands of tests, to be completely sporadic. In other words, it looks like a threading issue (ie. Race condition) where another thread will go and update the element you are working on.

The result you see as a normal user is "Access Denied". When the site is set to debug-mode, you will see "File has been modified .." as the actual exception.

The stacktrace will tell you what I have just described above - that the exception is generated in the DocumentSet .dll, and originates as a COM Exception.

My resolution

When creating the document set with

DocumentSet.Create(/* something here */)

I wrapped that in:

  var retry = true;
  do 
  {
    try
    {
      DocumentSet.Create(/* something here */);
      retry = false;
    }
    catch (Exception e)
    {
      //ACTION: delete the document set just created (because the document set will actually get created)
    }
  } while (retry); 

I know this is a dirty old hack, and not in any way best practice. I would love to know WHY the error occurs - and putting in another 20 hours, I probably could. But for now, I just wanted to put this out there, since it doesn't seem to be documented.

share|improve this answer
add comment

Thanks for the answer, CodeMonkey, and that is certainly interesting. However, I think my problem was something a little simpler -- what I believe it was (it's been a while, now, so I don't remember exactly what it was, just that it was something fairly simple) was that I used a single document library in which to create all the doc sets. However, I did not add all the 40+ content types to the library ahead of time. So if a user (with low privileges) tried to create a new doc set of a content type that had not been added to the library yet, SharePoint would try to add the ctype to the library, but the user would not have the correct privileges to do so. Then, after the ctype was successfully added to the library by an Admin user creating a doc set of that type, it was then available at the library/list level for users with lower privileges. I ended up deploying the library with all 40+ ctypes included in the list instance definition, so they would be available from the get-go.

share|improve this answer
    
This would make a better comment, CodeMonkey probably would never of seenm this reply –  Hugh Wood Nov 21 '12 at 11:53
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.