Customization Feedback

Coordinator
Jan 16, 2008 at 4:09 PM
Please post all feedback on this solution starter here, not deployement issues.
Jan 18, 2008 at 10:55 PM
Great to see the many changes. I haven't yet run this code, but it looks like it could use the same SSL detection as the original code. If I'm off base and this routine isn't used in this code, my apologies. I'll try this project out in the next couple weeks.

update AutoStatusing\UpdateStatus.cs WSUrl method to
private string WSUrl(SPSite ss, string hostName, string sspName, string wsName, bool impersonate)
{
string ssHostName = ss.HostName;
if (hostName.Length > 0) ssHostName = hostName;
if (impersonate)
{
if ((ss.Protocol.ToLower()) == "https:")
return string.Format("{0}//{1}:56738/{2}/psi/{3}.asmx",ss.Protocol, ss.HostName, sspName, wsName);
else
return string.Format("{0}//{1}:56737/{2}/psi/{3}.asmx", ss.Protocol, ssHostName, sspName, wsName);
}
else
return string.Format("{0}/vtibin/psi/{1}.asmx", ss.Url, wsName);
}


hope this helps...
James Fraser
Apr 25, 2008 at 2:22 PM
Unhandled scenario
When a resource (ResOne) saves a timesheet the timesheet event handler inserts a row in the tsAutostatus table. This row contains the UserName which is fetched from contextInfo.UserName in Event.cs.

Above is fine but what you have to have in mind (or maybe change the code for) is when the timesheetmanager (tsmgrOne) rejects the timesheet saved by resOne and edits the timesheet and then saves the timesheet another row is inserted with tsmgrOne as the userName.

This all ends up in a 401 - error when the TSAutostatus service picks up the job and tries to impersonate tsmgrOne and update task for resource resOne!

If this happens - edit the userName value in the row in tsAutostatus table to resOne and the processing will succeed.
Jul 15, 2008 at 10:54 PM

Looks like a good day for our customers with the July 15th Project Server 2007 Infrastructure Update. The remaining work addition is a huge help to the problems of the dual timesheets/my tasks updating.

