With the new 2013 workflows there are a few scenarios that can cause issues which may not be obvious to those coming from 2010. One such scenario is configuring list items to have Create and Edit access set to Create items and edit items that were created by the user and have a user who did not create the item initiate a 2013 workflow. By default, this will result in the workflow failing due to unauthorised access exceptions.
Lets walk through the scenario in more detail.
Start with creating a new custom list and then in SharePoint Designer, publish a simple List workflow to it.
As you can see, a very simple workflow 🙂
Configure the list to allow users to only edit items that they created.
SharePoint Short #9
When using SharePoint Designer, especially in a development environment where content and assemblies can frequently change, SPD can start to behave erratically, sometimes loading content that has been removed from the web site, or using an older version of an assembly. This is due to how SPD caches content, which thankfully, is easy enough to clear.
First, close SPD and then remove all files from the following folder:
%APPDATA%\Microsoft\Web Server Extensions\Cache
This contains things like page caches.
Then, do the same for this folder:
This contains cached items such as assemblies used and lots of other xml configuration files.
Restart SPD and all should be good in the world 🙂
Using SharePoint Designer, users can update WebPart properties directly via the code pane. Now, if this is a requirement for you, you’ll notice that when editing a custom version three WebPart (System.Web.UI.WebControls.WebParts.WebPart) that the properties are displayed as attributes of the WebPart element:
<webpart:test_webpart runat="server" CustomProperty="custom value"></webpart:test_webpart>
I’ve trimmed the above to make it more readable, the real element would be far longer and all on one line.
To make it easier for users to update properties via SPD and to move the properties to their own child elements, one option available is to make a few changes to your WebPart.
- Change the WebPart to inherit from the version 2 class – Microsoft.SharePoint.WebPartPages.WebPart
- Add the SupportsAttributeMarkup(false) attribute to the WebPart class
- For the property you want displayed as a child element, ensure the property attribute used for storage is WebPartStorage(Storage.Shared) and not Personalizable(PersonalizationScope.Shared). The storage type used is not important.
Note: A sample project containing a simple designer workflow and the code described in this post is available for download here.
Workflows created in SharePoint Designer are good when you want to be able to deploy workflows to your customers and give them the power to add and customise the actions and logic contained within.
You can save the workflow to the Site Assets as a template from Designer and then either import it into your Visual Studio solution as a Reusable Workflow or SharePoint Solution Package. Importing a Reusable Workflow doesn’t give you a workflow that can be edited in Designer and although the Solution Package method gives you this, you need to create a separate feature with activation events to run custom code against the workflows, such as automatically associating the workflows with your lists.
Sometimes it’s good to be in full control of the installation process, if for example you want to log certain events. It’s also good to be able to understand what the generated Solution Package solution is actually doing.
The purpose of this post is to demonstrate how to deploy one or more SharePoint designer workflows, enable for web browser rendering and associate with a list all through custom code tied to the feature activated event of a web feature.