Tuesday, March 19, 2019

Delegation in Project Online: what's wrong??

4 years ago, I wrote an article about the delegation limitations and it has reached a great number of views. I guess this is because the delegation feature is (I should say was) intensively used by administrator for daily support and security model use case testing.

However back to May 2016, we noticed a strange behavior while running delegation sessions. Starting a delegation session for a user with limited access (team member for example), we were seeing more projects than we were supposed to. As usual, Brian Smith reacted promptly and published an article to explain this unexpected behavior. I didn't update my initial article at this time, and I now feel like I should write a short post about it since I still see this question on the TechNet forums and from some on my customers, so I think that this change in the delegation feature is still not completely known and well understood.

Basically you'll see this unexpected behavior if the delegate user is a global administrator (O365 admin or Site Collection admin). Here the reason of the change, with Brian's words: "The reason for the change is that in Project Online customers were accidentally locking themselves out of PWA by removing all their PWA administrators – and then the only way to make a user an admin again was to open a support call". To avoid this frustrating situation where the admin is locked into a delegation session, this restriction was created.

The workaround is unfortunately not magic: you simply have to use a session (not delegated) of a user to test the security model. 

Share this article :

Thursday, March 7, 2019

PowerBI : manage different project calendars in your dahsboards.

Following my previous article talking about how to manage your calendar working time as a parameter in PowerBI, I had an interesting comment from my fellow colleague Xavier Trottin. Xavier has a similar role as me, but works most of the time with larger organizations. Meaning that they often (always) have different project calendars because they are managed in different countries with specific working week hours.
Thus my previous method doesn't work. It would require having as many parameters as calendars. 

The way Xavier proposes to manage this use case is to retrieve the minutes per day, which is a data based on the project calendar and attached to each project. The issue is that this data is not accessible in the standard OData reporting PROJECTS table (/_api/projectdata). You have to collect it from the /_api/ProjectServer/Projects table.

Here are the steps to perform to go further in your deployment industrialization.

1- Create a new query. In the source step of the new query, access the table mentioned above. Note that since the PWA url parameter goes until /PWA, you don't have to create a new parameter.



2- Select the ID and minutes per day columns. Note that you can find here a lot of useful information, such as "ischeckout" or the last saved date.


Then you'll get the query output as following, with the project ID which will be the key of the merge and the minutes per day (420 in my example for 7 hours/days).


3- Merge queries. From the standard PROJECTS query, merge it with the newly created query. You'll have to select the project ID from both queries to merge the tables.


4- Expand the column. I'm not really sure if this stage is mandatory but it allowed me having the minutes per day column in the standard PROJECT table in addition to the merged query. You do not need to include the ID column since it is only used for the merging step.


5- Use the new measure in the formulas. Back in the desktop client, for the project duration in days in my example, I divide it by the minutes per day multiplied by 60 (to get hours).


Et voilà! Thanks again to Xavier for the tip. And remember that those improvments have a considerable added value since you do it on one report and you can deploy it for any customer.

Share this article :

Tuesday, March 5, 2019

PowerBI : manage the working time as a variable in your dashboards!

In PowerBI reports, I usually propose a set of dashboards including standard indicators. On a portfolio dashboard such as the one below, you'll always find the duration, baseline, variance, etc...


By default, any data related to time unit in the reporting database is expressed in hours. When you talk about work, it might relevant, but duration are most of the time more comprehensive in days.

In my first reports, I used to create a new column with a formula dividing the duration by the number of hours in a working day.


When you have one major Project deployment per year, this can be a suitable solution. However I personally saw the change in our Project consultant job: with Project Server, we used to do major deployments which could take months and even years. Now with Project Online, since you don't manage the infrastructure part, deployments are much more simpler and quicker. Moreover much more organizations are interesting in deploying Project Online since it is now opened also to smaller companies (less licensing fees). Therefore we are doing a large number of smaller deployments.
All that to say that with this new paradigm, we do need to industrialize our deployments and particularly PowerBI reports deployments. In the usual use cases where the working days can be different in all organizations, the method described above can be time consuming.

So here is the solution: set the working time as a variable.

1- In the PowerBI Query Editor, select "new parameter". You can create a new parameter "hrs_day" with a list of values (7, 8, etc...) and select the current value for the company you're deploying Project Online.


Note that I already have the PWA tenant URL as a parameter.

2- In the dataset where you need to convert hours into days (Project dataset in my example), add a custom column calling the parameter.


3- Back in the desktop client, select again the Projects dataset and select the measure having the manual calculation (.../7). You can also create a new column. Replace the division by 7 by the new parameter.

Here is how to manage working time as a parameter in your PowerBI dashboard. This will optimize your report deployment for new customers and make you reporting toolbox more efficient.

Share this article :

Wednesday, February 20, 2019

Change your default PWA site in Project Home

Thank you Brian (see article)! We can now change the default PWA site in Project Home. 
This is a nice improvment, in the same direction than the permission mode being configurable from PWA settings (versus the SP CA). Now orgnizations tend to have more PWA sites and do need more flexibility to manage several PWA sites. This is also why proposing the new Project Home was very relevant.

From Project Home, you'll find this new "Default PWA site" option.


Then you can select a new PWA url.


When you select a PWA site, Project Online checks if the active account has the right permissions on the new defaut site.

Then what's new? When you'll create a new project from Project Home, it will use the new default PWA. Also the "Go to Project Web App" link will open the default PWA site.

If you are curious, you'll notice when you hit the "Go to Project Web App" that the URL is the following, using the "default" property.




Share this article :

Project Online permission mode directly accessible from PWA settings

When Project Online was released back in 2013, Microsoft introduced the SharePoint permission mode. I've never understood why but this SP permission mode has always been the default mode, where as in most of the cases, the Project Server permission mode was the one to choose.
Indeed the SP permission mode requests to manually give permissions to user in both SharePoint and Project Online, on every projects. Where as the well known Project Server permission mode, even if it is more complex (groups, categories, RBS), is much more simpler to manage once define. It embeds a synchronisation between projects and Sharepoint sites. It also allows defining permissions at group/category level and only requires adding users to groups.
At this time, we only had a few PWA site available for creation : 3 in 2013, then 10 few years later. But now we have up to 9999 PWA sites available, so organizations use to create more PWA site for test, demo, training, different departments, etc...
So at every PWA site creation, the administator has either to change the permission mode in the SharePoint CA (Project Online) or to run a Powershell command (Project Server) to switch from SP permission mode to Project Server permission mode.

This is now over since the permission mode can be set from the PWA setting in the additional server settings.


Share this article :