Archive

Archive for September, 2014

Adding the org chart back into a SharePoint 2013 My Site

One thing everyone loved about the SharePoint 2010 my sites was the Silverlight Organisation chart.

It seems to have been dropped from SharePoint 2013, my guess as Silverlight is no longer flavour of the month.

However its still there on the \organizationview.aspx page in the My Site Host Collection Site.

All we need to do to bring it back is modify the quick navigation and add a link to it and hey presto!

We can do this via the GUI or we can use PowerShell to do this.

Using the GUI

Log onto the my site root site as a site collection administrator.

Select the ‘Gear Wheel’

Select ‘Site Settings’.

Under ‘Look and Feel’ select ‘Quick Launch’.

Select ‘New Heading’.

New Heading

Set the web address to http://<my site host collection root site URL>/organizationview.aspx’.

Set the description to ‘Organisation Chart’.

Select ‘OK‘.

Using PowerShell

$Web = Get-SPWeb -Identity:http://<my site host collection root site URL>/”

$Navigation = $Web.Navigation.QuickLaunch

$Node = New-Object `

-TypeName:“Microsoft.SharePoint.Navigation.SPNavigationNode” `

-ArgumentList:“Organisation Chart”, http://<my site host collection root site URL>/OrganisationView.aspx”, $true

$Web.Navigation.QuickLaunch.AddAsLast($Node)

Organisation Chart Link

Enjoy

Sebastian

Too many numbers

For a long time now I’ve been telling people that there are only three numbers in computing:

  • None
  • One
  • Many (and for our purposes Many will actually be Two)

Thus when testing if we cover these bases then that should be enough.  For example if testing that modifying properties on a record I might have a set of unit tests as follows:

  • AddsNoProperties
  • AddsOneProperty
  • AddsTwoProperties

However even though records are by definition immutable in practice records managers sometimes have to amend them so we also need to test.

  • UpdatesNoProperties
  • UpdatesOneProperty
  • UpdatesTwoProperties

Worse still they sometimes update records by removing information (typically due to a ‘misfile’) so we also need:

  • DeletesNoProperties
  • DeletesOneProperty
  • DeletesTwoProperties

That’s nine tests not too bad.  Hold on what if in a single transaction we add some properties, update some properties and delete some properties?

  • AddsNoPropertiesUpdatesNoPropertiesDeletesNoProperties
  • AddsOnePropertyUpdatesNoPropertiesDeletesNoProperties
  • AddsTwoPropertiesUpdatesNoPropertiesDeletesNoProperties
  • AddsNoPropertiesUpdatesOnePropertyDeletesNoProperties
  • AddsOnePropertyUpdatesOnePropertyDeletesNoProperties
  • AddsTwoPropertiesUpdatesOnePropertyDeletesNoProperties
  • AddsNoPropertiesUpdatesTwoPropertiesDeletesNoProperties
  • AddsOnePropertyUpdatesTwoPropertiesDeletesNoProperties
  • AddsTwoPropertiesUpdatesTwoPropertiesDeletesNoProperties

If you work it out that’s 54 tests.  That’s too many.  We use xUnit so as well as Facts (xUnit tests) we have Theories (xUnit ‘data-driven’ tests) so maybe we really have one ‘theory’.

  • AddsSomePropertiesUpdatesSomePropertiesDeletesSomeProperties

It will have fifty four examples, so while its better its still long to run and set up.  It smells of hidden complexity.

Hold on do we really have three numbers?  I don’t think so in fact we may have only one number:

  • Some, and for our purposes this can be defined as any number greater than the minimum value and less than the maximum value.

In addition we probably have two edge cases:

  • Minimum value, which we can assume as zero.
  • Maximum value, which if we assume is two we can easily handle.

For this to be useful we need to be working with a collection of separate things, that is they must all be homogeneous and independent.  If they are not homogeneous then we need to treat each separately and if they have dependency on each other then which one we change becomes important.  However when using collections, e.g. lists, arrays, dictionaries, this is nearly always the case.

So this means I can now have a single test so long as I have enough things in my collection to allow for each action. I choose to split my actions and end up with three tests based on an object with two properties.

  • AddsSomeProperties, using one existing property and adding one new property.
  • UpdatesSomeProperties, using two properties and updating one and not the other.
  • DeletesSomeProperties, using two properties and deleting one and not the other.

This is quick and easy and covers all the bases, except for those pesky edge cases.  However if these are important, e.g. deleting all properties, then we can convert our facts into theories and test for them.

So in this case we don’t have three numbers, in this case we only have one number:

  • Some

Happy testing

Sebastian