none
Publish Timesheet Only - Project Server 2010 RRS feed

  • Question

  • I would like to allow users to manage their timesheets without directly accessing the Project Server 2010 Project Web App.  The Technet documentation (e.g. - http://technet.microsoft.com/en-us/library/gg314584(v=office.14).aspx) seems promising, but I have not been successful in implementing my idea scenario.  Here is what I have tried:

    • Add the "My Timesheet" web part to a page in a site collection that is in a different web application [http://publicSite/default.aspx] from the PWA [http://internalSite/PWA] even with both in the same SharePoint 2010 farm (Fail).  When I enter the Project Web App URL in the web app configuration, it does not get flagged as an invalid URL (so it seems to recognize it as a valid PWA).  However, I receive the error: "Cannot communicate with the server.  Verify your connection and try again."  I suppose this is related to the security between web applications.  However, this would be an ideal scenario for me to provide the maximum separation between the users who are entering their time and the other sensitive data that is found in the PWA. 
    • Add the "My Timesheet" web part to a page in a site collection [http://internalSite/default.aspx] that is in the same web application as the PWA [http://internalSite/PWA] (not ideal, but tolerable).  The web app displays and functions normally (the same as you would expect from the out-of-the-box PWA "Timesheet" page.  However, the "Period" controls in the ribbon cause the page to be redirected to the PWA [http://internalSite/PWA/Timesheet.aspx] just to change the period for the timesheet.  This is a basic feature that I would think should be able to be accomplished without redirecting the page, but that is not how it is implemented.  I have seen http://social.technet.microsoft.com/Forums/projectserver/en-US/af1a5b83-94df-4ef9-953f-3bd25a4d4ace/my-timesheet-webpart that indicates that this is simply not an out-of-the-box feature, but this is disappointing, since it seems that changing the period is just as fundamental as saving, sending, submitting the timesheet (all of which can be done without a redirect). 

    My questions:

    • Am I missing something that would allow the "My Timesheet" web part to change periods without redirecting to the PWA\Timesheet.aspx page?
    • Is there anything I'm missing that might allow me to publish a timesheet without user interaction with the PWA at all (my ideal scenario)?
    Thursday, August 29, 2013 4:38 PM

All replies

  • Hi trellistnick --

    Why are you trying to avoid accessing the timesheet via PWA? If you are trying to avoid paying for user licenses, then you are out of luck. MSFT's policy states that if you are accessing live data from Project Server -- regardless of the interface -- then you are still responsible for the licenses.

    If you want to change or simplify the interface, then you may be able to do that within the boundaries of PWA... depending upon what you are trying to accomplish.

    If you want to expose the timesheets in an area where users spend more of their time (i.e. in another area / portal) therefore making it more convenient for them, then this may require some custom development to override some of the built-in functionality (i.e. redirects back to PWA) or simply develop a new timesheet web part.

    -- tz


    Tony Zink | Vice President, EPMA | http://www.epmainc.com | Blog: http://www.epmablog.com | Training: http://www.epmainstitute.com

    Thursday, August 29, 2013 5:05 PM
  • It is definitely not an issue of licensing - it is a matter of security.  I would like to provide the timesheet web part in a site with a different, more restricted security profile than the PWA. 

    It seems as though a custom web part that inherits the "My Timesheet" web part may be the way to go - I was just checking for alternatives before going that route. 

    Thanks. 

    Thursday, August 29, 2013 5:08 PM
  • More restricted security profile? Can you please explain?

    Project Server has a security model that is based on groups and categories that control access to system functions and data at a very granular level. Does the Project Server security model not meet your needs?

    -- tz


    Tony Zink | Vice President, EPMA | http://www.epmainc.com | Blog: http://www.epmablog.com | Training: http://www.epmainstitute.com

    Thursday, August 29, 2013 5:36 PM
  • It's not the security model of Project Server with which I have an issue - it's the vulnerability associated with publishing (via a firewall like UAG) and making accessible the PWA in a less-secure zone than a trusted zone like an intranet (which is where I assume most instances of Project Server reside).  I would prefer to be able to publish a site with a page that has web parts making web service calls to the PWA rather than publishing the PWA itself (which seems to be my only option at this point).  In my view, publishing that separate site that uses only web parts would make the PWA itself (and all of the sensitive data housed therein) less vulnerable to intrusion from that less-secure zone. 

    Perhaps I am being overly-cautious or my expectations are not set correctly.  I welcome input on this. 

    Thanks. 

    Thursday, August 29, 2013 5:51 PM