Tuesday, August 4, 2009

Sharepoint Designer - what did you do ? ACCESS DENIED !

Hey all,
A few weeks ago we created with the SPD ( Sharepoint Designer ) a workflow.
After deploying it in one of our Moss websites, we saw that every time when end users created a list - there was a problem to edit an item.

The weird thing was , that every attempt to edit an item, even with the system account or with our strong privileges users, we got an access denied page.

After doing some research, we narrowed down the issue to occur only in a certain version of Moss. Googling for a while led me to the February hotfix rollup kb961756 & kb961755 - that solve this issue.
But what can I do regarding the lists that already "damaged" ? I got to this code snippet that was published by Microsoft support -







 
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Xml;

namespace CA_TestingHotfix
{
class Program
{
static void Main(string[] args)
{
FixField(args);
}

static void FixField(string[] args)
{
string RenderXMLPattenAttribute = "RenderXMLUsingPattern";

//Console.WriteLine("Please enter the URL of the site: (Press enter after typing):");
string weburl = args[0];

//Console.WriteLine("Please enter the Document Library Name: (Press enter after typing):");
string listName = args[1];
SPSite site = new SPSite(weburl);
SPWeb web = site.OpenWeb();
SPList list = web.Lists[listName];
SPField f = list.Fields.GetFieldByInternalName("PermMask");
string s = f.SchemaXml;
Console.WriteLine("schemaXml before: " + s);
XmlDocument xd = new XmlDocument();
xd.LoadXml(s);
XmlElement xe = xd.DocumentElement;
if (xe.Attributes[RenderXMLPattenAttribute] == null)
{
XmlAttribute attr = xd.CreateAttribute(RenderXMLPattenAttribute);
attr.Value = "TRUE";
xe.Attributes.Append(attr);
}
string strXml = xe.OuterXml;
Console.WriteLine("schemaXml after: " + strXml);
f.SchemaXml = strXml;
}

}
}



This console application just adds to your schema the attribute that is missing. We did some more research in order to understand what really happened. The thing is that somehow we made the list schema be unghosted on that Site Collection, which means that instead of taking the schema.xml for list from the WFE itself, it made a "new" copy of the schema.xml in the DB - literally a simple case of Unghosting.

We wanted to see if we can fix it without deploying SP2 or that hotfix, So in our virtual machine we decided to track that record down.

 

SELECT SiteId, Class,Scope,ContentTypeID,Version,NextChildByte,Definition, Size, ResourceDir,IsFromFeature
FROM ContentTypes
WHERE (ContentTypeId = XXXXXXXXXXXXXXXX)




To sum things up, You can deploy service pack 2 or just run the query above ( NOT SUPPORTED ), and in order to fix the lists that already affected, run the console application.

Hope it helps.

No comments:

Post a Comment