Quick & dirty way to bulk delete project sites

I had a requirement to bulk delete 2000 project sites. This used to be much easier in good old PSI days. Project Server CSOM couldn't do it and PSI support has been removed from Project Online & Project Server 2016.

To solve this problem, I wrote a script that basically simulates going to "Connected SharePoint Sites" page and click "Delete Site" button for each Project :) This is tested on Project Server 2016 only.

Here are the steps to apply this script.

1- In Chrome, go to PWA Settings -> Connected SharePoint Sites
2- Press F12 to get in developer mode
3- In Console window, copy paste the script provided at the end of this article and press Enter
4- Type DeleteSites() and press Enter
5- Watch the magic in Console :)

The JavaScript code is as following

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

https://gallery.technet.microsoft.com/Publish-All-Projects-in-ad8ee80e/file/174745/1/Publish_All_Projects_ProjectOnline.ps1

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
https://gist.github.com/hammadbinarif/6a3312528040f717a510c0a3d0f55df0

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 

https://gist.github.com/hammadbinarif/822e8eae649851822d1abd9d6a7af4e3

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

https://stackoverflow.com/questions/10183440/console-is-undefined-error-in-ie9

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.