2

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.

Improve this question

3 Answers 3

Reset to default
1

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.

Improve this answer
0

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.

Improve this answer
3
  • 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?
    – user5907
    Commented Dec 5, 2011 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
    Commented Dec 5, 2011 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.
    – user5907
    Commented Dec 5, 2011 at 18:58
0

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.

Improve this answer
1
  • 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.
    – user5907
    Commented Dec 6, 2011 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.