development

So I like many have a workflow that takes requests for Sites with a bunch of details for costing etc.  Then when approved those Sites are created and permissions allocated.

What we did not have was a record of who actually approved the sites.  Whilst this info is in the workflow history after a while that information gets purged, leaving us with Sites that were approved but by whom we know not.

So this is a simple case of changing the workflow and recording all of the approvers in the SPWeb properties, except that the approvers as we can tell happen to be Sharepoint Groups or AD groups, neither of which contain a history of membership, if AD does none I know how to access and certainly not easy for the customer and in a large membership we still would not know who actually did the deed.

I dug and dug for this and eventually found the User Login that actually did the change and here is how.

In your workflow you need a “Workflow Action” of EventName “OnTaskChanged”, this object in the code behind, when Invoked contains AfterProperties,

string user = OnApprovalTaskChanged.AfterProperties.ExtendedProperties[new Guid("d31655d1-1d5b-4511-95a1-7a09e9b75bf2")].ToString();

The above statement gets the User Login frmo the ExtendedProperties Collection.  It More >

If you were one of the two people who read my last post on WSS and PowerShell I updated it a bit and it’s worth checking out the changes.

I thought this time I would just point out some of the very simple statements in PowerShell that differ from your usual C# so that you can quickly make a transition from one to another.

One of the first things any programmer might need to do in a script is conditions so here is a PowerShell condition and how it differs to c#

if ($i -eq 10)
{
    write "It's ten you know"
}

The comparison operator for equals is not "=" or "==" but a scripting style operator of -eq. So this is the first thing you’re going to have to remember.  Other operators are

-gt greater than,  -lt less than,  -ge greater than or equal to,  -ne not equal

There are more I found a simple table of them here.

When dealing with boolean responses its important to know that they are represented by $true and $false so a condition to test this would look like

if ($kidding -eq $false) {

    write "How strange" }

Now being good little programmers you’re bound to want to structure your More >

The more I do with SharePoint the more and more I an finding a use for PowerShell. I am using WSS as an application platform and using lists etc as a datasource.  Providing what you want is not huge amounts of referential integrity and transactional control etc it works pretty well.

But when things go wrong, often the only way to quickly get in a fix something in a structured, repeatable and documented manner is PowerShell.  Hell and its fun too.

So as a Sharepointy person what do you need to learn to get you quickly started.

First go and install PowerShell, this is version 1 which is what I am using, version 2 will be great but is not in production yet, so try getting that on your live servers, if they let you, sack them – pre-release code on production servers pah!.

Next go and download Quest’s PowerGUI.  This comes with the fantastic script editor, that allows stepping through code and debugging, i tend to use this for all my PowerShell development, I’m used to Visual Studio so being confronted with a command shell environment can be a little daunting.

Now if you go looking on the web at powershell there are More >

I’ve had a right game with this Sharepoint Versioning problem.

Now those of you used to writing .NET but maybe not SharePoint will be used to having AssemblyVersion attributes set in the AssemblyInfo.cs files.

This is something I took into my last SharePoint application for wss3.  Now in SharePoint 2003 I got used to not setting the version number but it slipped my mind for WSS 3.0.

My particular problem was I had some ItemAdding/Updating List events.  These were configured to fire in one of my Assemblies. My build server would automatically increment version numbers in AssemblyInfo.cs and in all associated .xml files in the features, very clever I thought at the time.  Now I needed to update this assembly and modify some code in these events.

I made those changes and installed it and all of a sudden none of the events were firing at all.

This is because when a list is created the EventReceiver details of the feature are not read from the XML file but are stored against the List in the content database.  This makes some sense as if you update the list template then you can update the EventReceivers as well and have different versions of a list definition More >

When exploring workflow you might want to create a bit of code and have it execute and fire of the debugger to investigate all the properties your expecting are there.

Hint.  In your Execute Code block where you write the code to check stuff out, its worthwhile placing this BEFORE any timeout events you have in your workflow, here I am sitting waiting for the next 60 minutes before my event fires.

In fact I’m finding that a call to Debugger.Break()  doesn’t start the debugger after a timer has started, how queer normally this works on everything.

Needless to say I’m making a quick change to my workflow order for now.