Handling of Deleted Assignments, Closed Work Items and Rejected Work Item Changes

Mar 27, 2008 at 3:34 AM

I'm new in using the PS2007 TFS connector and would like to find out how the connector handles:

1) Deleted tasks/assignments from PS2007 - After trying out deleting one of the tasks in project from MS Project and then published, it seems that the task association is gone, but the initially associated work item remain as active. How is the connector designed to handle deleted PS2007 tasks?
2) Rejected task updates - when updates on work items from TFS gets to PS2007 and are rejected by the Project Manager, it seems that it is not communicated back to TFS, and the work items are not reverted back to the original state before the update. Only after re-publishing the project from PS2007, these work items are updated to the original state. Is this supposed to be the way the connector handles rejection of updates?
3) Closing of work items - How is the change of status of TFS work items from "Active" to "Closed" get propagated to PS2007?

Thank you.
Mar 27, 2008 at 6:50 PM
1) Work Items cannot be deleted so the Connector takes this logic in addition to removing the association (which you noted):
    • move the work item to a Deleted Work Items Area Path if it exists. This Area Path can be secured so that 'regular contributors' are not even allowed read access; thereby, giving the illusion that the WI has been deleted.
    • change the synchronization status to Deleted if the synchronization state field exists for the process template
If neither of those conditions can be met, the Connector doesnt do anything else with the WI.
2) The Synchronization State should be set to Denied by EPM for the work item; however, I think there is a bug with this in the latest release that I am currently investigating. It is by design that no other changes occur to the WI until the project is published -- a published project reflects the 'true' state of the assignments (and therefore the work items)
3) Only 'mapped fields' as defined by the configuration within the web service are propagated to PS and back. To propagate changes to the System.State field, this would need to be added to that configuration.

Mar 28, 2008 at 3:20 AM
H Lenny,

Thank you for your reply.

Forgive my ignorance, but could you clarify what are Synchronization State and System.State fields mentioned here? I only know from the bloghttp://blogs.msdn.com/lfenster/archive/2007/07/05/getting-started-with-the-connector.aspx the mappings between the Enteprise WorkItem Types within Project Server and the TFS WorkItem Types and the "AutoSync to External System" custom field created by the connector in PS2007.
Mar 28, 2008 at 3:33 PM
System.State is the actual name of the field that holds the value for "Active", "Closed", Resolved", etc. SynchronizationState is a field that the Connector adds and is the whole reason for the custom process templates. These fields hold the current synchronization state (approvedbytpm, deniedbytpm, approvedbyepm, deniedbyepm, etc.)

The Connector allows you to map any fields you want to synchronize with Project Server. So if you wanted the "Active", "Closed", etc (the System.State) to show up as a field within Project Server you can add that mapping to the Conenctor configuration.

Make sense?