EPMSource

Over the past week or two, Microsoft have been quietly uploading all the sessions from the recent Project Conference held in Phoenix to the Project channel on Microsoft Showcase. This morning the Project team officially announced the availability, so I am pleased to announce that the video of Mark McDermott’s and my session is now available for your viewing pleasure. I encourage you to watch it and let me know if you have any questions.

Finally, the session deck, including notes is available for download at slideshare.net.

In the last post, we covered a few things you will need to know when hiding or disabling ribbon buttons in PWA. In this post we will look at how to actually hide the buttons.

Where to start?

Irrespective of whether you wish to hide or disable a button in the ribbon, you will need to follow the same basic process by building a solution in Visual Studio that will deploy your ribbon customisation.

To start, open up Visual Studio and choose to create an Empty SharePoint Project.

Enter a name and then click on OK. You will then see the SharePoint Customisation Wizard, enter the local site you wish to use for debugging and choose to ‘Deploy as a sandboxed solution’.

On clicking finish, Visual Studio will create a solution ready to be customised.

To start with we need to create a feature,  this is a logical container for our customisation and allows the user to turn on and off the customisation by activating and deactivating the feature. To do so, right click on Features in the solution explorer and choose Add Feature.

A feature will be created and Visual Studio will show a page where you can enter information about the feature such as the name, description and the scope. In this case we are going to choose Web (for an individual site) as we want this change to deploy only to the /PWA site and not all the children sites.

Next we want to add an element to the solution, this is where the real work is done and contains the XML that will be used to configure our ribbon.

To add an element, right click on the project name, choose Add, New Item

In the dialog that is displayed, scroll down and select Empty Element and give it a name.

Once you click add, the element will be created.

Now the empty element is created, all that is needed is to add the relevant XML to either disable or remove the button.

Disabling a button

For this example, we shall be disabling the EPT Change button from the Project Centre ribbon. To do so we need to know the ID of the item as defined in the ribbon so we can build up some XML that defines what we want to do to that item. To find the ID, we need to look through the PWARibbon.xml file, which can be a bit daunting, but after a while you will understand the structure and finding the Id’s will become simple.

SharePoint ribbon customisations use a defined XML schema which describes the structure and behaviour of the ribbon and the items that make it up. In order to disable the EPT Change button, we need to override the current structure and behaviour to change the configuration of what the button will do, in this case, pointing to a command that doesn’t exist.  In doing so, the ribbon will disable the button for us, giving us the desired effect.

To get the various attributes of the button, the PWARibbon.XML is your friend, containing all the configuration information you will need. In this case I have taken the configuration of the button and changed the command to point at a non existent command, which will cause the button to be disabled. This XML then needs to be put in the Element.xml file ready to be built, but more on that later.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
			Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
			Location="CommandUI.Ribbon"
			Title="Disables the EPT Change button in the Project Center Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change">
					<Button
						Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
						Command="ChangeReplacement"
						Sequence="10"
						Image16by16="/_layouts/$Resources:core,Language;/images/ps16x16.png"
						Image16by16Top="-112"
						Image16by16Left="-190"
						Image32by32="/_layouts/$Resources:core,Language;/images/ps32x32.png"
						Image32by32Top="-352"
						Image32by32Left="-96"
						LabelText="$Resources:pwafeatures,WEBPARTS_PROJECTCENTERPART_CM_CHANGE"
						TemplateAlias="o1"
						ToolTipTitle="$Resources:pwafeatures,PAGE_PDP_CM_CHANGE_WORKFLOW"
						ToolTipDescription="$Resources:pwafeatures,SUPER_TOOLTIP_CHANGE_PROJECT_TYPE"
						/>
				</CommandUIDefinition>
			</CommandUIDefinitions>
		</CommandUIExtension>
	</CustomAction>
</Elements>

Removing a button

The XML code required to remove a button is simpler. Instead of defining the XML for the whole button, all that is required is to redefine the CommandUIDefinition as per below.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
			Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
			Location="CommandUI.Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change" />
			</CommandUIDefinitions>
		</CommandUIExtension>
	</CustomAction>
</Elements>

When PWA parses the XML it uses this to remove the button as key items are not defined. Once again, all that is required to remove the button is to move this XML into the Elements.XML file and save ready for building.

In both cases, if you wish to hide or disable more than one button, you will need to duplicate the Custom Action mark up and change as necessary for each button.

How to Build

Finally once the configuration is completed, all that is required is to build and deploy the solution. To do so, right click on the project name and choose build, if everything is ok, you should see something similar to this in the build output:

If the build fails, then there may be a problem in your code. I have packaged the code up I used to build this post into a zip file which is available from my Skydrive account so you can compare or copy.

Once the build is successful you can deploy the solution by right clicking on the solution name and choosing deploy. VS 2010 will then deploy the solution to the site you entered for debugging and activate the solution in the site collection.

Once the solution has been activated, you should see the changes to the ribbon in Project Center.

As you can see from above, creating a custom feature to hide or disabling buttons in the ribbon is relatively simple once you have the basic structure in place. Hopefully this post has explained how to build these customisations for use in your next project or internal implementation.

