SP2013 Workflows and WSPublishState does not exist

Column 'WSPublishState' does not exist. It may have been deleted by another user.

This is a quick blog of something that troubled me for nearly an afternoon.

Scenario

  • SP2013 workflow
  • Packaged as Sandbox Solution with list definitions in Visual Studio

 

The errors happen during Feature activation.  Both from within Visual Studio's Deploy as well as via Site Settings - Activate Feature.  The feature activation fails because WSPublishState column doesn't exist.

 

Resolution

 

I fixed this by splitting the list definition and workflow definitions into different features.  This leads me to ponder if there is a conflict caused by the list, workflow and workflow association being created all within the same feature.

TypeScript presentation (take 2) at SPSMEL

 

Earlier today I delivered possibly my best TypeScript session ever at SharePoint Saturday Melbourne.  The attendees were great, and I feel like I cracked jokes all the way through!

The secret, and this I think many attendees may not have realized, is that I started almost 10 minutes early.  So they went through 70 minutes of solid TypeScript wonderland with me.  I hope that extra time was good.

As I have actually done the rounds with TypeScript for a whole year.  I think this might be a good time to sunset this particular topic. 

Download Links

 

 

The Future of TypeScript

 

TypeScript, now that it has reached version 1, will never disappear:

There are some really big projects within Microsoft that is using TypeScript.  There is no alternative for them to switch to.

  • Dart - is not focused on building JavaScript.  Dart believes that JavaScript is broken fundamentally, and the only way to fix it is to introduce a new Virtual Machine.  Dart compiles down to JavaScript is almost a side-effect for adoption.  If Flash and Silverlight are bad for the web, what do you think people's reaction would be to Dart VM?
  • Coffee Script is great, and solves a genuine problem with JavaScript - that the language is too loose, and gives you too many ways to hang yourself.  Coffee Script's syntax, being so close to Ruby, will ensure a smooth path for them to work on Ruby and Coffee Script. 
    In the same vain that I feel a Ruby Developer should never use TypeScript - they should use CoffeeScript; a C#/.NET/Java/C++/JS developer should never use Coffee Script - they should learn the TypeScript syntax that's closer to what they already know, plus TypeScript will greatly help them learn, understand and write better Javascript.
  • ECMA Script v6 - is really the holy grail that will fix a lot of the odd JavaScript syntax (along with "option strict").  But ES6 does not include Type information.  What that means is that even with the eventual convergence of the Evergreen Browsers to ES6, TypeScript will still have a place as a superset to ES6.  The Type information is important for the tools to correctly check your code for you during design and compile time.

TypeScript sits in its own place.  It tries to give you "invisible railings" for your JavaScript. 

