[Microsoft.SharePoint.SPSecurity]::RunWithElevatedPrivileges(
{
$site = get-spsite "http://localhost/nonfarmadminsitecollection"
}
)
$elevatedSite = new-object Microsoft.SharePoint.SPSite([Guid]$site.ID,$site.SystemAccount.UserToken)
535f4b3f-f88e-4866-a826-6c17bc283b2d|2|5.0
The issue occurs on a publishing site that has a contenttype containing a Publishing Hyperlink (SPFieldLink).
Inserting a link with the Link Tools Tab of the ribbon works fine, but removing the link after it has been set does not.
Found a post on Stackoverflow that describes the issue in detail:
For quick reproduction: (steps and testing by M. Siepel)
- Create a Publishing Portal site
- Create a column of type Publishing Hyperlink
- Add the column to de Welcome Page contenttype
- Navigate to the Press Releases page
- View information -> Edit
- Add a link to the newly created column and save the page
- Open it again, remove the link (the link is visually removed, it even says: Click here to add a new Hyperlink)
- Save the page again
- Now open the page again.
- In our situation, the message 'Click here...' is gone, and if you view the source our original link is still there, but there is no text inside it.
I did some testing on it and these are the results:
- It occurs on dev and prod server with a custom solution installed
- It occurs on a server with no custom solution installed (clean install)
- It also occurs on the 'Adventure Works' site (both on a clean install and on a server with custom solution)
- It occurs both when creating a sitecolumn of type Publishing Hyperlink through API and UI
- When viewed with firebug the 'deleted' link is still in the href property, but the text property is empty
- Tested on IE/FF
- When viewing with Sharepoint Manager 2010, the link is still in de DB (with no text property as stated above)
- It happens on Dutch and English sites.
A little more time on the Bing machine resulted in finding a post from M Siepel on the Microsoft forums:
http://social.msdn.microsoft.com/Forums/en-AU/sharepoint2010general/thread/8ce468ec-096b-4ad2-a1e9-0bfb93cecf95
Basicly it states that the bug can be reproduced consistently and it has been reported to the product team. Lets hope this will be fixed in the next CU.
Someone already created a powershell fix, but that is not really end-user friendly. I will update this post
Param([string]$site0=http://mysharepoint,
[string]$list0="My List",
[string]$itemKey0="Item Key",
[string]$linkUrl0=http://newlink,
[string]$desc0="New description",
[string]$toolTip0="New Tooltip")
$site = Get-SPSite($site0)
$rootWeb = $site.rootWeb
$lists = $rootWeb.Lists
$list = $lists[$list0]
$items = $list.Items
$listItem = $items | Where-Object {$_.Name -eq $itemKey0}
$linkUrl = $listItem["Link Url"]
$linkUrl.NavigateUrl = $linkUrl0
$linkUrl.Description = $desc0
$linkUrl.ToolTip = $toolTip0
# this is the trick - set the object back to listItem
$listItem["Link Url"] = $linkUrl
$listItem.Update()
cdfa2c88-c814-4f4d-a9ed-11dc36634130|0|.0
About a week ago Microsoft published the XML Schema Definition (XSD) files for the Microsoft Visio 2010 XML Drawing (.vdx) format. This schema is also known as DatadiagramML.
This should make it alot easier to use the visio file to generate code based in the visio file.
The DatadiagramML Schema for Visio 2010 consists of three .XSD files:
- visio.xsd is the core schema used by Visio 2003 and later
- visio12.xsd is the set of extensions used by Visio 2007 and later
- visio14.xsd is the set of extensions used by Visio 2010
More information about the schema is available in the Visio 2010 XML Schema Reference on MSDN.
9aedc9fb-fc67-468f-a6d7-5ce9a463eb13|0|.0

Today I had some issues with a Lookup Column in SP2010.
When using my Admin account I was able to edit an Item and select a value. When using my normal useraccount (with contribute rights on bot lookuplist an list) I wasn't able to select anything, and SP2010 showed an empty dropdown.
Looking at the column properties in SharePoint everything looked OK, but using SP Designer the properties where empty.
Figuring this just might be something other then a rights issue, I wrote a little PowerShell function to check the settings of my Column.
Function Check-LookupColumn($webURL, $listName, $columnName, $lookupListName)
{
$web = Get-SPWeb $webURL
$list = $web.Lists[$listName]
$column = $list.Fields[$columnName]
$lookupList = $web.Lists[$lookupListName]
write-host "lookupweb : " $column.LookupWebId.ToString()
write-host "should be equal to web : " $web.ID.ToString()
write-host "lookuplist : " $column.LookupList.ToString()
write-host "should be equal to list: " $lookupList.ID.ToString()
}
Turned out that during the migration from one environment to the other, the references of the lookup column had not been updated.
The Admin account had sufficient rights on both environments, so it worked for that account. my user account on the other hand was not available in the source environment, so no sigar.
After updating the column with the right GUID's everything works again.
Wish I had seen this before writing my onw script
, but the script to fix the lookup column can be found at: http://get-spscripts.com/2011/01/fixing-blank-lookup-columns-in.html
618aad08-2143-47af-9a7b-4cd59e406b0c|0|.0