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. …
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.
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.
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
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..
An update to ConfigTool is now available on the App Store.
v126.96.36.199 is ready to install for everyone.
- Language support improvements
- Bug Fixes
Open site contents in PWA to find the update link in the usual place:
I came across this while working with a customer and quickly found that the error triggers a known issue in my Bulk Edit app as well which was causing some unexpected errors using the app for some people, however this is a broader issue as it causes basic OData feeds to fail completely with the following message: Error message accessing /_api/ProjectData/Projects
<?xml version="1.0" encoding="UTF-8"?>
<m:message xml:lang="en-US">An error occurred while processing this request.</m:message>
The problem can happen both on-prem or online but if you have access to the ULS logs you will see the following log entries (showing only the interesting bits):
Project Server Database agxfb Exception [bucketHash:7C60C52B] SqlException occurred in DAL (ProjectWebApp@NB): Class 16, state 1, line 1, number 8156, procedure , error code -2146232060, exception: System.Data.SqlClient.SqlException (0x80131904): The column ‘Campaignstatus’ was specified multiple times for ‘OdataSelect’. Project Server OData abljj High [Forced due to logging gap, Original Level: Verbose] PWA:http://nb/PWA, ServiceApp:Project Server Service Application, User:i:0#.w|blah\ml, PSI: Exception encountered when trying to instantiante the OdataResultItemCollection
As error logs go that is a pretty helpful one!
Cause – Duplicate Custom Fields
The issue is caused by the Enterprise Custom Field configuration of the Project Server, specifically to looks like there are some duplicate named fields (Campaignstatus in my error above), now of course that is of course not possible! However when you look at the OData feed you can see that a few things happen:
- Spaces are removed from field names; so e.g. Campaign Status becomes CampaignStatus, etc.
- Duplicate named fields (after space removal) are numbered, so for example you may see CampaignStatus1.
However there is a bug, OData is case-sensitive while SQL is not. So in my example above it seems that there are two fields the same name but with different cases, specifically I have the following two fields configured: Campaign Status and Campaignstatus. In my case if the second field was named CampaignStatus then this issue would not occur as it would have a number appended in the feed! (While this might sound a little esoteric actually I’ve already seen this a couple of times in German PWA instances where words are typically conjugated, etc)
- Rename the aforementioned field to something completely different (e.g.; Campaignstatus2), or
- Recreate the field with different Case, e.g. in my example if I recreated the field Campaignstatus as CampaignStatus.
Note; renaming a field to a different case does not work(!), you need to recreate the field in order to regenerate the correct ‘cased’ Odata name.
Hopefully this bug will be fixed in a future service pack, but for now in Bulk Edit at least I have implemented a workaround anyway.
A new version of Bulk Edit is available from the App store, check your site settings for the upgrade link now to install it.
- Project Owner Field editing support
- Loading never finishes in some cases
- Loading of projects is incomplete errors occur in the F12 script console
Open site contents in PWA to find the update link:
Finally if you use and love Bulk Edit, please rate it in the App Store!
I’ve written many times before about working with projects using the JSOM and CSOM API’s, and this is another issue in the API that I’ve had to resolve for one of my apps (in this case Bulk Edit).
When updating built in fields (I haven’t observed this for custom fields) using the client side library (JSOM or CSOM or REST) in the normal way the following error can be reported in the queue unexpectedly:
CICONotCheckedOut: CICONotCheckedOut (10102). Details: id=’10102′ name=’CICONotCheckedOut’ uid=’a2da51ea-792b-e411-9af1-00155d908811′.
Queue: GeneralQueueJobFailed (26000) – ProjectUpdate.FailIfNotCheckedOutMessage. …
For example the following code from the MSDN article on this topic will intermittently get the above error:
// Get the target project and then check it out. The checkOut function
// returns the draft version of the project.
var project = projects.getById(targetGuid);
var draftProject = project.checkOut();
// Set the new property value and then publish the project.
// Specify "true" to also check the project in.
var publishJob = draftProject.publish(true);
// Register the job that you want to run on the server and specify the
// timeout duration and callback function.
projContext.waitForQueueAsync(publishJob, 10, QueueJobSent);
This is despite the fact that we are obviously doing the check-out of the project in line 4.
- The update will still work for most fields (like Status Date but NOT for Project Owner), despite the error indicating otherwise!
- The error is not consistent, some updates work without an error.
Cause and Solution
Turns out the issue is one due to the asynchronous nature of the client side libraries, specifically it looks like when performing the “waitForQueueAsync” we are actually requesting four things:
- Check out Project
- Update project value (start date above)
- Publish Project
- Check project back in
However it seems that steps 2 and 4 don’t quite run in the correct order! Changing line 10 as follows to NOT check-in after publishing results in a successful update and no error:
var publishJob = draftProject.publish(false);
Then we need to add a separate checkIn() call AFTER the completion of the publish (IE in the callback function ‘QueueJobSent‘ above) and then call waitForQueueAsync again.
Looks like a bug although perhaps not as it is important to keep in mind that the queued async jobs are not guaranteed to be done in the correct order although clearly it usually happens in the order expected.
BTW, Yes expect an update for Bulk Edit supporting more built-in fields soon!