It’s always puzzled me why Microsoft never did show the ID of a SharePoint based list entry in the edit or display form. What do I mean by that? Well, out of the box, when you create a list in SharePoint, each item has an ID associated. This ID is then used to identify the individual records in the list.  Once you have created an item in the list you can see the ID in the view

But not in the edit or display views of the list item.

Now this is not unique to Project Server 2010, nor SharePoint 2010 for that matter. The same behaviour can be seen in SharePoint 2007 as well. So why am I telling you all this, well today one of my clients requested that the risks and issues lists on their Project Server instance be modified to show the actual id of the item, making it easier for them to reference and relate to the information they were viewing.

Well, it turns out doing this is pretty easy. Basically all that is needed is to add a content editor web part to the the Display and Edit forms and add a small piece of JavaScript to render the relevant ID. A quick search on the web revealed this article from PathToSharePoint.com that provides the code as well as steps to insert the Content Editor web part on a WSS 3.0 / SharePoint 2007 installation.  So I am going to concentrate on what is required to do so for SharePoint 2010.

First navigate to the list you wish to make the change to,  in my case I am using an issues list. In the ribbon choose List and then click on ‘Form Web Parts’.

Click on the little down arrow and three options will be displayed.

We are interested in modifying the Default Display Form and Default Edit Form. There is no point in editing the Default New Form as the ID won’t be available yet to display.

Click on the Default Display Form, the screen will refresh to show the form in edit mode and display the web part zone.

Click on the ‘Add a Web Part’. The Web Part gallery will be displayed, select ‘Media and Content’ in the Categories and then the ‘Content Editor’. Click on Add to add it into the web part zone.

Click on the ‘Click here to add new content link’ inside the Content Editor Web Part.

Select the Edit HTML Source from the HTML menu.

In the dialog, paste in the code from the PathToSharePoint site into the HTML Source and click on OK.

Choose to Stop Editing the Page and then navigate back to an issue and choose to view it, causing the newly updated display form to be used.

You’ll notice a new item has appeared on the top line showing the Issue Id.  Now all that’s needed is to repeat the above for the Default Edit Form and your finished. Of course, this will only customise the list of the site you are in. If you want this to be carried through all of your sites, make sure you make the same changes to your Project template site.

When I was in the US last week, I commented that it would be great if SharePoint and Project Server made it easier to look up the relevant ULS log entries for a specific correlation id. Of course, the traditional way of viewing these is to navigate to the ULS log location within the farm and view the relevant log file, or to use the excellent ULS Viewer tool to interrogate the files. However, both of these options require the user to have physical access to the file system where the ULS logs are located, which isn’t always available, especially on a production environment.

Thanks to Christophe, who pointed me at this excellent CodePlex solution called SPCorrelationViewWP, is the brainchild of Tom Van Gaever who has done a fantastic job. The project provides a web part and a site action menu item which allows you to enter a Correlation ID and pulls back the relevant ULS log entries for that Correlation ID directly within the SharePoint GUI.

After installing the solution two items will be added, including a new web part to the web part gallery.

Also the solution will add a new menu item to the Site Actions menu which when you click, will pop up a dialog for you to enter a Correlation Id to pull back the relevant ULS lines, all without needing to grant the user access to the file system directly to read the logs.

After looking at the solution, I wondered if it might be more appropriate to offer the Correlation ID lookup via Central Administration, after all, you may not want all end users seeing the option, or giving them the capability to trawl through the logs. So whilst making a minor code fix to allow the Site Actions item to work for Project Server, I also coded up a new feature which adds a Correlation Id item to the Monitoring section of Central Administration.

These changes have been uploaded as a patch which you can download the source directly from here, hopefully it will get accepted into the main solution in the coming weeks. Tom is also requesting feedback and feature suggestions on the project via the discussion forums, so please make sure you give him feedback.

Out of the box Project Server provides the ability to store a project’s risks and issues within an associated project workspace. As these risks and issues are stored in SharePoint lists, there is a tremendous amount of flexibility to customize these lists. As a consultant, a common request I hear again and again is the need to extend the out of the box risks lists to encode some form of risk matrix, such as the one outlined below:

Implementing such a matrix is relatively simple thanks to SharePoint calculated columns, but can be fiddly to get correct. In this post I will run through the process of setting up the risk list to encode the matrix above and hopefully provide you with some insights on how it works that you can leverage elsewhere.

Setting up the columns

Before setting up the matrix, it is necessary to set up the three columns required to support the matrix:

· Consequence – used to store the risk consequence

· Likelihood – used to store the risk likelihood

· Residual Risk – used to store the calculated risk from the matrix

Each of these columns will be added to our Risk list in the Project Template site.

Remember: If you intend for this customization to be available in all new project sites moving forward, it is essential you make the changes in a template site not linked to a project and then register that template into Project Server.

Consequence & Likelihood

In the Project Template site Risk list, create two new choice columns called Consequence and Likelihood. In each column set of the choice values to be as follows:

