none
[ProjectServer 2013] Resource authorization data lost on PSI Resource Update RRS feed

  • Question

  • Hi,

    as the title says I noticed that sometimes resource authorization data of a resource/user is lost in ProjectServer 2013 on a PSI resource update. Since it did not happen every time for every resource (user) I tried to investigate this issue in more detail. I found out that it is related to a change in the resource availabilities. A resource/user loses its resource authorization data on a UpdateResources PSI call when the following criteria are fulfilled:

    - "Earliest available" or "Latest available" date is set

    - Resource/user has more than one ResourceAvailablities row

    - Max units are changed for one of the rows

    Since this is a quite complicated and specific issue here are some simple steps to reproduce it on a PWA instance:

    1. Create new resource/user.

    2. Enter any date in the "Earliest available" field and assign the user to some security groups.

    3. Programmatically change the max. units of any ResourceAvailablityRow and update the resource via the UpdateResources PSI call.

    4. Open the user in PWA. The security group associations will not be there any more.

    I have successfully reproduced this issue on two different PWA instances on two different servers.

    Did i miss anything obvious or is this a well known issue?

    If yes are there any workarounds?

    Did anybody else run into this issue?

    Thanks in advance for you help,

    Michael


    • Edited by W_Michael Thursday, April 16, 2015 3:15 PM formatting
    Thursday, April 16, 2015 2:54 PM

All replies

  • Can you make a Fiddler trace? Without knowing what you have sent to PSI its a bit hard to track down what the problem might be. On my end it is working without any problem on Project Server 2013 March 2015 CU.
    Friday, April 17, 2015 8:02 AM
  • I created a Fiddler trace (see link at the end of the post) but i could not find anything suspicious in there.

    If it helps here is the code that i use to reproduce the issue:

    var singleResDs = resourceClient.ReadResource(resUid);
    
    var maxUnitsRow = singleResDs.ResourceAvailabilities.First();
    maxUnitsRow.RES_AVAIL_UNITS = maxUnitsRow.RES_AVAIL_UNITS + 1;
    
    resourceClient.CheckOutResources(new Guid[] { resUid });
    resourceClient.UpdateResources(singleResDs, false, false);
    resourceClient.CheckInResources(new Guid[] { resUid }, false);

    As you can see there is nothing special about it.

    I also checked the patch level on one of the servers and its 15.0.4569.1506 which corresponds to SP1 (April 2014). I can definitely try to install the newest CU and check if that fixes the issue.

    Fiddler trace:

    http://bit.ly/1DvaWsZ

    EDIT:

    I have now installed the March 2015 CU (15.0.4701.1001) and the issue is still existing.

    • Edited by W_Michael Monday, April 20, 2015 6:45 AM March 2015 CU
    Saturday, April 18, 2015 2:35 PM
  • That is very interesting, all what you send looks normal. I had a look at our code, we possible won't get the error, as we set the resource authorization data as well in the call behind with the Resource.SetResourceAuthorization() method. It maybe fixes your problem as well.

    Nevertheless it might be worth to open up a service request at Microsoft.

    I hope this helps you at least a little bit.

    Monday, April 20, 2015 10:48 AM
  • Setting the resource authorization data via a separate SetResourceAuthorization() PSI call is also the workaround that i implemented for this issue and i guess this is also what happens when updating a resource via PWA.

    But i don't think this is an acceptable workaround because if the SetResourceAuthorization() PSI call fails for some reason resource authorization data is still lost.

    I will most probably open up a service request at MS because i really want to find a fix or at least an acceptable workaround for this issue.

    Thanks a lot for your investigation/help!

    Even if you could not provide a solution it's good to know that i did not overlook a simple error on my side.

    Monday, April 20, 2015 1:27 PM
  • Indeed, it would be good if you can post here some results about the service request. Less server calls are always good :).

    Monday, April 20, 2015 3:03 PM
  • Just in case anybody had the same issue and is still following this thread:

    In the last few months Microsoft could reproduce and fix the bug. The fix will be included in the "December 2015 Public Update".

    Tuesday, November 3, 2015 12:32 PM