This restriction can be achieved by following two steps,

1. Restrict write permissions by placing users in the appropriate security groups (on project level).

2. Now you can restrict which users can perform work item state transitions by modifying the work item type definition and placing "for" and "not" attributes on the state transition. For example:

<TRANSITION from="Resolved" to="Closed" for="[Project]\Testers">

Reference - https://msdn.microsoft.com/en-us/library/ms194954(VS.80).aspx

DomainProjectPicker dpp = new DomainProjectPicker(DomainProjectPickerMode.None);

if (dpp.ShowDialog() == DialogResult.OK)

{

    try

    {

        Cursor.Current = Cursors.WaitCursor;

        tfsServer = new TeamFoundationServer(dpp.SelectedServer.Name, new UICredentialsProvider());

        tfsServer.Authenticate();

        //Connect to VersionControlServer, BuildStore or WorkItemStore.

    }

    catch (Exception ex)

    {

        //Exception handling

    }

    finally

    {

        Cursor.Current = Cursors.Default;

    }

}

 https://www.microsoft.com/downloads/details.aspx?familyid=8BDAA836-0BBA-4393-94DB-6C3C4A0C98A1&displaylang=en

Project portal configuration are defined in the WssTasks.xml file within the [Process Template]/Windows Sharepoint Services directory. Within this xml file, document libraries, folders and default files list is defined. Also the sharepoint site template name is defined.

<Portal>

        <site template="VSTS_MSF_CMMI" language="1033" />

        <documentLibraries>

            <documentLibrary name="Security" description="Documents for the architect team" />

            <documentLibrary name="Test" description="Documents for the test team" />

            …………………………………………..

        </documentLibraries>

        <folders>

            <folder documentLibrary="Test" name="Draft" />

            <folder documentLibrary="Test" name="Released" />

            <folder documentLibrary="Project Management" name="Draft" />

            <folder documentLibrary="Project Management" name="Released" />

            <folder documentLibrary="Process Guidance" name="Supporting Files/images" />

            <folder documentLibrary="Development" name="Drafts" />

            <folder documentLibrary="Development" name="Released" />

            …………………………………………..

        </folders>

        <files>

            <file target="Test Approach.doc" documentLibrary="Test" source="Windows SharePoint Services\Test\Test Approach.doc" />

            <file target="Draft/MGSI Acceptance Test Plan.doc" documentLibrary="Test" source="Wss\Templates\MGSI Acceptance Test Plan.doc" />

            <file target="Draft/MGSI System Test Plan.doc" documentLibrary="Test" source="Wss\Templates\MGSI System Test Plan.doc" />

            <file target="Draft/Development Project Plan.mpp" documentLibrary="Project Management" source="Wss\Templates\Development Project Plan.mpp" />

            …………………………………………..

        </files>

</Portal>

Groups and Permissions XML

List of groups and their permissions within process templates are defined within the GroupsandPermissions.xml file located within [Process Template]/Groups and Permissions directory. For the MGSI SDC Process template we have added four new groups.

<groups>

           <group name="Project Managers" description="Members of this group can add, modify, and delete items within the team project.">

                           <permissions>

                                           <permission name="GENERIC_READ" class="PROJECT" allow="true" />

                                           <permission name="GENERIC_READ" class="CSS_NODE" allow="true" />

                                           <permission name="GENERIC_WRITE" class="PROJECT" allow="true" />

                                           <permission name="GENERIC_WRITE" class="CSS_NODE" allow="true" />

                                           <permission name="WORK_ITEM_READ" class="CSS_NODE" allow="true" />

                                           <permission name="PUBLISH_TEST_RESULTS" class="PROJECT" allow="true" />

                                           <permission name="WORK_ITEM_WRITE" class="CSS_NODE" allow="true" />

                                           <permission name="START_BUILD" class="PROJECT" allow="true" />

                     </permissions>

  </group>

                ……………………………………………………

                ……………………………………………………

</groups>

References

1.       CodePlex – Visual Studio Team System: Process Templates and Tools. https://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx

2.       MSDN – Customizing Process Template

https://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx

3.       Visual Studio 2005 Team Foundation Server Power Tools
https://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx

4.       Customizing Microsoft Project Field Mappings

https://msdn2.microsoft.com/en-us/library/ms404684(VS.80).aspx

Iterations and Areas

