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 | 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..
by Martin Laukkanen | Aug 25, 2014 | Apps, Development
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).
Issue
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.
draftProject.set_startDate("2013-12-31 09:00:00.000");
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.
Worse still:
- 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!
by Martin Laukkanen | Jul 25, 2014 | Apps, SharePoint 2013, Troubleshooting
Recently while working with a colleague we came across a few easy to miss issues when configuring the App Management Service in a SharePoint farm and while troubleshooting those issues found a lack of online resources on what turned out to be super-simple issues to resolve. (Hindsight is great)
Issue 1: ‘Let’s try this again’ error installing from the App Store
After installing and configuring the services, app domain and catalog as required, we could now open the SharePoint App Store, and choose an app to install, however the following message was displayed and the installation of any App would never begin.
Error text: Everything is fine, but we had a small problem getting your license. Please go back to the SharePoint Store to get this app again and you won’t be charged for it.
Everything’s fine hey? Looking at the ULS revealed that this was caused by security:
w3wp.exe (0x0CA0) 0x1DF4 SharePoint Foundation App Marketplace High An exception was thrown while trying to import the app license. AppName:Bulk Edit; Exception:System.UnauthorizedAccessException: You don’t have the right to perform this operation. at Microsoft.SharePoint.SPAppLicenseManager.ImportLicense …
w3wp.exe (0x0CA0) 0x1DF4 SharePoint Foundation App Marketplace High Post app license acquisition did not result in a successful license import. HugState:Retry
But how can this be, we’re testing using the Farm Admin account and so we have all permissions! It turns out, that is actually the problem! While I can’t say specifically where / what setting causes this, in a typical SharePoint 2013 install the Farm Admin (/ Installer account) is intentionally restricted in certain ways, my guess is something to do with local computer policies or such.
Solution
Login using a user account (who can be Site Collection Admin and all that)!
Yay my favourite app!
Issue 2: App installs without issue but does not work
Now we have our first app installed, however running it doesn’t quite work out. Unfortunately this time we get very little indication of the problem, in fact with Bulk Edit the app will start and look good, except nothing works! The buttons do nothing, and no data is displayed! :(
Similar issues happen with other apps installed and without looking at the F12 browser debug console the only indication that there is a problem is the top right hand corner site icon image which is just a little ‘x’.
If you do debug you will see an error like this:
SCRIPT5009: ‘RegisterSod’ is undefined
File: Default.aspx, Line: 14, Column: 32
Basically that tells me as a developer that something is seriously wrong in the farm (SP.js is missing which the whole JSOM api requires)!
Cause & Solution
Fortunately the solution was simple: SP.js was actually missing! Well not exactly, as it turns out while we had provisioned a single PWA site collection at /PWA in our Web App, we had not actually created a Default Root site collection at ‘/’. This configuration actually can break lots of things including SSRS and so this comes as no surprise really.
Simply creating a root site collection (using Blank or any template) fixed the issue and now all apps work as normal.
Other potential issues
While possible the topic of another rather long post, here’s a list of other things to check if you get permissions issues trying to install apps (sorry this is from memory so pls comment below if you think any of this has changed):
Hope that helps someone else out there!
by Martin Laukkanen | May 3, 2014 | Apps, ID
One of the most common things I get asked by customers is how can they assign a unique project number to projects in Project Server, it does seem strange that there is no out-of-the-box way to do it but now there’s an App for it!
Check out Nearbaseline ID available now in the SharePoint App store.
