EPMSource

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.

Recently I have been working on a number of projects where the requirement to disable ribbon commands in Project Server has come up again and again. There are a couple of posts out there around modifying the ribbon, but they tend to focus on adding new items, not removing or disabling them, so I thought I would post something covering it. Of course, before you look at disabling the ribbon item through a customisation, you should look to see if the item can be disabled using the Project Server security model first.

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.

 

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.

It’s less than two weeks until TechEd Australia, and I have been hard at work with Brian Farnhill  putting the finishing touches to the presentation and demonstrations.

For those of you coming along, I will be taking part in two sessions:

OFS310 The SharePoint Developers Guide to Project Server 2010

Friday 2nd September – 9:45am – 11:00am

It’s just meant to be – Project Server and SharePoint server are better together, and this is the session that will show you why. Come and join us as we take you on a tour showing how the two products work together, and how you can deliver better solutions by integrating the two. Get to know how developers can leverage both of these great tools together and how you can deliver more value, what the features of the tools can offer and what you need to know as a developer to start solving real world business problems.

AIT001 | Ask a SharePoint Expert: Q&A Panel (End / Business Users)

Tuesday 30th August – 6:30pm – 7:00pm

Join the SharePoint End / Business user ‘experts Alexander Burton. Dan Holme, Ben Walters & Bhavik Merchant for a open forum Q&A panel in the SharePoint Interactive Theatre in the Expo hall, sponsored by AvePoint.

Finally, it would be a crime to miss out on fellow Project MVP, Marc Soester’s session. Marc is a fantastic speaker and his sessions always entertaining and informative.

OFS311 BI and Reporting using Project Server and SharePoint

Thursday 1st September – 3:30pm – 4:45pm

One of the main challenges organisations face is giving users the flexibility to report against Project, Resource and Portfolio information. This session will give you the insight on how you can take advantage of the great reporting features in Microsoft Project Server 2010 and Microsoft SharePoint Server 2010. By utilising Microsoft Project Servers build in Data Warehouse in combination with the SharePoint Business Intelligence tools, Project Server delivers what your Project team and your Executives require.

Learn how users are able to generate their own ad hoc reports minimising the overall cost and effort to produce meaningful reports. This session will give you a deep dive on how to manage projects, Resource and portfolio dashboards by creating Key Performance Indicator (KPI) reports using PerformancePoint Services, Excel Services and Power Pivot utilising Microsoft SQL Server and Microsoft Analysis Services 2008 R2.

I will be at TechEd Australia all week, so if you have any questions, or would like to catch up to see some more of Project Server, please do not hesitate to contact me.

I recently had a customer ask me how to use the Skip to Stage functionality of Nintex Workflow for Project Server. Now I know I have done a few Nintex posts recently, but I promised them I would post this for the greater good of the EPM community  (and will lay off Nintex for the next few months).

In case your not aware, the Skip to Stage capability of Project Server allows an administrator to skip a workflow to a particular stage, usually as a result of modifying the existing workflow, or swapping to a different workflow and needing to skip over some of the business logic or steps.

Sam Chung wrote an excellent blog post on this over at the Project Programmability blog back in February 2010, and the same concepts apply to Nintex. Consider the flow chart below which outlines a simple Project Server workflow scenario.

Should the administrator wish to skip this workflow to the the execution stage, and skip the approval, it is not possible as the workflow has not been coded to allow it. This is where the Skip To Stage information comes into play. When an administrator chooses to skip to a specific stage using the Server Settings > Change or Restart a workflow, the workflow is initiated with two pieces of information:

• the Skip To Stage parameter set to ‘True’;
• the Stage UID of the desired stage to skip to is passed through.

In the workflow, if logic is added to check for this, then it is possible to bypass the business logic for the stage and skip over. The Project Server workflow engine is clever enough to determine if the stage being skipped to is the stage in the StageUID and will stop the skipping there (however the same caveats that apply for a Visual Studio workflow apply and if the required fields for a stage being skipped are not completed, the workflow won’t skip).

 

Now to incorporate this into a Nintex Workflow for Project Server couldn’t be simpler, all that is required is to use the ‘Set a condition’ action to do a check on the Skip To Stage context variable, and then branch to the approval / flexi task (as below) if the value is no, or to skip over the approval logic if the value is yes. In the screenshot below, I have also added a ‘Set Status Information’ so I can log to the workflow that the skip is happening.

 

The Skip To Stage information is stored within the Workflow Context, so when setting up the ‘Set a Condition’ action, make sure you pick the Workflow Context.

Finally, as mentioned in Sam’s original blog post, you need to ensure you have selected the Always Wait option in your Set Stage actions.

If you don’t do this, the workflow may continue to skip past the requested stage.

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.

