by Martin Laukkanen | May 8, 2015 | Project 2016, Project Online
A week of Ignite in Chicago is coming to an end and I thought it is about time to share some of my thoughts and discoveries over the last week, firstly though it’s been great to see a lot of familiar faces amongst the 23,000 or so people here in Chicago!
I’m not going to do a full write up of every session I’ve seen, the great thing about the blog-o-sphere is I can point you to the great write-up’s done by others (@PWMather‘s posts here, here and here are a great place to start!). What I will do is focus on some of the details that have interested me most.
New Project 2016 features
First up of course is what can we expect from Project 2016 / Project Server 2016 and Project Online in the next release; hmm how do I say this diplomatically? – Not that much.
Write support in MS Project client side API
I really really wish this feature was available six months ago considering the work I have been doing for customers lately! Good riddance VSTO I say! :)
Resource Engagement – Request / Review / Approve resource assignments
This is a long awaited feature for Project Server, however for some reason it didn’t get much air-time here at Ignite, fortunately I’ve had a chance to see most of during my day job working with some TAP customers and it goes a long way to addressing the typical need for managing / controlling and monitoring resource usage and over-allocation in a typical organisations.
I have to say though, with a major disclaimer (as I am an employee of TPG – The Project Group), that this new feature doesn’t quite come close to what is available in TPG’s TeamManager App, but then again I think that’s great as it really shows the the benefits of the App Model that Microsoft has created!
No more Project Server database – Project database to merge with the Content DB
This is already happening in ProjectOnline, but the interesting thing is what does this mean for reporting directly from the RDB as it is not supported to report from the SP Content DB’s? Well the good news is that according to at least one MS product manager for Project it will still be supported, so allow me to quote @mikemcleanlive; “You will be able to report directly against the new consolidated db if it’s on a dedicated server” (I’m just going to ignore that little “if” in there for now)
Other improvements
- OData limit changes are good to see, specifically for Timephased data the max rows per request has been increased to 2,000, apparently this can improve performance by 10x, but more importantly however it will make it possible to actually report on timephased data via OData. (No sorry 2-3hours to wait until Excel times-out or crashes when loading those datasets in the past was not a viable solution)
- Zero-downtime patching, this is a great and very well received new feature on the SharePoint side.
- PowerBI, PowerBI, PowerBI, seems to be a popular topic here this week. Well seriously seeing what can be done using it connected to OData from Project is pretty cool, shiny responsive dashboards are cool (excuse my hint of sarcasm).
- No more Project Service Application – goodbye one more configuration step – details TBA. :)
- Small API changes previously announced (but now documented!) include BulkCustomField updates and ProjectCreate methods enabling faster custom field updates and controlled Project site create via workflows.
Final thoughts
I was really hoping to see more cool new features both for Project and SharePoint, much of the latter focused on Delve and Office Graph API which I have yet to see any relevance in the Project space. Additionally the push to be mobile first, cloud first for most of Microsoft seems to have been neglected in parts of SharePoint and especially Project Server, I expect it will be a very long time before we see PWA usable on a mobile phone for instance! :(
Having said that, the good thing about Microsoft’s online story with Office365 and Project Online is that all that hard work MS have put into making the software fast, responsive, stable and fully integrated across the full stack of MS products are all now going to be available on-premises as well, so this might mean Project Server 2016 is not going to be a major release (2003 -> 2007 or 2007 – 2010 for example) but it will be a solid upgrade for existing and new customers.
by Martin Laukkanen | Apr 16, 2015 | BulkEdit
A new version of Bulk Edit is available from the App store, check your site settings for the upgrade link now to install it.
Bug Fixes
- Updates to multiple fields in a single project failing without error.
- Update to correct filter issue when values contain special characters.
Installation
Open site contents in PWA to find the update link next to the App Tile.
Finally if you use and love Bulk Edit, please rate it in the App Store!
Updated 21st April: Re-released and updated to build 1.0.4.4.
by Martin Laukkanen | Mar 4, 2015 | How to, Project 2013, Project Online
Back in the days of 2010 there was a Project Site List Viewer WebPart that gave you the ability to show specific lists (Risks, Issues or anything) from a given project’s site in a PDP. While in 2013 on-prem you can still install that solution starter from Fluent-Pro (here), that doesn’t help you with Project Online and not to mention with the dozens of on-prem scenarios where the solution doesn’t work without code modifications. So recently I was asked to solve this problem again and I thought that I’d try to find another way.
Another (simpler) way
Let’s start with a screenshot of the end result:
Perfect it looks exactly like a typical SharePoint list only in the Project Detail Page for our project – and of course importantly it shows the Risk list from the currently open project.
Reason 9,999 why I love JavaScript
Basically using a small script we can show the actual SharePoint page for the risk list e.g. “/PWA/Project Name/Lists/Risks/AllItems.aspx?isdlg=1” in an iFrame on our PDP. To do that firstly you can see that I’ve added “&isdlg=1” to the URL which tells SharePoint to show the page without the rest of the SharePoint master page and quick launch menu in the frame (which just looks weird), then we need to update the address with the actual project’s name and finally by default the ribbon menu would be shown again in our frame so we need to hide that.
JQuery script
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
<script type="text/javascript">
function RenderiFrame (c) {
document.write('<iframe id="nbDataGridFrame" src="' + c + '" width="100%" height="1400" onload="hideRibbonMnu();">');
document.write('<p>Your browser does not support iframes.</p>');
document.write('</iframe>');
}
function runSummaryReport() {
var projectName = $("[id$=RootAspMenu]").find("[href*=projuid]").first().find(".menu-item-text").text();
var URLString = '/PWA/' + encodeURIComponent(projectName) + '/Lists/Risks/AllItems.aspx?isdlg=1';
RenderiFrame(URLString);
}
function hideRibbonMnu() {
var $isFound = $("#nbDataGridFrame").contents().find("#s4-ribbonrow");
if ($isFound.length > 0 && $isFound.is(":visible")) {
$isFound.hide();
}
else {
setTimeout(hideRibbonMnu, 100);
}
}
runSummaryReport();
</script>
Okay so I won’t go through it line by line, but in summary what the script needs to do is the following:
- Construct the correct URL to the list (Risks in this case) by obtaining the Project Name from the quick launch menu of the current page- Yes I’m assuming the default site naming based on project name!
- Passes the encoded URL into a function which renders an iFrame of the specified size.
- Finally as a part of the iFrame itself there is an ‘onload’ parameter which calls a function to hide the ribbon menu once the frame is loaded.
Installing the script
If you’ve not used the CEWP much before here are a few reminders on how to create a PDP with this kind of script:
Firstly save the script above to a file named “showListonPDP.html” (note it is .html not .js), then upload that to your PWA site contents where everyone can access it /PWA/SiteAssets/ or /PWA/Site Collection Documents/ etc.
Then create a new PDP as normal and add the Media and Content -> Content Editor web part:
Now edit the web part properties and paste in the URL of the script:
Note that the URL must be just the file name, not the full URL, e.g.: “/PWA/SiteAssets/showListonPDP.html”
Now add the PDP to your EPT and go ahead and open a project.
Just one more little thing
Now if you click the new or edit item menus it opens the form in the frame which could be better, fortunately SharePoint lists can be configured to open forms in a dialog, the option can be found from the list settings on the project site itself (obviously you want to do this on your project site template as well), so open your site project, go to the Risks list, and select site settings -> Advanced settings, at the bottom you will find:
Select yes and Ok, now when you go back to the PDP and click New Item this is what you should see:
Neat huh?
by Martin Laukkanen | Dec 8, 2014 | Project 2013, Project Online, Troubleshooting
I came across this one working with a customer recently, basically the following error comes up whenever you attempt to edit a project schedule in PWA and selecting a view that contains custom gantt chart formatting:
Error Message: View Failure: The view failed to load. Press OK to reload this view with the default settings….
In some cases users see the additional message of:
An error occurred while opening your project. Give us a few minutes and try again. …
Cause
While this error is quite generic as it can be caused by a number of things, this specifically only occurs when attempting to edit a project using the view in question, all other views work (view and edit) and these custom views definitely work when only viewing the project data.
For example modifying a view to use the following Gantt Chart with “Custom Duration 1” selected will result in this error:
Finally I have tested this issue on a number of Project Server versions and as far as I can see it exists on all Project Server 2013 SP1 and above – up to the latest Cumulative, as well as Project Online (at the time of writing).
However it does not affect Project Server 2010.
Solution?
Sorry can’t help you here, other than to disable the customisations to the gantt chart! I’ll be logging this one with Microsoft and will update this post if anything comes of that.
by Martin Laukkanen | Nov 25, 2014 | Apps, Reporting
Project Server 2013 changed a lot when it comes to both security and reporting and I’ve had a few customers asking about configuring user access to OData both for reporting and apps (such as Bulk Edit), fortunately Microsoft has some good guidance available on MSDN covering this topic;
When Project Server 2013 or Project Online is in Project permission mode, you can explicitly grant or deny access to the OData feed for specified Project Web App users. For example, on the Edit User page in Project Web App, expand the Global Permissions section, and then in the General section, select the Access Project Server Reporting Service check box in the Allow column.
In the default SharePoint permission mode, not all Project Web App users have access to the OData feed. Only users in the following groups have access: Portfolio Viewers, Portfolio Managers, and Administrators
Source: https://msdn.microsoft.com/en-us/library/office/jj163015.aspx
So basically if using Project Permission mode then this is what you’re after (preferably from Edit Group, not edit user as MSDN suggests):
Unfortunately as above article goes on to mention there is no granularity to the access, it is all or nothing so if you’re looking for the kind of flexibility that the cubes previously gave then unfortunately you’re out of luck!
What has this got to do with Apps?
OData and the REST Api’s used in CSOM / JSOM are closely related, and in the case of Project Apps that need to work with project data such as Bulk Edit, then we need to also grant access to “Use Remote Interfaces” in SharePoint, to do that you will need to check the Permission Levels configuration: Site Settings -> Site Permissions -> Permission Levels -> Edit
By default the Project Managers SharePoint Group has this already, so if for example you want to grant all Project Managers in PWA permissions to run Bulk Edit, then all you need to do is add the Project Server Global reporting permission above, and combined with the SharePoint permissions they will be able to edit all project information.
What if I want Granularity?
I’m not good a saying “no it can’t be done” :) so if you require reporting granularity then the solution would be to use the SSIS reporting to create your own local SQL replica where your DBAs can apply whatever permissions are required. Reason 999 why that SSIS solution is key to any deployment in the future!
How about Apps? The picture is a little better but at the same time less simple, REST is security trimmed, so a PM will by default only be able to update / modify the project to which he / she has permissions, great. However as Apps can leverage both OData and REST endpoints which work differently it may result in inconsistencies depending on how the App was designed, for example:
Bulk Edit (at the time of writing) will allow Read Access to all Projects as a minimum, BUT will only allow updates to projects that to which the user has the rights.
If you’re wondering about any other app, then these simple rules apply:
- Writing data always requires REST – allows security trimmed granularity.
- Reading sometimes requires OData – does not allow granularity.
I expect in the future this to change, from experience project server security has been a moving target since the very beginning, so perhaps we’ll see more granularity in the future.
Hope that helps someone out there..
