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

This is a hair pulling defect that I cant figure out.

Out intranet has an extended content query web part that is widely used. After our last deployment site owners were unable to modify these web parts. Only site collection owners/authors are allowed to. The code did not change between the last deploy and this one. So this more than likely relates to permissions.

There were issues with users being deleted from groups during the deployment and the administration team seems to have caught them. The user's permissions are still intact for the subsite but are unable to do anything.

I have debugged the solution that contains the web part and no exceptions are thrown either in SharePoint's code or my own and nothing appears in the logs. The only confirmation of an error is the Access Denied page when you try to edit the webpart.

What could be causing this issue? Im not really expecting a solution, but a good place to start looking would be awesome.

Update This isnt just the extended content query web part anymore. Its the base content query web part.

I decompiled the SharePoint dll's using Dot Net Reflector and have finally hit something.

I get an UnauthorizedAccessException in SPRequest.cs in the GetFileAndFolderProperties method.

Working with another developer, we believe it to be permissions around either the List Type or Content Type lists in the Query portion of the Tool Part.

Update SharePoint is trying to reference a language resource file which it doesnt have access to. After checking permissions for all the SharePoint service accounts I can rule that out as they all have at least read access to the en-US.resx files.

Still at a loss :/

Update

The problem has been isolated in the class ExtendedContentByQueryToolPart

Update

A potential fix is to delete the webapplication and recreate it. Trying this on my machine has resulted in my test farm being completely screwed unfortunately. Another possible solution is to upgrade to SP2010. It seems to get rid of it.

What a mess.

share|improve this question

3 Answers 3

I am not sure what the extended content query web part is doing behind the scene in your website, but I would advise to check the database rights for the users who received access denied error in your site.

share|improve this answer
    
The web parts were used prior to the last deployment and you can still view the content. Its only when you click the "modify shared web part" option. Would that still be database rights? –  John S Dec 5 '11 at 18:03
    
Just a place to start with. I thought of the database rights since, that could be a possible difference with the site coll admin and other users. Is this happening when the web part is edited or when the page is in edit mode? Did you check whether it is a page layout issue? –  Deepu Nair Dec 5 '11 at 18:18
    
I just updated the question with some recent details. Its not just the extended content query web part, its the base version. –  John S Dec 5 '11 at 18:58

Was the OOTB itemstyle.xsl, header.xsl, or ContentQueryMain.xsl files modified at all? It's not good practice to modify these core files but I've seen where someone has unintentionally modified one of these and the CQWP broke.

share|improve this answer
    
Unfortunately no. As far as I and another developer can tell it has to do with SharePoint trying to get to a file that it doesnt have rights to. Trying to find that file specifically is turning out to be a pain as its url is "_fields\resources_fields.en-US.resx". After checking permissions on all the files postfixed with en-US.resx we ruled that out. –  John S Dec 6 '11 at 21:57
up vote 1 down vote accepted

After at least a month of hair pulling frustration I have a fix that does not involve giving users site collection owner rights.

I created a new permission level that was a copy of "Limited Access" for the top level site. I gave it, on top of li's permissions, the ability to Browse Directories and thats it.

I then gave the site owner's group those permissions on the root site and they are now able to edit the webpart. While not a solution, it definitely a better fix than what I had.

I will leave this question in case anyone else has or had this problem.

share|improve this answer

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.