One of the coolest features of Internet Explorer 9, other than the standards compliance and in the case of the Release Candidate, the general speed and stability improvements, is the ability to pin sites to the Windows 7 taskbar allowing you to launch your favourite websites with one click.

With a little more effort, it is possible to define a number of task specific entry points into your site through a jump list that is available when the user right clicks on a pinned site. Imagine the possibilities of this for users of Project Server, having the ability to navigate directly to their timesheet page, or into the business intelligence dashboards all from a jump list entry on the Windows 7 taskbar.

After some inspiration from Brian Farnhill’s excellent SP Jump List Codeplex project, I set out to build a slightly more simplistic version that a Project Server administrator could deploy to PWA easily and provide a number of static links into Project Server functions for any user that pinned the PWA site. In this case, we are going to add a number of links to key Project Server functions such as Project Center, My Tasks and Server settings.

Adding the links is as simple as embedding a small piece of JavaScript within the PWA landing page. The JavaScript defines the attributes of the jump list, namely:

• the name of the jump list (Project Server Links)
• the jump list task icon
• the jump list task name
• the link to invoke when the jump list task is clicked

and wraps them up inside a try / catch and a couple of other JavaScript calls that Internet Explorer 9.0 recognises and interprets.

try {

			window.external.msSiteModeCreateJumplist('Project Server Links');

		        // Server Settings
		        window.external.msSiteModeAddJumpListItem
	        	('Server Settings',
		         '/pwa/_layouts/pwa/admin/admin.aspx',
		         '/_layouts/inc/pwa/images/ProjectServer.ico');

		        // Personal Settings
		        window.external.msSiteModeAddJumpListItem
		        ('Personal Settings',
		         '/pwa/_layouts/pwa/home/personalsettings.aspx',
		         '/_layouts/inc/pwa/images/ProjectServer.ico');

		        // Timesheets
		        window.external.msSiteModeAddJumpListItem
		         ('My Timesheets',
		         '/pwa/timesheet.aspx',
		         '/_layouts/inc/pwa/images/ProjectServer.ico');

		        // My Tasks
		        window.external.msSiteModeAddJumpListItem
		        ('My Tasks',
		         '/pwa/tasks.aspx',
		         '/_layouts/inc/pwa/images/ProjectServer.ico');

		        // Resource Center
		        window.external.msSiteModeAddJumpListItem
		        ('Resource Center',
		        '/pwa/resources.aspx',
		         '/_layouts/inc/pwa/images/ProjectServer.ico');

		        // Project Center
		        window.external.msSiteModeAddJumpListItem
		        ('Project Center',
		         '/pwa/projects.aspx',
		         '/_layouts/inc/pwa/images/ProjectServer.ico');

			window.external.msSiteModeShowJumplist();

	}

	catch (ex) {
	    // fail silently
			}

You will notice that the items in the JavaScript are in a reverse order to that which they appear in the jump list, this is required as when IE is building the list, it puts the most recent item read on the top of the list. Customising the list is as simple as choosing what items you wish to link to then updating the JavaScript accordingly. The Try / Catch ensures that if there is an error, you won’t get a ‘Error on Page’ error on your PWA instance.

Once you have customised the JavaScript to contain the links you want all users to see when pinned, save the file as PS Jumplist.txt to a document library within your PWA site and note the URL of the document.

To add the JavaScript into the page itself, put the PWA page into edit mode via Site Actions > Edit Page, and add a Content Editor web part to the footer web part zone. Using the Edit Web Part properties set the content link to the URL of the PS Jumplist.txt file. It’s also a good idea to rename the content editor web part in the Appearance section to something more meaningful, in this case I have called it JavaScript – IE9 Jump List.

Once the configuration has been completed, save the PWA page.

Now when users open the PWA page, the custom JavaScript will be included in the page. If that user happens to be using Internet Explorer 9 and pins the site, the JavaScript will fire and the various items added to the IE 9 jump list.

Of course, as I highlighted above, this solution is fine for static jump list links, but in many Project Server implementations users may have access to different items, depending on their Project Server group memberships. In the implementation above, should the user not have access, they will get an access denied error. A more elegant solution would be to check the users access level and to dynamically build up the JavaScript code as a result, stay tuned, I am working on it

Update: 20/12/11 – As noted in the comments, you will of course need to wrap the above javascript in a <script type=”text/javascript”> </script> tags for it to work correctly.

Twenty ten has been a massive year. With the release of Project 2010, the interest it has generated amongst customers & the community and the 20,000+ visitors we have received on this blog it feels more like it’s been two years!

Next year looks set to be an even bigger year, with the continued growth of the Project 2010 and a bumper crop of new posts ideas I have been working on.

So with that, I am having a couple of weeks off to recharge, hit the beach and soak up some of the Australian summer with my family before I have to head back to work in early January.

Thanks for your support in 2010, and hope to see you again in 2011.

Alex.