Does the timesheet tied mode code support this? If not (I'd be surprised if it did already) will that be incorporated soon?


Thanks...
James Fraser
Coordinator
Aug 14, 2008 at 5:57 PM
Yes it does James
Aug 15, 2008 at 11:21 AM
Edited Aug 28, 2008 at 3:25 PM

Don't know how to delete this comment?

 

Oct 2, 2008 at 9:10 PM
I'm still investigating the details, but it looks like the handler doesn't deal with situations where a Timesheet entry is zeroed out or deleted. In these cases, it looks like the time is not updated in the My Tasks section. Manually importing the timesheet does bring the change over.

I'm just checking if anyone has thoughts before I go looking into the code.


James Fraser
Oct 6, 2008 at 10:29 AM
Hi,

FYI Our Current Version- Prior latest MS Project Infrastructure Update (Still in testing)

I would like to inform users that the daily restriction of hours is not tied into the add-on. We currently have a limit of 24 billable hrs on any given day in our Project Server Settings, due to the odd project support task that requires this. Although if a resource books more, lets say 30 hrs and then saves the timesheet, the 30 hrs is presented as a task-update to the Project Owner via the Add-on bi-passing this server settings.
Linking this to James comment above, and despite the efforts of the project resource the 30hrs will not be amended unless the timesheet is reimported. to "My Tasks".

Is there a way to update the code to consider this Project Server Setting for restricting the hours to, as per our example 24hrs or other.

Or

Has the Infrastructure update effectively allowed the Add-on to process multiple changes/saves without the need to reimport the timesheet to ensure an on flow of this data to Task Updates.

Regards

Ryan Martini
Nov 6, 2008 at 6:11 PM

The current version doesn't seem to support Administrator adjustments to timesheets:

Administrators can go into the Approvals-> Timesheet section and adjust timesheet entries. These timesheets are added to the tsAutoStatus table, but with the id of the administrator. So impersonation does not have permission to update the My Tasks page and import the timesheet.

The fix that we've implemented: We are running the following SQL script hourly to update the userName to the owner of the timesheet, not the administrator. I haven't looked in the code for it, but there might be a quick fix there as well.

Hope this helps someone...
James Fraser


UPDATE dbo.tsAutoStatus
SET userName = (SELECT mer.ResourceNTAccount
                FROM dbo.MSP_Timesheet ts
                INNER JOIN
                dbo.MSP_TimesheetResource tr
                ON tr.ResourceNameUID = ts.OwnerResourceNameUID
                INNER JOIN
                dbo.MSP_EpmResource mer
                ON tr.ResourceUID = mer.ResourceUID
                WHERE tsAutoStatus.tsGuid = ts.TimesheetUID)
WHERE dateprocessed IS NULL
 AND EXISTS (SELECT mer.ResourceNTAccount
                FROM dbo.MSP_Timesheet ts
                INNER JOIN
                dbo.MSP_TimesheetResource tr
                ON tr.ResourceNameUID = ts.OwnerResourceNameUID
                INNER JOIN
                dbo.MSP_EpmResource mer
                ON tr.ResourceUID = mer.ResourceUID
                WHERE tsAutoStatus.tsGuid = ts.TimesheetUID)
               

Jan 6, 2009 at 6:45 AM
Hi All/jbfraser

Did you ever find out the solution to your problem - I am having the same problem and before I go ahead and implement the script i am trying to find if there is a coding solution?

Thanks in advance,

Doug
Jan 7, 2009 at 6:48 PM
All,
We have implemented the code and it has been working fine for 2 months.  Now for several users, their Time Imports are failing.  Reviewing the code, the following is indicated in  Microsoft.EPM.TSAutoStatus:  
#region STEP 4 - Import Timesheet, will get an error if TS period is not within the Task's Start & Finish.  

This appears to mean that updates will fail if a user starts a task early or if additional hours are logged for a task with a finish date prior to a Timesheet Period date.  Both of these conditions are common in all organizations. Is there a reason for this restriction and is there a way to remove it?
Jan 9, 2009 at 12:46 AM
All,

This is the solution we are implementing at a client site - instead of a scheduled sql update statement as above we have modified the storec proc "tsAddTimesheet" that comes with this solution to incorporate the change as follows:



IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tsAddTimesheet]') AND type in (N'P', N'PC'))
BEGIN
EXEC dbo.sp_executesql @statement = N'-- =============================================
-- Author:  Mike Shughrue
-- Create date: 12/21/07
-- Description: 
-- =============================================
CREATE PROCEDURE [dbo].[tsAddTimesheet]
 @siteGuid uniqueidentifier,
 @tsGuid uniqueidentifier,
 @lcid nvarchar(50),
 @userName nvarchar(50)
AS
BEGIN
 DELETE FROM [dbo].[tsAutoStatus]
 WHERE [tsGuid] = @tsGuid
 AND [dateProcessed] is null

/*
 INSERT INTO [dbo].[tsAutoStatus]
      ([siteGuid]
      ,[tsGuid]
      ,[lcid]
      ,[userName])
   VALUES
      (@siteGuid
      ,@tsGuid
      ,@lcid
      ,@userName)
*/

-- change starts here

DECLARE @NTUserName NVARCHAR(50)
SET @NTUserName =
 (
 SELECT TOP (1) MSP_EpmResource.ResourceNTAccount
 FROM MSP_Timesheet INNER JOIN
 MSP_TimesheetResource ON MSP_TimesheetResource.ResourceNameUID = MSP_Timesheet.OwnerResourceNameUID
 INNER JOIN MSP_EpmResource ON MSP_TimesheetResource.ResourceUID = MSP_EpmResource.ResourceUID
 INNER JOIN taAutoStatus ON MSP_Timesheet.TimesheetUID = @tsGuid
 )
 
 INSERT INTO [dbo].[tsAutoStatus]
      ([siteGuid]
      ,[tsGuid]
      ,[lcid]
      ,[userName])
   VALUES
      (@siteGuid
      ,@tsGuid
      ,@lcid
      ,@NTUserName) 

