Out of the box, the printing capability in the Project Web Application is limited to the grids, including the schedule grids that are visible in a schedule PDP and uses a custom page to render the information as can be seen below.

After a little experimenting with the Internet Explorer printing, it seems that PDP’s can be printed quite well directly from the browser, so I thought I would try and pull together a ribbon feature that enables PDP printing.

The feature consists of XML button definition and a little piece of JavaScript to determine if the button will be enabled or not. This is important so that the button can be disabled when the user is on the schedule page that has it’s own grid based printing function like the picture above. For the purposes of this feature, I have gone the quick route and do the check based on the name of the page, in this case if the page is called schedule.aspx the button will be disabled. You may need to modify this check if your schedule based PDP(s) have a different name.

The element.xml looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction Id="Ribbon.Tabs.PDP.Home.Print"
				  Location="CommandUI.Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.Tabs.PDP.Home.Groups._children">
					<Group Id="Ribbon.Tabs.PDP.Home.Print"
						   Sequence="60"
						   Description="Print Custom Group"
						   Title="Share"
						   Command="EnableCustomGroup"
						   Template="Ribbon.Templates.Flexible2">
						<Controls Id="Ribbon.Tabs.PDP.Home.Print.Controls">
							<Button Id="Ribbon.Tabs.PDP.Home.Print.PrintPDP"
									Sequence="40"
									Command="PrintPDP"
									Alt="Print"
									Image16by16="/_layouts/$Resources:core,Language;/images/ps16x16.png" 
									Image16by16Top="-96" 
									Image16by16Left="-160" 
									Image32by32="/_layouts/$Resources:core,Language;/images/ps32x32.png" 
									Image32by32Top="-288" 
									Image32by32Left="-128" 
									LabelText="Print" 
									TemplateAlias="o1"
							        ToolTipTitle="Print" 
									ToolTipDescription="Print the contents of the PDP"/>
						</Controls>
					</Group>
				</CommandUIDefinition>
				<CommandUIDefinition Location="Ribbon.Tabs.PDP.Home.Scaling._children">
					<MaxSize
						Id="Ribbon.Tabs.PDP.Home.Scaling.Print"
						Sequence="140"
						GroupId="Ribbon.Tabs.PDP.Home.Print"
						Size="LargeLarge"/>
				</CommandUIDefinition>
			</CommandUIDefinitions>
			<CommandUIHandlers>
				<CommandUIHandler Command="EnableCustomGroup"
								  CommandAction="javascript:return true;" />
				<CommandUIHandler Command="PrintPDP"
								  CommandAction="javascript:window.print();" 
								  EnabledScript="javascript:
								  function disablePrintForSchedule() {
									var sPath = window.location.pathname; 
									var sPage = sPath.substring(sPath.lastIndexOf('/') + 1); 
									if (sPage.toLowerCase() == 'schedule.aspx') 
									{
										return false;
									}
									else 
									{
										return true;
									}
								   }
									disablePrintForSchedule();"
/>
			</CommandUIHandlers>
		</CommandUIExtension>
	</CustomAction>
</Elements>

The process of building the feature is exactly the same as outlined in http://epmsource.com/2011/12/13/hiding-disabling-ribbon-items-in-project-server-part-ii/ but substitute the above code into the Element.xml file and change the feature name accordingly.

Once the feature is deployed and activated a Print button should available on the PDP ribbon that when clicked will invoke the Internet Explorer print dialog.

From my preliminary testing, the output is pretty good, as can be seen from this ‘Print to XPS’ below:

I have uploaded the full source to Skydrive which can be downloaded from the link below.

Project PDP Print Page

 Happy PDP printing

There are a number considerations for allowing your reports and scorecards to render correctly on an iPad. From my limited testing most, if not all of the the Project Server v1 demo image rendered correctly without modification, with the exception of one of the status reporting services reports. Microsoft published a technet article outlining the limitations of the type of reports that can be displayed on the iPad and tips on how to interact with the reports.

