Publish all projects in Project Online using PowerShell

I was looking for a PowerShell script to publish all projects in a Project Online instance but surprisingly (or due to lack of correct google terms) couldn’t find one.

So I ended up writing one myself and uploading it on TechNet for rest of the world. You can directly download the script from this link

Best practices for writing JavaScript for Project Online – Part 5

Write values to PDP input fields.

If you have followed my previous blog, you’d know how to tap an input field value on a PDP. Once you get hold of it, you can perform many operations like hide it, lock it, move it etc. using simple JavaScript operations.

In one of my apps, I was a bit surprised to learn that setting a field value programmatically e.g.  (‘#YXZ’).val(‘123’) wasn’t sufficient for a PDP to detect that an input value has changed and it should save the value back to project when the save button is pressed.

So to simulate the experience as if an end user has typed the value. I had to trigger the JavaScript change event. This then successfully forced PDP infrastructure to save the value back to project.
TypeScript code to write values back to PDP is following.

You can also download the code from

Best practices for writing JavaScript for Project Online – Part 4

Read input field values on a PDP

Sometimes, in our script we need to know the values of custom fields to render our own output. Case in point, I once had to draw cool d3.js based graphics representing project status based custom field values. See the sample output below

Now I could have read the values from Project Odata endpoint /_api/ProjectData/Projects but the requirement was to update the graphics as soon as user changed those values. I’ll probably share some other key aspects of this script (rendering graphics and updating it when user changes it) in a different future blog. The focus of this blog is the piece of code that I wrote to read input field values.

The input field values are displayed as editable input boxes if a project is in edit mode. As shown in the screenshot above.

In non-edit mode, the fields are displayed as simple text values inside a DIV tag which in turn resides inside a TD tag. However, even in edit mode, there are cases where fields would be displayed as simple text, e.g. when a field is a calculated field or it is locked in the current workflow stage etc. see output of non-edit mode below.

The important points about the code that I am going to share are following

  1. The code is in TypeScript but could easily be transformed to JavaScript. I highly recommend using TypeScript for any medium and large sized scripting apps. 
  2. It depends on JQuery
  3. If in future, Microsoft changes the HTML Dom structure of a PDP page, the code will likely break and will require an update. 

Without further ado, following is the code to read Number, Date & Text values from PDP in both edit and non-edit mode. This code can be downloaded from 

In my next blog, I’ll talk about writing values back to PDP fields. Fun trivia: It is not as simple as changing the values of the input fields 😊

Best practices for writing JavaScript for Project Online – Part 3

Create dummy console object to avoid script error in Internet Explorer

One common issue I face with Internet Explorer version 11 and below is that If I my code uses console object for diagnostics, it blocks the execution of rest of the script.

Interestingly, if I open a debug console (by pressing F12 or right click -> Inspect element), the script executes just fine without any error message. After some google search it turned out that IE does not have a console object defined if a console window is not already open. See this stack overflow question for details

To avoid this error simply add these lines at the start of your JavaScript code. This will create a dummy console object if the real console object doesn’t exist already.

Best practices for writing JavaScript for Project Online – Part 2

Checking the Project details page edit mode

The tip is about changing script behaviour based on the fact that project is editable or not.

I recently created a custom editable grid for user to enter project financial information. However, I wanted the grid to behave like regular PDP input fields which does not allow editing if the project is not in Edit mode. See the output of my grid in Edit and non-edit mode.

When PDP is in edit mode

When PDP is not in edit mode

On every PDP, project online PDP infrastructure injects a global object named EditState which exposes some useful information about the current edit state of the PDP. One of its property EditState.Editing is set to true when the page is in edit state. See the following example code.

In the next part of this series, I’ll talk about how we can avoid a common Internet Explorer error

Best practices for writing JavaScript for Project Online – Part 1

Checking the Web Part page design mode

In this series of blogs, I’ll share some the practices I use to write better JavaScript to customise Project Online screens.

The first tip is about detecting the web part page edit mode. Frequently, we write scripts to manipulate UI of the page and if the user is already editing the page, our script can cause undesired behaviour.

We could either execute a different set of functions or at minimum, just not execute the script in design mode to keep the user experience clean.

Its relatively simply to detect the WebPart page design mode. Just add the following code to the startup your script.

In the next part of this series, I’ll talk about how we can detect if a Project Details Page is in Edit mode.

Fixing SharePoint designer 2013 workflow that won't switch to "Text-based designer" view

I recently wrote a big (200+ lines) List workflow in a SharePoint designer 2013. Those of you who have done it know that it becomes hard to maintain the workflow of this size as SPD is not really designed to author large workflows.

After spending few days, it become common for workflow designer to display validation errors every now and then which happened because SPD kept mysteriously deleting the variable references from the workflow actions.

Finally, i reached the stage where my workflow will not open in text-based designer mode, no matter what i do. It always opened in Visual designer mode with empty visio page.

Exporting the workflow as vsdx file and re-importing as new workflow didn't solve the problem.

After some experimentation, i was able to recover my workflow using the following procedure.

  1. I exported the original workflow as vsdx file using export to visio function. 
  2. I deleted the workflow from SharePoint designer
  3. In SharePoint designer, I created a new workflow “temp” and associated with my original SharePoint List.
  4. New workflow had only 1 line which was logging to history list. I published the workflow
  5. On my computer, I renamed the .vsdx file (step 1) to .zip and extracted all its contents.
  6. In SharePoint designer, I went to navigation windows on left hand side, there i clicked All Files -> WfSvc1 (this is a known folder where SPD stores workflow files)
  7. In that folder, there were many sub-folders, each having a guid as its name. each folder represents a workflow
  8. Went inside each folder and picked the folder which has most recent last modified date for workflow.xaml file (this represents workflow created in step 1)
  9. From the extracted folder (step 5) I copy pasted the file workflow.xaml to the SPD folder (step 8)
  10. Restarted SharePoint designer
  11. Opened the workflow designer page for the new workflow "temp" and it showed the restored workflow J
  12. Renamed & published the workflow

As a lesson learned, i decided to break the workflow into smaller manageable workflow pieces, so that the damage remains minimum in case of future corruption.