Classification files are located within [Process Template]/Classification directory. Iterations for the project are defined within ProjectLifeCycle node and project areas are defined within ProjectModelHierarchy node.

 <tasks>

            <task id="UploadStructure" name="Creating project structure" plugin="Microsoft.ProjectCreationWizard.Classification" completionMessage="Team project structure created.">

                    <taskXml>

                            <Nodes>

                                            <Node StructureType="ProjectLifecycle" Name="Iteration">

                                                            <Children>

                                                                            <Node StructureType="ProjectLifecycle" Name="Iteration 0" />

                                                                             <Node StructureType="ProjectLifecycle" Name="Iteration 1" />

                                                                            <Node StructureType="ProjectLifecycle" Name="Iteration 2" />

                                                            </Children>

                                            </Node>

                                            <Node StructureType="ProjectModelHierarchy" Name="Area">

                                                            <Children>

                                                                            <Node StructureType="ProjectModelHierarchy" Name="Area 0" />

                                                                            <Node StructureType="ProjectModelHierarchy" Name="Area 1" />

                                                                            <Node StructureType="ProjectModelHierarchy" Name="Area 2" />

                                                            </Children>

                                            </Node>

                            </Nodes>

                            <properties>

                                            <property name="MSPROJ" value="Classification\FieldMapping.xml" isFile="true" />

                            </properties>

                    </taskXml>

            </task>

</tasks>

MS Project Field Mappings

These values define how the values stored in TFS are translated when exporting work items to and from Microsoft Project.

Mapping between MS project columns and work item type fields is defined by the FieldMapping.xml file. This file is located within [Process Template]/Classification directory.

<MSProject>

            <Mappings>

                            <Mapping WorkItemTrackingFieldReferenceName="System.Id" ProjectField="pjTaskText10" ProjectName="Work Item ID" />

                            <Mapping WorkItemTrackingFieldReferenceName="System.Title" ProjectField="pjTaskName" />

                            <Mapping WorkItemTrackingFieldReferenceName="System.WorkItemType" ProjectField="pjTaskText24" />

                            <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.Discipline" ProjectField="pjTaskText17" />

                            ……………………………………………….

                            ……………………………………………….

                            <ContextField WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.TaskHierarchy" />

                            <LinksField ProjectField="pjTaskText26" />

                            <SyncField ProjectField="pjTaskText25" />

            </Mappings>

</MSProject>

Work Items Type

Team members use work items to track work to be done within TFS. Team members can create a new work item based on a default work item type such as bug, requirement, risk, or task. Each Process Template comes with a set of default work item types, which depends on the installed methodology, such as MSF for CMMI Process Improvement or MSF for Agile Software Development. A work item type is a template from which new work items of that type are created.

Work Item type xml files are located within [Process Template]/WorkItem Tracking/TypeDefinations directory. Each work item will have its own XML file, named as [WorkItem name].xml

Work item type xml can be divided into three major sections – Fields, Workflow and Layout

1.       Fields

This section consists of list of all fields which are defined within this work item type. Each field tag will encapsulate all rules defined for that particular field.

<FIELDS>

<FIELD type="Integer" name="Id" refname="System.Id" />

  <FIELD type="String" name="Title" refname="System.Title">

       <HELPTEXT>Short description of the bug used to differentiate it in a list or report</HELPTEXT>

       <REQUIRED />

  </FIELD>

  <FIELD type="String" name="Assigned To" refname="System.AssignedTo">

       <HELPTEXT>The person assigned to act on the bug, either to fix it or to verify the fix</HELPTEXT>

       <VALIDUSER />

  </FIELD>

<FIELD type="TreePath" name="Area Path" refname="System.AreaPath">

       <HELPTEXT>The area of the product with which this bug is associated</HELPTEXT>

  </FIELD>

<FIELD type="TreePath" name="Iteration Path" refname="System.IterationPath">

       <HELPTEXT>The iteration of the product with which this bug is associated</HELPTEXT>

  </FIELD>

………………………………

………………………………

</FIELDS>

2.       Workflow

Workflow section can further divided into two parts,

a.       States

This section list out all states through which work item can pass on. And each state tag will encapsulate list of fields which have to be empty or required for that particular state.

<STATE value="Resolved">

<FIELDS>

<FIELD refname="Microsoft.VSTS.Common.ClosedDate">

                <EMPTY />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ClosedBy">

<EMPTY />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ResolvedDate">

<REQUIRED />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ResolvedBy">

<REQUIRED />

</FIELD>

<FIELD refname="System.AssignedTo">

<REQUIRED />

</FIELD>

</FIELDS>

  </STATE>

b.       Transitions

This section list out all the transitions which can take place between different states. Each transition will encapsulate actions, reasons and fields.

<TRANSITION from="Active" to="Resolved">

<ACTIONS>

<ACTION value="Microsoft.VSTS.Actions.Checkin" />

 </ACTIONS>

<REASONS>

<REASON value="As Designed" />

<DEFAULTREASON value="Fixed" />

</REASONS>

<FIELDS>

<FIELD refname="Microsoft.VSTS.Common.ResolvedDate">

<SERVERDEFAULT from="clock" />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ResolvedBy">

<COPY from="currentuser" />

</FIELD>

</FIELDS>

</TRANSITION>

3.       Layout

This section defines the work item user interface, and way controls will be places in the UI. Controls are grouped and positioned using <Group> and <TabGroup> controls.

