Editing TeamPulse Advanced Project Settings

Project Settings Elements

The settings below are used to define the rules for features, stories, bugs, issues, risks and tasks. In case the logged in user has the "EditProjectSettings" permission, these settings can be modified from the Project Settings page.

To edit a project's advanced settings go to Settings -> Projects -> Your Project -> Advanced Settings

There:

1. Use the textbox containing XML to modify the project settings.
   • An alternative approach would be to copy and paste the XML into an XML editor (such as Visual Studio).  When finished, paste the XML back into the textbox.
   • For more information about the XML, see the following blog post:
     http://blogs.telerik.com/teampulse/posts/10-08-10/project_templates_in_teampulse.aspx
2. When finished, click the Save button to save your settings to the database.
   • If there are any validation errors, they will be displayed to the right of the textbox. 

All element names, attribute names, and values are case-sensitive.  If your project is syncing with a TFS project then please pay particular attention to the case of the status names as they must match exactly with the states defined in TFS.

The following section describes each element of the project settings XML in detail. 

SynchronizationSettings

• This element is only used to set the AutoSyncNewEntities attribute to true or false.  This attribute controls the default value of the Sync with TFS checkbox.
  

  <SynchronizationSettings AutoSyncNewEntities="true" />
  

• For more information, see the section entitled: Choosing What to Synchronize .

Tracking

• This element defines some of the reporting settings used in Iteration Status and People Status screens.
• Instead of editing these values directly in the XML, it is recommended to use the Reporting tab in the project settings.
• For more information, see the section entitled: Reporting Settings .

EntityDefinitions

• This element contains the definitions for all the entities in TeamPulse which includes Feature, Story, Task, Bug, Issue, Risk, and Feedback.
• The only valid child element of EntityDefinitions is <EntityDefinition> .
• You should not add any new EntityDefinition elements.
• You should not remove any of the existing EntityDefinition elements.

EntityDefinition

• This element defines a variety of settings for a TeamPulse entity type which includes the workflow, rules, and UI settings.
• Workflow
  • Statuses
    • This element contains a list of all the possible statuses an entity can have.
    • Status names are case-sensitive and must not have any leading or trailing spaces.
    • The only valid child elements of the Statuses element are <string> elements.
    • For project synced with TFS it is important the statuses in TeamPusle to match the statuses in TFS. Read more about  How Statuses Are Synced .

  • Transitions
    • This element is used to define the statuses an entity can be moved to given its current status.
    • The only valid child elements of the Transitions element are <Transition> elements.
    • Each Transition element must contain a From attribute and a To attribute and the values must be one of the statuses from the Statuses list.
    • There must be exactly one Transition element whose “From” attribute is empty as this defines the initial status of the entity.

  • Status groups
    • As part of the workflow element there are a number of status groups.  These groups are used to make a difference between the work that is not started, in progress and completed. This is required when create reports and analyze data. Also, it is helpful when visualize projects with different names of the statuses.
    • UnexecutedStatuses - Comma separated list of statuses that are considered to mean that work on an item has not yet started.
    • InProgressStatuses - Comma separated list of statuses that are considered to mean that work on an item has started but is not yet completed.
    • DoneStatuses - Comma separated list of statuses that are considered to mean that work on an item has been completed.
    • ExcludedStatuses - Comma separated list of statuses that are considered to mean that an item should be ignored because it is no longer in scope or will otherwise never be worked on.

• Rules
  • Rules can be used to change the behavior of an entity including default values, list of values, and validation.  They are described in more detail in the Rules section below.

• FieldColorMappings
  • Field color mappings are used in a number of places in the UI to highlight certain values.
  • These mappings are most often used with fields that also use an allowed values list such as the severity field on bugs.
  • Use the FieldName attribute to specify the field to apply the color mapping to.
  • Use a <ValueToColorMapping> element with Color and Value attributes to choose a color for a specific value.
  • Colors should be specified using a six digit hexadecimal code preceded by the # sign (i.e. #FF9900).

• SeverityValueToPrioritizationPrefixMappings
  • These mappings are used to calculate the default sequence number that will be set when marking a bug as triaged or marking an issue or risk as assessed.
  • If the list of allowed values for the severity field for bugs, issues, or risks is changed, these mappings will also need to be changed.
  • The lower the prefix, the higher (more important) the default sequence number will be.

Rules

This section describes the rules available to entities in TeamPulse. 

Required Rule

• A field can be marked as required to ensure that it always has a value.
• Use the FieldName attribute to specify which field to apply this rule to.
• Example:
  
  < Rule xsi:type = "RequiredRule" IsActive = "true" IsValidationRule = "true" FieldName = "Name" />

Default Value Rule

• A field can be given a default value using a default value rule.
• Use the FieldName attribute to specify which field to apply the default value to.
• Use the DefaultValue attribute to specify the default value.
• Example:
     
  < Rule xsi:type = "DefaultValueRule" IsActive = "true" IsValidationRule = "false" FieldName = "FeedbackType" DefaultValue = "Feedback" />

Allowed Values Rule

• A field can be restricted to a specific list of values by using an allowed values rule.
• Use the FieldName attribute to specify which field the list of values is for.
• Use the AllowNull attribute to specify whether or not the field can be empty.
• Use a child element named <AllowedValues> to specify the actual list of values.
• Example:
  
  < Rule xsi:type = "AllowedValuesRule" IsActive = "true" IsValidationRule = "true" FieldName = "FeedbackType" AllowNull = "false" >

     < AllowedValues >

       < string >Idea</ string >

       < string >Feedback</ string >

       < string >Feature Request</ string >

     </ AllowedValues >

  </ Rule >

Match Rule

• A field can be validated against a regular expression by using a match rule.
• Use the FieldName attribute to specify which field to validate using this rule.
• Use the Pattern attribute to specify the regular expression to use.
• Use the Description attribute to provide some text for the validation message in the event the data entered by the user does not match the pattern.
• Example:
  
  < Rule xsi:type = "MatchRule" IsActive = "true" Pattern = "^\d*$" Description = "an integer value representing the percentage estimated likelihood that the risk will occur." FieldName = "Probability" />

The following table presents a list of which rules are supported by each field in each TeamPulse entity.

Feature

Story

Task

Bug

Risk

Issue

Feedback