Consequence Choice Value	Likelihood Choice Values
(1) Insignificant	(1) Rare
(2) Minor	(2) Unlikely
(3) Moderate	(3) Possible
(4) Major	(4) Likely
(5) Extreme	(5) Almost Certain

Residual Risk

The last column that needs to be set up is the Residual Risk, unlike the other two columns, this is a calculated column and uses a formula to reference the Consequence and Likelihood columns to determine the Residual Risk. The formula itself consists of only three operators, IF OR & AND and is relatively simple to implement, however as you can see in the matrix above, there are 25 different conditions that need to be encoded, so there is a lot of it

=IF(OR((Likelihood="(1) Rare"),AND(Likelihood="(2) Unlikely",OR(Consequence="(1) Insignificant",Consequence="(2) Minor",Consequence="(3) Moderate")) ,AND(Likelihood="(3) Possible",OR(Consequence="(1) Insignificant",Consequence="(2) Minor")),AND(Likelihood="(4) Likely",Consequence="(1) Insignificant"),AND(Likelihood="(5) Almost Certain",Consequence="(1) Insignificant")),"Low",IF(OR(AND(Likelihood="(2) Unlikely",OR(Consequence="(4) Major",Consequence="(5) Extreme")),AND(Likelihood="(3) Possible",OR(Consequence="(3) Moderate",Consequence="(4) Major",Consequence="(5) Extreme")),AND(Likelihood="(4) Likely",OR(Consequence="(2) Minor",Consequence="(3) Moderate")),AND(Likelihood="(5) Almost Certain",OR(Consequence="(2) Minor",Consequence="(3) Moderate"))),"Medium",IF(OR(AND(Likelihood="(4) Likely",OR(Consequence="(4) Major",Consequence="(5) Extreme")),AND(Likelihood="(5) Almost Certain",Consequence="(4) Major")),"High",IF(AND(Likelihood="(5) Almost Certain",Consequence="(5) Extreme"),"Extreme"))))

Deciphering the above can be a bit daunting, but in essence the formula is broken down into four IF statements that are nested, each used to determine the residual risk condition (Low, Medium, High or Extreme). Within each IF statement the relevant Likelihood and Consequence values are evaluated. In the case of the ‘Low’ residual risk, there are five different evaluations as outlined below:

Evaluation	Formula
1	(Likelihood=”(1) Rare”),
2	AND(Likelihood=”(2) Unlikely”,OR(Consequence=”(1) Insignificant”,Consequence=”(2) Minor”,Consequence=”(3) Moderate”)) ,
3	AND(Likelihood=”(3) Possible”,OR(Consequence=”(1) Insignificant”,Consequence=”(2) Minor”)),
4	AND(Likelihood=”(4) Likely”,Consequence=”(1) Insignificant”),
5	AND(Likelihood=”(5) Almost Certain”,Consequence=”(1) Insignificant”))

If any of the above evaluations are true, then the IF statement will return the text ‘Low’ into the calculated column.

Debugging

With a formula as complex as the above, it’s pretty easy to forget a comma or bracket. Unfortunately SharePoint is a little unforgiving and if you get it wrong and you will see an (un)helpful error message like this:

Unfortunately if you get an error all you can really do is review the formula to try to work out where the problem is.

Once the formula is accepted test each Residual Risk calculation manually by creating a risk and setting the relevant values for the Likelihood and Consequence and saving the risk.

If all goes well you will now have a new column called Residual Risk that is automatically populated depending on the values entered in the Likelihood and Consequence columns as outlined in the Risk Matrix.

Hopefully this has given you an overview of how simple it is to extend the risk list to encode a risk matrix. Of course you are not limited to just risks, the technique outlined above can also be applied to the issues list, or any other list within any SharePoint workspace where you want to encode an automated matrix type calculation.

Update: Gord Schmidt has posted a more elegant number based approach to the matrix here.

I am pleased to announce I will be speaking at the upcoming Australian SharePoint Conference in June on ‘Managing Projects in SharePoint 2010’. This is a 200 level presentation in the business track and kicks off straight after the keynote!

The abstract is…

Managing Projects in SharePoint 2010, a match made in heaven – 200 Level
Today it is more important than ever to ensure every project your organisations undertakes is delivered effectively. To accomplish this, it is essential that there is clear communication across the project team and effective tools to facilitate your project management process.
Come and see how SharePoint 2010 can improve the management of your next project, including the new Project 2010 client integration, Access Services, Reporting with Visio & Excel Services and team site improvements.

I will no doubt manage to get a bit of Project Server in there as well

You can read more about the Australian SharePoint Conference at www.sharepointconference.com.au , and can register here. I look forward to seeing you there.

In a departure from the usual content on this blog, I thought I would try something a bit different, a screen cast. To start of, I have picked one of my favourite features of Project 2010, Sync to SharePoint, a fantastic little feature that allows you project schedule to be synchronised directly with a SharePoint Foundation team site list.

This screen cast is very much a toe in the water , so if you like them, please let me know and I will do some more.