Just recently I ran across a test case I was testing on a web part in SharePoint. I was opening the page with a user that had read only access to the page and I was getting an "Access Denied" message. After several hours of hunting I discovered that it was related to calling SetPersonalizationDirty() for the current web part. Obviously a user with read only access shouldn't be allowed to update the web parts properties. So here's what I used to resolve the issue:
if(SPContext.Current.Web.DoesUserHavePermissions(SPBasePermissions.UpdatePersonalWebParts))
{
this.SetPersonalizationDirty();
}
This blog shares some of the issues / experiences I have passed through related to development in SharePoint.
Monday, June 14, 2010
Tuesday, January 19, 2010
How to Resize a Fixed VHD
I just set up a bootable virtual machine in Windows 7 running Windows Server 2008 R2. I realized after creating the VM that I didn't need as much capacity as I allocated for the VHD file. After several hours of failed attempts I finally came up with a solution and wanted to share.
1) I first attached the VHD using Disk Management in Windows 7.
2) Using DiskPart I shrank the VHD volume down to a manageable size running the following commands. Note I had 100 GB of free space.
-diskpart
-select disk 1 (varies depending on the number assigned to the attached VHD)
-select volume 0 (also varies depending on the number assigned to the VHD volume in the disk)
-shrink ( If you would not like to shrink the volume to the absolute minimum capacity I would recommend using the [desired=] [minimum=] parameters. I repeated this command until I shrank the volume to the desired size. You can use detail disk command to check the actual amount of space needed for the disk).
3) After shrinking the VHD volume down you'll notice in Disk Management that there is a certain amount of unallocated space in the VHD. To remove that unallocated space use VHDResizer to actually resize the VHD to the size of the volume you just shrank.
Thursday, November 5, 2009
SharePoint Designer and Workflows...beware
It seems that no matter how many times I'm disappointed using SharePoint Designer 2007 I still find myself using it. The ability to quickly browse content on my SharePoint site, copy content into my Visual Studio project and quickly create Workflows that are attached to lists...**halt**... That's what I thought about 2 weeks ago until it came time to migrate the site I was currently working to another web application. Little did I know that workflows, created in SharePoint Designer, are assigned to lists using the lists's GUID (which makes perfect sense).
Okay, enough of the background. If you're like me and you get into something where you end up getting stuck (classic tar-baby) you won't give up without a fight. Well, fight hard I did. It turns out that it IS possible to reattach the workflow to its list after exporting your SharePoint site to a new site collection...the answer in a nutshell... make a call to SharePoint's web part service (duh...obviously...not).
Here's what I did, in a nutshell.
1) Create a feature event receiver to attach the workflow to the new list.
2) Open the workflow configuration files (usually stored in the "Workflows" list in your site) and replace all the list GUIDs from the old site with the GUIDs from the new site.
3) Call the SharePoint web part service to reassociate the workflow with the list. Here is a code sample for this step.
WebPartPagesWebService service = new WebPartPagesWebService();
service.Url = String.Format("{0}/{1}", SPWeb.Url, "_vti_bin/webpartpages.asmx");
service.UseDefaultCredentials = true;
service.ValidateWorkflowMarkupAndCreateSupportObjects(, null, , "2");
service.AssociateWorkflowMarkup(cfgFile.Url, "V" + cfgFile.UIVersionLabel);
**Important thing to note is the service will not associate the workflow with the list unless the version number of the config. file is greater than what is there currently. In other words you need to make sure the version of the workflow configuration file increases before calling the service to associate the workflow with the list.
Okay, enough of the background. If you're like me and you get into something where you end up getting stuck (classic tar-baby) you won't give up without a fight. Well, fight hard I did. It turns out that it IS possible to reattach the workflow to its list after exporting your SharePoint site to a new site collection...the answer in a nutshell... make a call to SharePoint's web part service (duh...obviously...not).
Here's what I did, in a nutshell.
1) Create a feature event receiver to attach the workflow to the new list.
2) Open the workflow configuration files (usually stored in the "Workflows" list in your site) and replace all the list GUIDs from the old site with the GUIDs from the new site.
3) Call the SharePoint web part service to reassociate the workflow with the list. Here is a code sample for this step.
WebPartPagesWebService service = new WebPartPagesWebService();
service.Url = String.Format("{0}/{1}", SPWeb.Url, "_vti_bin/webpartpages.asmx");
service.UseDefaultCredentials = true;
service.ValidateWorkflowMarkupAndCreateSupportObjects(
service.AssociateWorkflowMarkup(cfgFile.Url, "V" + cfgFile.UIVersionLabel);
**Important thing to note is the service will not associate the workflow with the list unless the version number of the config. file is greater than what is there currently. In other words you need to make sure the version of the workflow configuration file increases before calling the service to associate the workflow with the list.
Subscribe to:
Posts
(
Atom
)