-- end change

END
'
END

Jan 13, 2009 at 6:28 PM

DouglasKamp,

Thanks for the code change. I implemented it today in an instance.

I think you've got a minor error in your code. The corrected code is below:


IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tsAddTimesheet]') AND type in (N'P', N'PC'))
BEGIN
EXEC dbo.sp_executesql @statement = N'-- =============================================
-- Author:  Mike Shughrue
-- Create date: 12/21/07
-- Description: 
-- =============================================
CREATE PROCEDURE [dbo].[tsAddTimesheet]
 @siteGuid uniqueidentifier,
 @tsGuid uniqueidentifier,
 @lcid nvarchar(50),
 @userName nvarchar(50)
AS
BEGIN
 DELETE FROM [dbo].[tsAutoStatus]
 WHERE [tsGuid] = @tsGuid
 AND [dateProcessed] is null

/*
 INSERT INTO [dbo].[tsAutoStatus]
      ([siteGuid]
      ,[tsGuid]
      ,[lcid]
      ,[userName])
   VALUES
      (@siteGuid
      ,@tsGuid
      ,@lcid
      ,@userName)
*/

-- change starts here

DECLARE @NTUserName NVARCHAR(50)
SET @NTUserName =
 (
 SELECT TOP (1) MSP_EpmResource.ResourceNTAccount
 FROM MSP_Timesheet INNER JOIN
 MSP_TimesheetResource ON MSP_TimesheetResource.ResourceNameUID = MSP_Timesheet.OwnerResourceNameUID
 INNER JOIN MSP_EpmResource ON MSP_TimesheetResource.ResourceUID = MSP_EpmResource.ResourceUID
 WHERE MSP_Timesheet.TimesheetUID = @tsGuid
-- THE ABOVE LINE WAS CHANGED FROM THE EARLIER POST!
 )
 
 INSERT INTO [dbo].[tsAutoStatus]
      ([siteGuid]
      ,[tsGuid]
      ,[lcid]
      ,[userName])
   VALUES
      (@siteGuid
      ,@tsGuid
      ,@lcid
      ,@NTUserName) 

-- end change

END
'
END

Feb 17, 2009 at 8:12 PM

Has anyone seen this, and better yet, have any ideas for a fix?
We have seen a frequent problem with the imports:
When users correct their timesheets to delete or zero out previously entered hours, the Timesheet Import run by this service does not pick up the change. Subsequent changes can be made to the timesheet, and the timesheet is added to the tsAutoStatus queue/table. Other changes are imported successfully, but not the removal of hours.

A manual import of the Timesheet works fine in these cases.

Looking at the code, the problem looks like it's in the PSI, not in the codeplex code:
UpdateStatus.cs has this line:
statusing.ImportTimesheet(tspUID);
It's a call to the PSI and there isn't much code around this. Since the other lines are getting imported, this must be getting called, so it looks like the 0 time should get imported...

We would really like to get this solved: I'm open to any suggestions...


James Fraser
Feb 18, 2009 at 3:57 PM

We looked into the problem I mentioned yesterday in more detail. It looks like the zero updates are going through to the My Tasks, but aren't getting submitted as a status update. There's more meat in the codeplex solution code here, and I think we found the problem (see http://www.codeplex.com/EPMTSST/Thread/View.aspx?ThreadId=18488 ) The obvious problem we are now investigating is the performance penalty if we remove the requirement for actuals to be greater than 0.

(The case where the updates weren't making it to the My Tasks was because of another improper line in the Timesheet.)


James Fraser