Finally, don’t forget to check Brian Smith’s and Adrian Jenkins webcast covering the contents of the December CU including the various fixes and design changes it implements, to make sure the patch is right for your farm & circumstances.

Happy Patching

The full conference agenda has not been published yet, but at a high level covers:

• 15 customer-led sessions (representing 6 verticals) where customers share personal success stories using Microsoft Project and Portfolio
  Management (PPM).
• Project desktop best practices for scheduling, program management, Earned Value, and more.
• Project Server best practices for Demand Management, Portfolio Analysis, Resource Management, Time Management, Business Intelligence, and more.
• Key solutions overviews and case studies for Application
  Lifecycle Management, Innovation Process Management, Product Lifecycle Management, Dynamics AX integration, ERP integration, and more.
• Technical best practices for IT Professionals and Developers.

Last week I was excited to find my session , ‘Building advanced Project Server workflows with Nintex Workflow for Project Server’ had been accepted. The sessions abstract is as follows:

Many organizations have used Nintex Workflow for Project Server to help them build their demand management workflows quickly and effectively. This session will show how your project management processes and governance can be implemented using demand management workflows, integrating workflows with Project Server event handlers and applying workflows in project team sites. We’ll also provide a few other tips and tricks on implementing these processes.

I have been hard at work with some awesome demonstrations that will show off the capabilities of Nintex Workflow for Project Server and am counting down the days to getting over to Phoenix and talking shop

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.

What you need to know about the ribbon

If you are going to do any work on the ribbon, you need to be aware of a couple of things, firstly for performance reasons the ribbon is cached client side, which makes it really really painful to work with as your changes may not be visible straight away. To get around this, I found using the InPrivate mode of Internet Explorer stopped the client side caching and ensured my ribbon changes were visible.

Secondly, if you are going to hide or disable a ribbon item you need to know the ID of the item. Both SharePoint and Project Server have xml configuration files that define the structure of the ribbons, for SharePoint the ribbon structure is defined in a number of files, but the main one is CMDUI.XML located in {SharePointRoot}TEMPLATE\GLOBAL\XML\CMDUI.XML. For Project Server, the ribbon definitions are kept in the PWACONFIG.XML file located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\PWARibbon\listtemplates. The file itself contains the configuration of each button within the PWA app, including the name, image, command to be fired when clicked and references to the tooltips etc.

Finally, in the case of Project Server, you need to make sure you find the correct Id, things like the Timesheet ribbon have different id’s depending on whether the timesheet is running in Single Entry Mode, or normal timesheet mode.

To disable or hide? That is the question…

There are two schools of thought when disabling commands in SharePoint and therefore Project Server, to disable or hide the buttons. Hiding the buttons will remove the button completely from the ribbon, whereas disabling the button will leave the button on the ribbon, but in a state that cannot be clicked, thus stopping the functionality the item provides.

Normal
Disabled
Hidden

As you can see from above, the disabling route will be less confusing and will lead to a more consistent user experience for end users, but there are still situations where hiding might be the best route to go (I have a couple of customers that preferred hiding to disabling).

In the next post, we will look at how hide and disable a button using Visual Studio and some SharePoint features.

Whilst the WP7 marketplace has a wide variety of application that is growing on a daily basis, it is a little light on Project related applications. So inspired by the fantastic Project Server and SharePoint iPhone app by Giles Hamson, I thought I would have a go at doing something myself, so I am pleased to introduce Project Social.

What is it?

Project Social is a social viewer application that aggregates MS Project related Twitter and RSS feeds from the official MS Twitter accounts and blogs, a number of community blogs and the Project Server Technet content feeds all into one convenient application. Each item can be read directly on the phone where you can interact socially with it by via twitter (tweets, replies or retweets) email or directly via the browser. The application is based on the excellent Codeplex Social Viewer template which is constantly being updated, so watch out for some exciting new updates in the future.

Where can I get it?

Project Social is available now as a free download from the Windows Phone Marketplace or by clicking on the image below.

