The script can be downloaded from the Microsoft Script Gallery below:
jquery-2.1.1.min.js – jQuery download
Another version of this library may work but this was the one I used / tested with.
Upload this library to your PWA site collection then update the script file with the correct location. I uploaded this file to the site assets library as you can see in the code below:
Once the script has been downloaded you will notice that I have used 6 default project level fields and 2 custom fields. The two custom fields are Programme and RAGPMStatus. These can be seen on the select below:
Programme and RAGPMStatus are custom to my test environment but I added these to show that default and custom project level fields can easily be added. To get the script to work you can either add these fields to your configuration – probably fine for a test environment, or modify the script to remove the custom fields or add your own. Here I will assume you want to add 2 of your own project level custom fields. Below are parts of the script that will need to be modified to accept your own 2 project level custom fields. For simplicity we will assume that the two new fields are Project Location and Project RAG. Project RAG is associated to a lookup table with the following 3 values: Green, Amber, Red.
Starting from the top of the script file here are all the places you will need to modify to get the two new fields in the code.
- In the table, update the two column headers, replace Programme with Project Location and replace RAG Status with Project RAG.
- Update the select query, replace Programme with ProjectLocation and replace RAGPMStatus with ProjectRAG.
- On the first if statement replace Programme with ProjectLocation and replace RAGPMStatus with ProjectRAG.
- In the data table processing section, replace Programme with ProjectLocation and replace RAGPMStatus with ProjectRAG for the aoColumns parameter
- In the data table processing section for the aoColumnDefs parameter update the fnCreatedCell if statement with the correct lookup table values for the Project RAG field. So in this example replace On schedule [Green] with Green and Slipping but can mitigate [Amber] with Amber. You might also want to change the cell and font colors.
Once updated, add the script to your PWA site collection, I uploaded this to the Style Library. Then add a content editor web part to the project site and reference the uploaded project information JS file. If you want this to be on all project sites then you would need to create a new project site template with the JS file added.
Once added to a project site the project information will be visible for that project:
Just a quick post to highlight a new script I have published this evening. This displays project fields on the associated project site. A full blog post will be coming soon that explains how to use the script and what would need modifying for your environment (custom fields etc.). The script can be downloaded below:
A screen shot of the output is below:
The RAG Status background colour and font colour update based on the custom field value.
While working on a client site today the client wanted to increase the input box for a single line of text field on the PDP to help when typing data / viewing what you have already typed. As the box is quite small the text at the start of the box disappears as you type. See below:
“This is a new comment in a single line of text field. As I type the text disappears from view making it difficult to review”
To get the ID, use the browser dev tools and select the correct element:
In the highlighted html you will see a property called ID, shown below in bold:
<input name="ctl00$ctl40$g_e2fda013_167b_4aa4_96c8_3c3437803054$ctl00$pfp_Repeater$ctl24$idCF_41396333-22dd-e311-9430-00155d15d1fe" title="Test Single Lint of Text" id="idCF_41396333-22dd-e311-9430-00155d15d1fe" type="text" size="50" maxlength="255" GUID="41396333-22dd-e311-9430-00155d15d1fe"/>
Copy the ID value and update the script below with the correct ID:
Add to the script to the correct PDP either using a script editor web part directly or save the js file, upload to PWA and reference the file using a content editor web part. The script will also need access to the jQuery library. Once complete you will see the wider input box:
#Odata #SQL SSIS component now available for SQL Server 2012 #ProjectOnline #SSRS #SharePointOnline #SharePoint #BIMarch 26, 2014 at 9:16 am | Posted in Add-on, Administration, Configuration, Customisation, Functionality, Information, Reporting, T-SQL | 1 Comment
Tags: Project 2013, Project Online, PS2013, SharePoint Online, SP2013, SQL, SSRS
Quick post to let you know that the SSIS component to export data via ODATA that was mentioned here is now available for download, see the link below:
This will enable you to copy data from Project Online into a custom SQL database, from there you can easily create SSRS reports, custom OLAP cubes, integrate into other LOB systems etc. Look out for more details soon.
Tags: Office 2013, PPM, Project 2013, Project Server 2013, PS2013, SharePoint 2013, SP2013
Service Pack 1 has been released today for Office 2013, the links can be seen below:
SharePoint 2013 SP1:
Project Server 2013 SP1:
Project 2013 SP1:
SharePoint 2013 and other server related SP1:
Office 2013 and related desktop products SP1:
A list of the fixes for Office 2013 SP1:
As with all patches, deploy to a non production farm and fully test before deploying to a production system.
Tags: Project Server 2013, PS2013, SharePoint 2013, SP2013, SQL, SSRS
This post covers an the details around an issue I came across the other day and I wanted to make you aware to help in your deployments / system design. The issue is with displaying SSRS Native mode reports on a SharePoint 2013 page using a page viewer web part when using IE 10 or later. Our preference and recommendation is to usually use SSRS Integrated mode but on occasions some of our clients use SSRS 2008 R2 / 2012 Native mode. This issue doesn’t exist for SSRS Integrated mode.
****** Update ************
This issue is resolved by updating the document mode for the ReportViewer.aspx pages, updating this from <meta http-equiv=”X-UA-Compatible” content=”IE=5″> to <meta http-equiv=”X-UA-Compatible” content=”IE=8″> or later did resolve this issue for us. The file can be found on the report server in the following location: C:\Program Files\Microsoft SQL Server\MSRSx.InstanceName\Reporting Services\ReportServer\Pages. Please note, this will impact all the reports on that report server so test on a test server before a production server.
The issue is that the SSRS reports are not displayed correctly on the page, they are truncated:
Other standards-compliant browsers are ok, Chrome is:
IE 8 and 9 also work fine.
The page viewer web part with SSRS Native reports worked fine in SharePoint 2010 in any browser.
I have tested with the SSRS Report viewer web part (the 2008 R2 version as the SQL 2012 version doesn’t deploy to SharePoint 2013) from the RSWebParts.cab file, this has the same issue.
One of our devs had a quick look at this and it stated it was because the web part uses a table that is 3 cells wide. 2 of the cells are related to the document map while the 3rd contains the report itself. The document map cells are hidden by default.
In older versions of IE, a hidden cell in a table counted towards with width of the table, this was against the standard. Now with more standards compliant browsers, hidden cells do not count towards the width of the table.
This means that the report cell is the only cell defined for the row, so the browser forces it into the left most cell space. The end result of this is the SSRS report is truncated to the right as that is the limit of the size of that column.
So the answer going forward if your client wants to embed SSRS reports in SharePoint 2013 pages and they use IE, recommend (and use) SSRS 2012 Integrated mode.
Tags: Project 2013, Project Server 2013, PS2013, SharePoint 2013, SP2013
I have seen this issue a few times now in Project Server 2013 where users see the error “View Failure The view failed to load. Press OK to reload this view with the default settings. Press Cancel to select another view”
Clicking OK gives another error: “You don’t have permissions to view any projects”
This isn’t the case in this example.
There are two scenarios that I know of that cause this particular issue, these are described below:
Note: My farm is in the Project Server permission mode.
For an existing user:
• Log in as User A, access the Project Center, access “View A” – all works great
• Change the permissions so that User A no longer has access to “View A” or delete “View A”
• Log in as User A, access the Project Center, User A will see the View failed to load error
For a new user – never accessed the farm before:
• Prevent access to the default Project Center “Summary” view for the Team Members Group but allow access to other Project Center views
• Create a new user (User B) that is only in the Team Members Group
• Log in as User B (a new user on the farm), access the Project Center, User B will see the View failed to load error
The ULS logs gives the following error:
Error is: GeneralSecurityAccessDenied. Details: User does not have permission to this view. . Standard Information: PSI Entry Point: Project User: i:0#.w|support\userb Correlation Id: 2f5e74c7-c751-e311-9419-00155d15d154 PWA Site URL: http://vm753/PWA SA Name: ProjectServer PSError: GeneralSecurityAccessDenied (20010), LogLevelManager Warning-ulsID:0x347A6230 has no entities explicitly specified. ea70589c-4f64-e059-ef52-a016cf63c1ed
InitViewReportInfo ViewUid:63d3499e-df27-401c-af58-ebb9607beae8 is not found. ea70589c-4f64-e059-ef52-a016cf63c1ed
The remote command PWAProjectGetProjectCenterProjectsForGridJsonRemoteCommand encountered an unexpected exception. ea70589c-4f64-e059-ef52-a016cf63c1ed
If you have removed the default Project Center Summary view, either removed access to it or deleted it (new user scenario), or removed any other Project Center views that users may have accessed last (existing user scenario), the known workaround at this point is as follows. Click the Projects Tab, select a view from the view menu then refresh the page. At this point the view will load and the Project Center will continue to load successfully.
When upgrading #ProjectServer #PS2010 to #PS2013, consider any custom project site templates #SP2013 #SharePointNovember 19, 2013 at 9:48 am | Posted in Administration, Configuration, Customisation, Functionality, Information, Installation, PowerShell, Upgrade | 3 Comments
Tags: Project 2013, Project Server 2013, PS2013, SharePoint 2013, SP2013
I have seen this posted quite often on the Project Server forums so I thought I would write a quick blog post.
When upgrading from Project Server 2010 to Project Server 2013, you will need to recreate the customised Project Site templates. Project Server 2013 doesn’t recognise the Project Server 2010 project site templates. Project Server 2013 project sites now have a template name / ID of PROJECTSITE#0, Project Server 2010 project sites use PWS#0. This can be seen below:
When recreating the new site template in 2013, start with the “Project Site” template on the Collaboration tab found on the new SharePoint site page.
Should I display duration fields on the #ProjectServer PDPs? #PS2010 #PS2013 #SP2010 #SP2013 #SharePoint #ProjectOnline #MSProjectNovember 12, 2013 at 10:11 am | Posted in Administration, Configuration, Customisation, Functionality, Information | 1 Comment
Tags: Project 2010, Project 2013, Project Online, Project Server 2010, Project Server 2013, PS2010, PS2013, SharePoint 2010, SharePoint 2013, SP2010, SP2013
The answer to this question in my opinion is no. In this blog post I will explain why using an example.
Firstly I have created a new test duration field on my test Project Server 2013 environment, this is called _duration.
For the purpose of this post, I also have a new Project Detail Page (PDP) that only displays the _duration field. A new project is created, the schedule it not important here, just the value you specify in the _duration field. As you can see below, I have entered 10 days:
Save and publish this to Project Server and take a look at the project in PWA. You can see the project in PWA as shown below:
Notice the _duration field correctly shows the 10 days.
Notice the _duration field correctly shows the 10 days.
All ok at this point. Before we move on, I just want to show the project options for this project, specifically the hours per day:
Notice this is set to the default 8 hours per day. Update this to 7 hours per day. You will then notice that the _duration field correctly updates to 11.43 days:
Reset this back to 10 days then save and publish the project again.
The Project Center still display 10 days in the _duration field:
The PDP will show the incorrect duration in the _duration field:
The PDP’s assume the default 8 hours per day is used for each project. At this point the PM will probably think, lets correct the 8.75 days to 10 days. So lets do this, this is now correct in the PDP:
Great. Not quite, now take a look in the Project Center:
Notice the 11.43 days. Also check the Project Information in Project:
I was aware of this issue in Project Server 2010 but only just came across the same thing in Project Server 2013.
Hopefully that explains why I answered “no” to displaying duration fields on the Project Server PDP’s, it will save a lot of confusion with your Project Managers! As with all answers there is normally an exception to the rule and you can probably guess what that is. Displaying duration fields on PDP’s will be fine if your projects are 8 hour days
#ProjectServer #PS2013 #Project Site permission sync clarification #SP2013 #SharePoint #ProjectOnlineNovember 5, 2013 at 3:30 pm | Posted in Administration, Configuration, Functionality, Information | 5 Comments
Tags: Project 2013, Project Online, Project Server 2013, PS2013, SharePoint 2013, SP2013
**** Update ***
There has been a change to the project site user sync since 2013 was released, see the post from Brian below that explains the change and the change that is coming: http://blogs.technet.com/b/projectsupport/archive/2015/02/03/project-server-2013-project-now-controls-the-visitors-group-on-project-sites.aspx
Just a quick post to make you aware of a design change in the Project Server 2013 project site sync when in Project Server permission mode. The only issue is that you may find project team members without assignments are granted edit access to the associated project site rather than read access – this is now by design.
In Project Server 2010 if a user / resource was added to the project team but not assigned to any tasks they were added to the Readers (Microsoft Project Server) SharePoint group on the associated project site. This is different in Project Server 2013, when the users / resources are added to the project team but not assigned to tasks they are added to the Team Members (Project Web App Synchronized) SharePoint group rather than an equivalent Readers (Microsoft Project Web App) group. This is working as designed as there are now only two SharePoint groups on the Project Sites used in the permission sync:
Project Managers (Project Web App Synchronized)
Users who have published this project or who have Save Project permission in Microsoft Project Web App.
Team Members (Project Web App Synchronized)
Users who have assignments in this project in Microsoft Project Web App.
This could be misleading if you used 2010 and also if you view the SharePoint permission level descriptions. The Project Server 2013 Project Site permission levels can be seen below:
The “Readers (Microsoft Project Web App)” states “Users who have been added to this project in Microsoft Project Web App, but not assigned to tasks.”
Also the “Team Members (Project Web App Synchronized)” SharePoint group permission description is not quite accurate as it should states that it also includes project team members without assignments:
“Users who have assignments in this project in Microsoft Project Web App”
Hope that helps.