<Layout>

<Group>

<Column PercentWidth="100">

<Control FieldName="System.Title" Type="FieldControl" Label="&Title:" LabelPosition="Left" />

</Column>

     </Group>

<TabGroup>

<Tab Label="Description">

<Group>

<Column PercentWidth="100">

<Control FieldName="Microsoft.VSTS.CMMI.HowFound" Type="FieldControl" Label="&How found:" LabelPosition="Left" />

</Column>

</Group>

</Tab>

…………………………………….

…………………………………….

</TabGroup>

</Layout>

Work Item Queries

These are the queries on the work item database that are available to every project member. This initial set of queries can easily be changed once a project has begun.

Work Item query files are located within [Process Template]/WorkItem Tracking/Queries directory. Each work item query will have its own WIQ file, named as [WorkItem Query name].wiq

Contents of these query files are very much similar the way SQL queries are written. Such as test-case work item query file contents are as follows,

<WorkItemQuery Version="1">

<Wiql>

SELECT [System.Id], [System.State], [Microsoft.VSTS.Common.Priority], [System.Title] FROM WorkItems WHERE [System.TeamProject] = @project AND [System.WorkItemType] = 'TestCase' ORDER BY [System.Id]

</Wiql>

  </WorkItemQuery>

Let’s start with – What the process template means?

Process templates define key aspects of a team project that affect how a team works. By customizing a process template, we can define security for team project control, what templates are available on the project portal, source code control check-in notes, new work item types and queries, reports for monitoring and status, and which iterations and organization units are used. Process templates define the initial process settings for team projects. Most process settings can also be customized after a team project is created.

Each organization/teams already have their own project execution processes or document templates in place. So by defining their process template including those existing processes and document templates in the process template they can enforce those processes onto each project which is created within the TFS using custom process template.

So the Process templates define key aspects of a team project that affect how a team works. By customizing a process template, we can define the following security options to control your team project.

·         Define the templates that are available on the project portal.

·         Define and require source code control check-in notes.

·         Define the available work item types and queries.

·         Define reports to monitor progress and report status.

·         Define the iterations and organizational units that are used.

Constituents of Process Template

Work Item Type

A work item type is a database record which VSTF uses to track assignments and state of work. For example task, bug, risk, test case are some of the work item types.

Version Control Settings

A process template can define default settings for check-in notes, permissions for various group settings and multiple check-out.

Sharepoint site layout, theme and contents

Work products and document templates are documents such as Microsoft Word files, and Microsoft Excel files that are copied to the project portal when the new team project is created.

Process guidance is HTML content that describes the activities, roles, work items, and other parts of the process for the team.

Reports

A process template defines the default set of reports to be used by team members on the new team project.

Project areas and iterations

Project areas and iterations are used to facilitate work item queries and reports for grouping. They allow the team to query for work items that just affect a particular area of the project, or a particular iteration.

Customizing Process Template

The best way to start the process template customization is to start with an existing process template. We downloaded and started with the MSF for CMMI process template and started its customization. There are two ways to customize the process template,

1.       Use the VSTS Process Editor (which is part of VSTF Power Tools).

2.       Directly modify various process template XML files. (I will explain more about these XML files in the Part 2 of this series.)

Introduction to VSTS Process Editor

The Process Editor provides a convenient method of viewing and customizing process templates. The Process Editor can work in two modes: Connected and Disconnected. In Connected mode, the Process Editor interacts with Team Foundation server, enabling us to interact with the items in an existing project on the server.

Download and Upload a Process Template

To edit a process template, download it from Team Foundation server, edit it with the Process Editor or directly modifying template XML files, and then upload it. Uploading the new template will only affect the way future projects will be initialized on the server, and will have no effect on any of the existing project on the server.

Download a process template

1.       Connect to TFS.

2.       In Visual Studio, select from top menu - Team > Team Foundation Server Settings > Process Template Manager.

3.       In the Process Template Manager dialog box, select a process template.

4.       Click Download and save the template locally.

Now after modifying the process template, upload the new process template using the following steps.

Upload a process template

1.       Connect to TFS.

2.       In Visual Studio, select from top menu - Team > Team Foundation Server Settings > Process Template Manager.

3.       In the Process Template Manager dialog box, click Upload and navigate to the folder containing the ProcessTemplate.xml file.

4.       Uploading the template to the TFS server takes some time from couple of minutes to half an hour, depending on the location and configuration of TFS server.

What's New in Microsoft Office Outlook 2003 for Developers?

 An Introduction to Programming Outlook 2003 Using C#

Programming samples that can reference items and folders in Outlook by using Visual C# .NET

How to retrieve specific messages by using the Find method and the Restrict method in Visual C#

How to automate Outlook and Word by using Visual C# .NET to create a pre-populated e-mail message that can be edited

How to build an Office COM add-in by using Visual C# .NET