If you have any suggestions, or would like to add or remove your feed, please contact me directly at wp7@epmsource.com.

It’s time for the last MPUG Melbourne of 2011, being held at Microsoft Melbourne on Tuesday 6th December. In a change from previous events, this session is being held at 12:00pm, instead of the usual 5:30pm start, based on feedback from attendees.

The topic for December is The low-down on Project 2010 and Project Server 2010 Service Pack 1

We will provide an overview of the recently released Microsoft Project & Project Server 2010 Service Pack 1. Demonstrating the improvements that have been made that were highly requested by EPM users, including multiple-browser support, synchronisation to Microsoft SharePoint task list updates, manual scheduling extensions, and schedule web part improvements. We will also provide guidance on how to successfully deploy this Service Pack within your organisation.

If you’re running Project Server 2010 and haven’t installed SP1, then this is a must attend event. Registration is free, but please RSVP via EventBright so we know numbers.

Date:  Tuesday 6^th December 2011

Time: 12pm to 1:30pm

Location: Microsoft Melbourne, Level 5, 4 Freshwater Place, Southbank VIC 3006

• Close the web part – this stops the web part being rendered on the page, but still being created on each page load
• Delete the web part – this removes the web part from the page completely.

By default, when you click on a web part without putting the page into edit mode, the first option presented to the user is to close the web part, but not to delete.

It is only after you choose to edit the page that you will get an option to delete the web part, either in the context menu,

or via the Web Part Tools ribbon.

So what is the problem you may be asking? Well, in both cases,  to customise the templates the users had simply closed instead of deleting the web parts and then thinking all was good, saved the workspace as a template. When that template was used to create a new site, each of the closed web parts were restored and visible once again, effectively removing the customisations.

Luckily fixing this is pretty simple.

First, we need to gain access to the Web Part Maintenance page which will display all web parts on the page and their associated status. To get there, simply add the following to the URL – ?Contents=1 so…

http://project.contoso.com/PWA/ProjectSiteTemplate/default.aspx

becomes

http://project.contoso.com/PWA/ProjectSiteTemplate/default.aspx?Contents=1

This will display the web part maintenance page, showing each of the web parts and their associated status.

To delete the closed web parts, simply select the correct items and click on Delete. This will delete the web parts from the page.

Finally, save the site as a template once again and all new sites created with it will reflect your customisations. Of course all of this can be avoided by a simple bit of training to delete instead of close,  but if the web parts have already been closed, this will help you fix it.

During user acceptance testing, one user was unable to save and publish their project schedules into Project Server in one session as the publish button was disabled until the schedule was saved, MS Project closed and the schedule reopened. Only doing this would activate the Publish command in the menu.

On investigation it was found that the TRIM Context integration was causing the issue, specifically, when the file was saved, a TRIM record type dialog would be displayed that intercepted the save, causing the Publish menu item to become confused.

Luckily thanks to some investigation by the customer (thanks Claire and Federico), it seems that a setting within the TRIM Context options to ‘Integrate TRIM with Microsoft Project’ is to blame.

Simply unchecking this option will return the normal behaviour of being able to publish a schedule directly after saving.

In other organisations, it can also be a source of confusion when end users personalise a page and remove enterprise web parts from the page or totally configure the page , leading to an increased support overhead, which is why some organisations wish to turn off this capability.

Luckily doing so is incredibly easy and can be done at the web application level meaning both your PWA site and project workspaces can have Personalisation disabled in a couple of mouse clicks.

To start, navigate to Central Administration and choose Manage Web Applications

Select the web application you wish to turn of Personalisation off within, then click on User Permissions on the ribbon. This will show all the permissions for the web application which you can customise. Scroll to the bottom of the dialog box and uncheck Add/Remove Personal Web Parts and Update Personal Web Parts items.

Once you have saved the settings, you will find the Personalize this Page option is no longer available from the top right hand menu, stopping users from personalising PWA or any other sites within the web application.