Tuesday, July 9, 2013

#ProjectServer2013 Timeline issue

New project created
PWA Schedule timeline Phases shown in timeline


Project Published
SPSite Timeline seen to be a match for PWA schedule Timeline

Task #3 – Managing and controlling is deleted (with all its subtasks)

Initial view of PWA Schedule timeline is incorrect (I will forgive this one)

Publish plan and switch between PDPs and eventually the timeline displays correctly

Note the three remaining PHASE tasks
Now switch to the SPSite Timeline….

Notice the new task on the timeline now (making 4)
I have also seen other events where tasks are deleted from the plan, but yet remain in the Project Site Task List (and timeline) so are therefore orphaned, although I haven’t yet managed to repro this particular event

*FIXED* #ProjectServer2013 bug? - cannot close in progress timesheet periods

Timesheet periods cannot be closed "bug"(?):


The following has been repro'd on 
- an Project Server 2013 (RTM) - next step is June CU
- project online

- Create a number of resources/users
- Set up timesheet periods
- Test 1: TS periods can be closed
- Create a timesheet (one user)
- Save timesheet
- Test 2: Close timehseet period (same period as timesheet created in) = Result - TS period cannot be closed 

Note:  you can also note a javascript error in IE at line 1409.  When you look at the source code, this appears to point to a page with the URL /pwa/_Layouts/15/pwa/admin/PeriodCloseConfirmation.aspx
Now I don't know if this is a legacy page or not, but if you navigate to this page you see this (which is exactly what I want to see when closing a period)

So what this means if this means is:- if you are running timesheets it is impossible to exempt some users from timesheets submission as periods wont be able to be closed!! 

Another fail in this is that the Timesheet Status flag is extremely unreliable. I have seen many examples where a timesheet returns to 0 State (not submitted) event when it is approved. This will also trigger this failure to close timesheet periods.

It's my belief that this is not by design behavior due to the existence of this page, which suggests it is an override to allow periods to be closed:

Friday, July 5, 2013

#ProjectServer2010 PWA Provisioned With Errors (no ProjectBICenter provisioned)

Here's a repeated scenario that I thought I'd write up quickly:

On a new environment (2010 SP1 + June 2011 CU V2) I provisioned the first PWA site in the Farm.  Unfortunately the site provisioned but with errors, the errors being that the ProjectBICenter did not get created.

I worked through the usual ULS log entries and found a number of records relating to:

- Unable to create Images library due to content type "document" already exists

The fix for this as far as I can tell:
- Open STSADM and run

         stsadm -o deleteweb -url http://pwaaddress/projectbicenter

- Navigate to the PWA site and create a new subsite 
-- Using BI Center template
-- Named Business intelligence center
-- URL /ProjectBICenter

- now go to the Project Server Service App
-- Select the pulldown menu and select EDIT
-- Click EDIT to reforce provisioning

This should now complete, and in my scenario this stopped the issue happening again


Monday, July 1, 2013

#projectserver2013 Issues part 2 - Cannot close timesheet periods

#projectserver2013 Issues part 2

Following on from my previous post, here's some other tidbits of anomalies on PS2013

Close Timesheet Periods
There's an issue with page rendering and IE versions here.  When attempting to close periods, the changes cannot be saved

Javascript error on page (syntax error at line 1408)

Occurs on

The problem appears to be a page call to /pwa/_Layouts/15/pwa/admin/PeriodCloseConfirmation.aspx

I expect (unconfirmed) that the issue is because of Timesheets that have not been submitted for a period I wish to close.  However some resources do NOT complete timesheets in our configuration so this is ok.

When I looked at the code I found a call to this PeriodCloseConfirmation page which I assume is supposed to load when this event occurs, but it does not.

This looks a fairly substantial issue right now.  I'd be interested to know if anyone else sees the same thing.