With TypeScript, you start with JavaScript, and you work within self imposed railings (which magically disappear when it's compiled back in JavaScript) so you get the benefit of a strong typed language to help you write code, but none of the performance penalties.

TypeScript enables teams to work together.  For projects that have hundreds of thousands of lines of JavaScript - there is no way back.

Remember: As your JavaScript codebase grow, it will become unmanageable and you will have code rot.  TypeScript is a great way to help you avoid that gruesome spaghetti situation. 

jQuery Promise syntax to wrap SharePoint SP.SOD

 

jQuery has a special function $.Deferred - which lets you create an Deferred object to build Promise(s).

We use this to simplify everything we do in SharePoint and other JavaScript libraries.

 

Wrapping SP.ClientContext

function GetCurrentUserName() {

var deferred = $.Deferred();
var ctx = SP.ClientContext.get_current();
var web = ctx.get_web();
var currentUser = web.get_currentUser();
ctx.load(currentUser);
ctx.executeQueryAsync( function(sender, args) {
    deferred.resolve();
}, function() {
    deferred.fail();
});

var promise = deferred.promise();
promise.done( function() {
    var title = currentUser.get_title();
});

return promise;
}

Wrapping SP.SOD

function SPLoaded() {

var deferred = $.Deferred();
SP.SOD.executeOrDelayUntilScriptLoaded( function() { deferred.resolve(); }, "sp.js");

return deferred.promise();

}

Resolving multiple promises

var promise1 = ...
var promise2 = ...
var promise3 = ...

$.when(promise1, promise2, promise3).done(function(){

// do something

});

 

Concatenating Arrays of promises

 

var promises = [];
promises.push(promise1);
promises.push(promise2);
...

// use this syntax when you don't know how many promises are there - may be calling REST in a loop.

return $.when.apply($, promises);

 

Combining Array of Promises and SP.SOD

 

function Ready() {

var promises = [];

var deferred1 = $.Deferred();
SP.SOD.executeOrDelayUntilScriptLoaded(deferred1.resolve, "sp.js");
promises.push(deferred1.promise());

var deferred2 = $.Deferred();
SP.SOD.executeOrDelayUntilScriptLoaded(deferred2.resolve, "sp.core.js");
promises.push(deferred2.promise());

 

return $.when.apply($, promises);

}

 

Combining promises

 

$(document).ready(function(){

    var vm = new ViewModel();  // not included in above script
    var promise = vm.Ready();
    promise.done( function() {
        vm.GetCurrentUserName();

    });

});

 

(Updated) And the grand finale

 

function Ready() {

var promises = [];

// using the special javascript argument "arguments"

$.each(arguments, function(index, arg) {
    var deferred = $.Deferred();
    SP.SOD.executeOrDelayUntilScriptLoaded(deferred.resolve, arg);
    promises.push(deferred.promise());
});

return $.when.apply($, promises);

}

 

$(document).ready(function(){

    var vm = new ViewModel();  // not included in above script
    var promise = vm.Ready("sp.js", "sp.core.js");
    promise.done( function() {
        vm.GetCurrentUserName();

    });

});

Nintex Workflow Inline Function to check if SPFile is locked

 

IsDocumentWritable

 

Nintex Workflow has a fairly useful function "IsDocumentWritable" that checks if the current item that the workflow is running on is writable.

There is a small problem, it only checks if the file is Checked Out (SPFile.CheckedOutType) and not if the file was locked, say by a Desktop Client Application.

 

Add Nintex Workflow Inline Function

We can add a simple Nintex Workflow inline function to get the behaviour we wanted:

I followed Vadim's excellent blog entry: http://www.vadimtabakman.com/nintex-workflow-developing-a-custom-inline-function.aspx

 

/*
* & 'C:\Program Files\Nintex\Nintex Workflow 2010\NWAdmin.exe' -o AddInlineFunction -functionalias "fn-IsFileLocked" -assembly "MY_DLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f7c41d4a6ea1fb3" -namespace "MYNamespace" -typename "MYInlineFunctions" -method "IsFileLocked" -description "Checks if file is locked." -usage "fn-IsFileLocked(itemPath)"
*/

public static bool IsFileLocked(string itemPath)
{
    bool result = false;
    try
    {
        SPSecurity.RunWithElevatedPrivileges(() =>
        {

            using (SPSite site = new SPSite(itemPath))
            {
                using (SPWeb web = site.OpenWeb())
                {
                    SPFile file = web.GetFile(itemPath);
                    if (!file.Exists)
                    {
                        return;
                    }

                    // true if checked out

                    result = file.LockType != SPFile.SPLockType.None;
                    return;
                }
            }
        });
    }
    catch (Exception ex)
    {
    }
    return result;
}

 

You can call this method from within Nintex Workflow Designer.

image

Reading InfoPath template's default values in code

 

String xml = "";
FormTemplate template = this.Template;
using (Stream s = template.OpenFileFromPackage("template.xml"))
{
    XPathDocument reader = new XPathDocument(s);
    XPathNavigator nav = reader.CreateNavigator();
    XPathNavigator repeat = nav.SelectSingleNode("/my:myFields/my:Repeats/my:Repeat[1]", this.NamespaceManager);
    if (repeat == null)
    {
        return;
    }
    xml = tender.OuterXml;
}
if (!String.IsNullOrEmpty(xml))
{
    XPathNavigator destination = this.CreateNavigator().SelectSingleNode("/my:myFields/my:Repeats", this.NamespaceManager);
    destination.AppendChild(xml);
}

 

The top part of the code is particularly useful if you want to use the Default Values for repeating sections in InfoPath.  Your code will read the xml for the default values and insert them into the repeating section.  I've previously hardcoded these XML segments for insert, but that's extremely error prone when you inevitably update your XML template with new and more exciting child elements and attributes.