tfsaggregator / tfsaggregator

A server side plugin for Team Foundation Server (TFS) and Azure DevOps Server for performing various Work Item related calculations, create new Work Items and Links automatically.

Deprecation notice

Azure DevOps Server is deprecating the old work item APIs. They are likely not going to be removed any time soon, but we can't keep supporting this plugin version forever.

Our recomendation is to migrate to aggregator-cli which can now be hosted on Azure Functions or in Docker.

We won't do any major investment in this Plugin version and our bandwidth for support is limited.

This server side plugin, for TFS 2013 update 2 up to TFS 2018.3 and Azure DevOps Server 2019, 2020, 2022 up to 2022.0.1 and 2022.1 enables running custom script when Work Items change, allowing dynamic calculation of field values in TFS and more. (For example: Dev work + Test Work = Total Work).

Documentation

The complete documentation is available on the project's Documentation Site.

Changelog

What's new in v2.7

• Adds support for Azure DevOps Server 2022 RC1, RC2, and RTW, 2022.0.1 RC, 2022.0.1.

What's new in v2.6

• Adds support for Azure DevOps Server 2020 beta, RC and RTW, 2020.1, 2020.1.1, 2020.0.1.
• Adds support for Azure DevOps Server 2022.1 RC1

What's new in v2.5

• Adds support for Azure DevOps Server 2019.0, 2019.0.1, 2019.1RC1, 2019.1RC1, 2019.1
• Adds support for TFS 2018.2 and 2018.3

What's new in v2.4

• Added support for TFS 2015.4.1
• Added support for TFS 2017.0.1
• Added support for TFS 2017.1
• Added support for TFS 2017.2
• Added support for TFS 2017.3
• Added support for TFS 2017.3.1
• Added support for TFS 2018
• Added support for TFS 2018.1 RC
• Added support for TFS 2018.1
• Added support for TFS 2018.2
• Fixes TemplateScope in TFS 2017 update 2 and higher
• Added text to installer explaining the 2017u2 version works with 2017u3 as well
• Added text to installer explaining the 2018 version works with 2018u1 as well
• Reading and removal of Work item Links self.WorkItemLinks self.RemoveWorkItemLink
• Global List editing with AddItemToGlobalList and RemoveItemFromGlobalList
• Startup logging controlled by configuration file
• New code layout, contributors are urged to read Source Code
• Support for work-item-deleted event

What's new in v2.2

• Support for TFS 2017
• Macro snippets and Functions for Rules and make code more modular
• Ability to specify server URL
• Support for multiple workitem Ids in Console application (issue #178)
• Ability to Send email from Rules
• Migrated CI build from AppVeyor to VSTS
• Use of GitVersion to manage Semantic Versioning

What's new in v2.1.1

• Fixes important bug causing very high CPU usage (see #160).

What's new in v2.1

• Support for TFS 2015.2, TFS 2015.2.1 and TFS 2015.3
• Extended logging in debug version
• Ability to override base Uri of the aggregator
• Improvements in the setup
• Adds PreviousRevision/NextRevision properties to Work Items to navigate history
• Adds Uri field to Work Items
• Removed policyscope on Workitem template GUID and revision (didn't work anyway)

What's new in v2

• A 'real' Scripting language (C#, VB, Powershell)
• Scoping allows select which rules apply to which Team Project
• Enhanced filtering to trigger rules when conditions are met
• Console application to quickly test new rules
• Richer logging
• Test harness and modularity to ease adding new features
• Create new Work Items and Links using rules
• and more...

Example Uses

• Update the state of a Bug, PBI (or any parent) to "In Progress" when a child gets moved to "In Progress"
• Update the state of a Bug, PBI (or any parent) to "Done" when all children get moved to "Done" or "Removed"
• Update the "Work Remaining" on a Bug, PBI, etc with the sum of all the Task's "Work Remaining".
• Update the "Work Remaining" on a Sprint with the sum of all the "Work Remaining" of its grandchildren (i.e. tasks of the PBIs and Bugs in the Sprint).
• Sum up totals on a single work item (i.e. Dev Estimate + Test Estimate = Total Estimate)
• Create new work items
• Create new work item links

Contributing to the Project

Please read the Contributing document.

tfsaggregator's Issues

Extend the Object Model with basic navigation and tracking

Extend the Object Model exposed to Script engines to account for basic navigation and tracking

Aggregate remaining work to parent issue - decreasing!

Hi,

I followed the sample for a simple rollup.

_self.Parent["Custom.RemainingWork"] = (double)self.Parent["Custom.RemainingWork"] + (double)self["Microsoft.VSTS.Scheduling.RemainingWork"];

It works fine.

But the Problem is that the parent value will be increased with every change.
If the child has a value of 5, the parent value will be increased by 5.
When I change the child value from 5 to 2, the parent value will be increased be 2.
But it should be decreased with 3.

So I want to aggregate the difference from the new value to the old value and not the raw new value only.
I need to decrease the parent value also.

Could you help me please?
What can I do to achieve this goal?

thanks in advance
Martin

Cascade option for Console App

The server plugin can be triggered multiple times from a single user event (e.g. Task 6 changes parent PBI 4 which triggers a rule on its own).
To emulate this behavior, one must manually run the console app multiple times (one for work item 6 and one for 4).
This option will iterate through saved work items.

NOTE need to refactor work item Save calls in a single routine.

Setup a CI build

Setup a CI build on appveyor

Need to revisit the double epsilon on save issue

The current implementation works for the values I work with, but it may be inaccurate for large values:

http://stackoverflow.com/a/2411661/736079

Create Tips, Tricks & Pitfalls page in documentation

Tricks & Tips:

• Use HasFields to create rules for any work item type, even if the schema changes
• Efficiently fetching related work items through the Lazy query API.
• Setup the RateLimiting feature to prevent disasters
• Use Debug Viewer to see what's going on behind the scenes
• Log events from your own rules
• Use the TemplateScope to enable a given set of rules for all projects with a specific template
• Write your rules using the ReferenceName for fields, that way your rules will work on process templates in different languages (and are more likely to survive TFS upgrades unharmed).
• If all you do is play with strings, also check out this little known feature in WIT customization. (see: https://msdn.microsoft.com/en-us/library/ff731584.aspx)

Pitfalls

• Beware of the History field. (see #65)
• Beware of cascading changes over a large number of work items (use max depth on lazy query api)
• Any field can return null, make sure to keep this in mind when casting values (see #63)
• Don't forget to setup the Eventlog
• Don't forget to give the service account permissions to change your work items (on behalf of others if you have enabled impersonation)

Need unit tests and refactoring

I grabbed this code and needed to make changes to support a customer demand. Unfortunately the original code has no unit tests and I was a little short on time to clean the mess up.

Now that it works (enough for my initial needs), I really should go back through the code, clean it up, add tests and get things in ship-shape condition.

Unsafe double comparison in Divide rule can trigger infinite loop

The divide rule does a double division and then compares it to the previous value. When a difference is detected, the work item is flagged for saving.

Either due to TFS doing rounding on double values for storage or teh double value comparison going wrong due to differences in precision, this comparison sometimes fails (e.g. 20/35) causing the aggregator to keep flagging the field as changed.

The code causing the issue is in:
https://github.com/rbanks54/TFSAggregator/blob/master/TFSAggregator/Aggregator.cs :60

I suggest either using a safer double comparison method (with a maximum precision) or by setting a desired precision on the different numeric rules.

Update Appveyor build script to pull references for TFS2013 and TFS2015

@giuliov can you update the build script to build both TFS 2013 and TFS 2105 packages?

The build now also needs to restore two reference packages, the TFS2013 client and server object model and the TFS 2015 server object model.

• Configurations to build: Debug-2013, Debug-2015, Release-2013, Release-2015
• Platform to build: Any CPU
• upload references for TFS 2015
• unpack 2013 references to "references\2013" instead of "references"
• unpack 2015 references to "references\2015"

TFS 2015 support | Implemented, needs testing

Testing everything works on 2015

Multiple Executions Causes Kanban Board Issues

First, thanks for a great plugin--doing a lot of great things with it.

I just setup a fairly complex set of operations to calculate development cycle times during transitions on user stories. About 75% of the time, when I transition a story via the kanban wall, the Aggregator runs once and everything continues to work perfectly. About 25% of the time when I transition a story on the kanban wall the aggregator runs twice. It happens every time I change any data through TFS Aggregator using C# scripting. Now, this doesn't cause a data problem or anything like that, but what it does cause is a strange reaction on the Kanban. Every time after I see aggregation run twice in my DebugView the next transition attempt will fail (silently) exactly once. Then on further attempt it works correctly. This isn't tied to any single transition or anything I can find a pattern to, it appears to happen randomly. It is definitely reproducible. Please see my next comment with a video of the failure.

It isn't really a breaking issue, but it is aggravating my team because it fails so frequently that they have to pay careful attention on the kanban board. This issue does not appear to happen if I transition via the form view. Once I found how to reproduce the issue it DOES happen in the form view as well as Kanban board.

Any help is greatly appreciated--I'm not able to make heads or tails of why it would run twice sometimes or why that would affect kanban transitions only.

Console app for testing

Add a simple Console app to help admins testing configurations

Support quick hierarchy querying for: All children under node and All leaf nodes under node

Useful for Roll-ups

Refactor RuntimeContext to provide access to services

Instead of the WorkItem Repository holding on to a TfsProjectCollection and a WorkItemStore, the EventProcessor fetching services from the TFSProjectCollection directly and a few other places around that I find creepy, I suggest we refactor access to TFS internals into the runtimeConext.

Same with the ILogEvents, move access to that to the RunTimeContext as well. that way there is always one way to easily gain access to these services.

I also would like to add a pre-save event somewhere before a workitem is saved, preferably throuh the context as well, or on the IWorkItemRepository. That way it's easier to inject the rate limiter.

Compatibility with TFS 2015 update 1

Microsoft has made a few breaking changes, requiring us to solve these issues if we need to support it:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/10/13/breaking-change-in-tfs-2015-update-1-for-server-side-plugins.aspx

Breaking interfaces:

• TeamFoundationRequestContext -> IVssRequestContext
• TeamFoundationServiceHost -> IVssServiceHost
• ITeamFoundationService -> IVssFrameworkService
• DeploymentServiceHost -> IVssDeploymentServiceHost

Todo:

• Add new solution configurations
• Create zip file for dependent assemblies
• Update build definition
• Update solution to use these new interfaces

Split Plugin+Job

Wouldn't it be nice if we could use actual math to write the Numeric expressions?

I've been looking at alternatives to support mathematical expressions in the TFS Aggregator and it looks like this is the best one out there, since it supports all the standard operations and it has support for last-minute resolving of variables using a delegate.

That would allow us to have the user query the value of any field as part of their math.

Not sure yet how well this library deals with dates and timespans, but so far I haven't had much use of those.

http://ncalc.codeplex.com/

"TF30063: You are not authorized to access URL"

While trying to implement this solution on our TFS Server, every run of the TFS Aggregator spits out this error: "TFSAggregator: Exception encountered processing Work Item [######]: TF30063: You are not authorized to access https://tfs.abcde.com/tfs/DefaultCollection."

It does this irrespective of which credentials are passed in by the aggregatoritems.xml. I tried this without credentials, and with numerous other sets, including our root TFSservice user to no effect.

I'm still pretty sure that I'm doing something wrong, but not sure what it could be. I have the rest of the Stack Trace handy if it would be beneficial.

Enhance logging

Enhance logging to include native TFS logging, critical errors in EventLog

Setup & Install Section has broken link

Setup & Install Section has broken link.
Should be: https://github.com/tfsaggregator/tfsaggregator/releases/download/2.0.22-master/tfsaggregator-2.0.22-master.zip

Cycles and infinite loop check

We could drop a context Guid in the comments of a save action and check the history to see if the last save was done using the same Guid. Or a custom field if people want to keep the history clean.

See https://social.msdn.microsoft.com/Forums/vstudio/en-US/36e4bfbb-fd93-4ea8-b0f9-945d2cdc682d/workitemchangedevent-is-work-item-already-written-to-database?forum=tfsworkitemtracking for some scenario.

V2 rules engine

Hi,

I'm currently trying to make the beta plugin work with TFS 2015.

I've read the policies samples files in order to get an idea on how to work with the new rules engine. However, I've noticed that the most comprehensive sample, "allInOne.policies", does mix C# and VB language syntax, and I'm unable to get it work properly. Is it supposed to work as is ?

Best regards.

Implement ITeamfoundationRequestFilter to allow us to create a NotificationPoint and roll back changes

See: https://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.framework.server.iteamfoundationrequestfilter_methods.aspx

By catching, parsing and updating the REST, WebAccess and SOAP message for Work Item Save we may be able to provide a NotificationPoint option.

If one of child WITs dont have field than is need to be changing - no one will be saved

For example:

<rule name="CopyProduct"
      appliesTo="User Story; Product backlog Item; Technical Story; Bug">
   <![CDATA[
    if (self.HasChildren())
    {
      foreach (var child in self.Children)
        {
            child["Custom.Product"] = self["Custom.Product"];
        }
    }
    ]]>
 </rule>

If one of child WITs have not Custom.Product - aggregator will not save all scope of child WITs

Sorry for bad english :(

Sum rule does not work when parent field is empty.

Rule

<rule name="Original_Estimate_Calc"
appliesTo="*">
 <![CDATA[
 if (self.HasParent())
 {
self.Parent["Microsoft.VSTS.Scheduling.OriginalEstimate"] = (double)self.Parent["Microsoft.VSTS.Scheduling.OriginalEstimate"] +(double)self["Microsoft.VSTS.Scheduling.OriginalEstimate"];
}
 ]]>
</rule> 

Dont work when (double)self.Parent["Microsoft.VSTS.Scheduling.OriginalEstimate"] is empty (WI have just been created)

Create integration test framework

Right now most unit tests rely heavily on the Mock implementation. A few bugs turned out to be issues where the mock did something slightly different than the real thing.

I'd love there to be an integration test project which does:

• destroy all work items in the project(s)
• allow us to create a number of work items
• apply a number of changes
• run a specific rule or ruleset
• validate the expected outcome of the rule
• cleans up the mess the test just created

I'd like this to

• use the infrastructure of the Console application, so that we don't have to deploy the TFS Aggregator to the server (that way we could even test against VSO).
• not rely on existing work items, but always creates the work items needed for the test
• use pre-created team projects with a specific process template installed
• use pre-defined users, teams, groups, iterations and areas (could use the ScrumRobot from Richard Hundhausen to set those up).

It doesn't have to:

• Create the team projects each time (takes too long and is a brittle process)
• transform the process template on the fly (though that would be nice and could steal from WitMorph)
• be independent on the TFS version to run the tests against.

Add a doc page with design internals

Add a [design] page with the internals of the tool

Can't Process Multiple Rules

I assume this is just something I'm not understanding, but I just added a second rule to my policy file and whenever I have more than one rule in the file I get errors. The first rule takes two fields (probability and impact) and finds bug severity in a matrix and writes the string to a field--fairly straightforward and WORKS when it is the only rule in the file.

If I comment out the bug severity rule and run the second rule, which just sums three separate effort fields into the StoryPoints field, then it works as well.

However, when I turn both rules on (see the XML below) I get the following error:

The body of that error says:
A field definition MyCompany.Agile.Lean.BugProbability in the work item type definition file does not exist

I know it exists because, first I can see it in my Bug.xml, and second this error doesn't occur with either of the single rules in place and both separately work as expected. It is almost like the second rule is somehow executing the first rule because the User Story item type does not have the aforementioned BugProbability field.

Am I missing something syntactically here? Thanks for your help.

<?xml version="1.0" encoding="utf-8"?>
<AggregatorConfiguration>

  <runtime>
      <logging level="Diagnostic"/>
  </runtime>

  <rule name="CalcBugSeverity" appliesTo="Bug"><![CDATA[ 
      System.String Probability = (System.String)self["MyCompany.Agile.Lean.BugProbability"];      
      System.String Impact = (System.String)self["MyCompany.Agile.Lean.BugImpact"]; 

      if( Probability != null && Impact != null )
      {          
          int ProbInt = int.Parse( Probability[0].ToString() ) - 1;
          int ImpactInt = int.Parse( Impact[0].ToString() ) - 1;

          string[,] Matrix = new string[5, 5]
          {
            {"Low", "Low", "Low", "Medium", "Medium"},
            {"Low", "Low", "Medium", "Medium", "High"},
            {"Low", "Medium", "Medium", "High", "High"},
            {"Medium", "Medium", "High", "High", "Critical"},
            {"Medium", "High", "High", "Critical", "Critical"}
          };

          System.Diagnostics.Debug.WriteLine("TFSAggregator: Set bug severity to " + Matrix[ProbInt,ImpactInt]);
          self["MyCompany.Agile.Lean.BugSeverity"] = Matrix[ProbInt,ImpactInt];
      }
      else
      {
          System.Diagnostics.Debug.WriteLine("TFSAggregator: Nothing to do here...");
      }
    ]]></rule>


  <rule name="CalcTotalEffort" appliesTo="UserStory"><![CDATA[                  
      System.Diagnostics.Debug.WriteLine("TFSAggregator: Update Story Points Field (Total Effort)");
      self["Microsoft.VSTS.Scheduling.StoryPoints"] = (double)self["MyCompany.Agile.Lean.DevEffort"] + (double)self["MyCompany.Agile.Lean.QAEffort"] + (double)self["MyCompany.Agile.Lean.BAEffort"];
    ]]></rule>


  <policy name="DefaultPolicy">
    <projectScope projects="Agile Test Project" />
    <ruleRef name="CalcBugSeverity" />
    <ruleRef name="CalcTotalEffort" />
  </policy>

</AggregatorConfiguration>

Use "On behalf of" connections

Current configuration uses the identity of the AT to connect to the Team project. Any changes are stored under the AT's account. It would be great if the Aggregator were able to supply the original identity and connect on behalf of.

The original identity information is available in the Context object passed to the ISubscriber.ProcessEvent method so this should not be a huge step to supply these to the TfsTeamProjectCollectionFactory upon connecting.

This option will cause reconnections for each new identity, so we might as well make it optional for performance reasons.

Writing to History field causes infinite loop

Hello,
writing anything to History causes that Aggregator's modification triggers a new Aggregator's modification.
TFS Express 2013 Update 4
Aggregator 2.0 beta 4 (https://github.com/tfsaggregator/tfsaggregator/releases/download/2.0.71/tfsaggregator-2.0.71-master-Release-2013.zip)

Add this single line to a rule
self.Fields["History"].Value = "Hello";

Ensure that AddNewWorkItem checks for the correct link types and extend error handling

Currently the code

        public void AddWorkItemLink(IWorkItemExposed destination, string linkTypeName)
        {
            var destLinkType = this.workItem.Store.WorkItemLinkTypes
                .FirstOrDefault(t => t.ForwardEnd.Name == linkTypeName)
                .ForwardEnd;
            var relationship = new WorkItemLink(destLinkType, this.Id, destination.Id);

            // check it does not exist already
            if (!this.workItem.WorkItemLinks.Contains(relationship))
            {
                this.Logger.AddingWorkItemLink(this.Id, destLinkType, destination.Id);
                this.workItem.WorkItemLinks.Add(relationship);
            }
            else
            {
                this.Logger.WorkItemLinkAlreadyExists(this.Id, destLinkType, destination.Id);
            }
        }

Only checks case-sensitive on the forward-end link name. Plus the examples use the LinkTypeEndImmutableName, except the code above doesn't look at the immutableName, only at the name. Plus it doesn't look for the reverseend.

This code needs to be extended to:

• check for the reverse-end
• check both the immutablename as well as the current name
• throw a better exception than NullreferenceException when the link isn't found to help debug these issues

The samples need to be updates to:

• show both a sample of forward as well as reverse names
• provide guidance on which end to point the link to
• explain the order in which work items are saved.

Tagging Giulio, as this was your piece of code, I'll fix it if I have time before you do.

Add errors to WorkItem history

Add errors to ... TFS alerts? WorkItem history?

Add the save logic

Add save logic to make the plugin functionally complete

Extend the Object Model with rich navigation

Extend the Object Model with ability to navigate across most all work item link types for many levels deep, with filtering and querying abilities. Kind of enabling LINQ or WIQL or XPath to select work items.

Expose Links property on IWorkItem to allow creation of links during execution of the project

Currently it's possible to enumerate links, but not to create them

Support Powershell Get-Siblings and Get-Parent methods

Using tfs 2015

[Critical] 00.296 Exception encountered processing notification: Object refer
ence not set to an instance of an object.
Stack Trace: at Aggregator.Core.Facade.WorkItemRepository.GetWorkItem(Int32 wo
rkItemId) in C:\projects\tfsaggregator\Aggregator.Core\Facade\WorkItemRepository
.cs:line 45
at Aggregator.Core.EventProcessor.ProcessEvent(IRequestContext requestContext
, INotification notification) in C:\projects\tfsaggregator\Aggregator.Core\Event
Processor.cs:line 58
at Aggregator.ConsoleApp.RunCommand.Run(String[] remainingArguments) in C:\pr
ojects\tfsaggregator\Aggregator.ConsoleApp\RunCommand.cs:line 105

Policy:

<runtime>
    <logging level="Diagnostic"/>
    <script language="Powershell" />
</runtime>

<!-- When all Tasks are done being worked on, set the parent (Bug or PBI) to Done (unless it is Removed) -->
<rule name="AutoClose"
      appliesTo="Task">
<![CDATA[
if ($self.HasParent())
{
  if (-not $parent.State -eq 'Removed') {
          if (-not (Get-Siblings $self | where { 'Done','Removed' -notcontains $_.State })) {
                $parent.State = 'Done'
          }
  }
}
]]>

<!-- When any Tasks are In Progress set the parent (Bug or PBI) to In Progress -->
<rule name="AutoStart"
      appliesTo="Task">
  <![CDATA[
  if ($self.HasParent())
  {
          if (-not $parent.State -eq 'Removed') {
              if (Get-Siblings $self | where { 'In Progress','Ready For Test' -contains $_.State }) {
                  $parent.State = 'In Progress'
              }
          }
  }
  ]]>
</rule>

<policy name="DefaultPolicy">
    <collectionScope
        collections="*"
        />
    <ruleRef name="AutoStart" />
    <ruleRef name="AutoClose" />
</policy>

Install Instructions

Install instructions reference
TFSAggregator2.ServerPlugin.policies

However, that file does not exist anywhere.

I do see samples in the ConfigurationsForTests folder

Documentation

Currently documentation is a bit lean and we're basically relying on the docs from the codeplex project. We should move that content over to the wiki here and then update it with the new features and operations we support.

Error "Object reference not set to an instance of an object"

Hello guys,

First, I thank you all for good work.
Second, I have a issue succesfully deploy tfsaggregator to the production TFS 2013 RTM server (no update installed). I have followed your instruction at "Installation" section. Thanks to DebugView I know, that plugin si working a do some job. But results are weird.

1. when I use simple "Sum" aggregatorItem, result is always "0" in targetField regardless value in sourceField
2. when I use operation "CopyTo" like:

[AggregatorItem name="Update Priority" operation="CopyTo" operationType="Numeric" linkType="Children" linkLevel="1" workItemType="User Story" targetWorkItemType="Task"]
[TargetField name="Priority"/]
[SourceField name="Backlog Priority"/]
[/AggregatorItem]

aggregator successfully recognize that conditions for parent aggregation are met, but then it fails with error:

TFSAggregator: Exception encountered processing Work Item [3483]: Object reference not set to an instance of an object.
Stack Trace: at TFSAggregator.Aggregator.IntegerAggregation(IEnumerable`1 sourceWorkItems, IWorkItem targetWorkItem, ConfigAggregatorItem configAggregatorItem) in d:\tfsaggregator-master\tfsaggregator-master\TFSAggregator\Aggregator.cs:line 88
at TFSAggregator.EventProcessor.ProcessEvent(IRequestContext requestContext, INotification notification) in d:\tfsaggregator-master\tfsaggregator-master\TFSAggregator\EventProcessor.cs:line 181

I built tfsaggregator solution with version of TFS libraries which are on production server at a moment. Changeset is the most recent, downloaded from main site.

Any help is welcome.
Thanks.

Footnotes:

1. please delete project "https://github.com/Vaccano/TFS-Aggregator". I guess that this project is newer one (but its difficult to say), and that I am not the only one, who is confused by existence of second project.
2. Release version 0.1 from this site not function with TFS 2013 RTM (assembly mishmash, I guess its because some TFS update is required) and is pretty old. Cannot you roll out new release and maybe correct prerequisites please?

Configuration auto-refresh for TFS farms

Configuration is stored in TFVC monitored by the plugin, which refreshes the local configuration file when it changes, simplifying farm administration

Update sample scipts with proper null checks (and implement tests to check)

Current rollUp tasks assume all tasks have a parent. If not, this throws a NullReference exception.

Add HasParent and HasChildren properties on work item and extend sample scripts to handle this case properly.

Sum to parent fails for multiple fields

We have the following rule in our policy file:

    <rule name="RollupTask" appliesTo="Task">
        <![CDATA[
        if (self.HasParent())
        {
            self.Parent["Microsoft.VSTS.Scheduling.CompletedWork"] = self.Parent.Children.Sum(task => (double)task.GetField<double>("Microsoft.VSTS.Scheduling.CompletedWork", (double)0));
            self.Parent["Microsoft.VSTS.Scheduling.RemainingWork"] = self.Parent.Children.Sum(task => (double)task.GetField<double>("Microsoft.VSTS.Scheduling.RemainingWork", (double)0));
            self.Parent["Microsoft.VSTS.Scheduling.OriginalEstimate"] = self.Parent.Children.Sum(task => (double)task.GetField<double>("Microsoft.VSTS.Scheduling.OriginalEstimate", (double)0));
        }
        ]]>
    </rule>

It works fine if any single field (CompletedWork, RemainingWork or OriginalEstimate) is changed, ie the user story is updated with sums from the tasks, but if two or three fields are changed at the same time, only the first is summed up correctly (the others remain unchanged). In the event log on the TFS server everything seems fine as far as we can see.

The purpose here is to sum up the values from task to user stories. We also have similar rules for user story to feature, task to bug and task to issue.

Are we doing something wrong? Is there a simpler way to achieve what we want? Is this a bug?

Add a doc page on how to build

Add a [build] page on how to build [docs]

Expose ability to create new work item during execution

Some people create standard sets of tasks for a Bug for example. Creating a new work item and linking it to the work item under processing would be useful.

This may require a simple extension of the WorkItemRepository class to expose a New(Type) and New(Type, Project) function.

And then have the ability to create links.

Auto-fix data type conversion issues on save

When a script tries to store a double or decimal value in an integer (or when trying to store the outcome of a multiply, or divide operation in an integer field) the save operation fails. The new save handing code (or the field manipulation code) should check the target field's type before storing the value (or before saving the value).

New connection model (in hacking branch) will only work against one project collection

In the new model only a single instance of the EventProcessor is created, with a single connection to a TPC. To enable the plugin on a larger instance, it must support multiple TPC's.

I have the code to auto-resolve the TPC, but then there must be an EventProcessor per collection or per event.

Scripting support

I've been thinking about what we need to do to support scripting in the solution

Here's what I came up with:

• Put all scripts in a single user folder, not under the TFS folder (to avoid restarting TFS)
• Put a file watcher on that folder and reload scripts when needed, to avoid having to load scripts for each changed work item
• Call all scripts in the event processor. i.e. let the script figure out if it wants to act on a work item
• Pass the basic details of the work item to the script, and let the script decide if it wants to load the full details of the script and any parents/children/related items before doing an calculations/actions.
• Either let the script also save the work item, or pass the script a function for saving the work item. There is a challenge with this, in that work items are next to impossible to de/serialize because of the TFS object model design
• For performance work out how to prevent reevaluation of work items when they are saved and not trigger another processing loop (this is probably a separate issue though)

In terms of scripting langauges, I'd prefer JavaScript as it's the most widely known/used thing these days.
I tried using Edge.js and got some simple interaction working but I've been having problems with more complex objects and callbacks to C# code. That said, if we just send the work item to the JS script, and the script then uses the REST API (which would require TFS 2015) so there's likley no need to be any more complex than that.

Lua/Python, I'm less keen on simply because I don't know them.
ScriptCS might be an option. I don't know how easy it would be to directly call the server side API with it, but I doubt it would be hard.
And of course, there's powershell. Duh!

As a note, there's nothing stopping us supporting multiple scripting languages so that people have a choice. We'd just use a convention based on the file extension to decide which script engine to use at the time.

Effectively this would massively simplify TFSAggregator as it would become nothing more than a task runner, listening for work item changed events and calling scripts. The complexity would then be in the scripts themselves. We'd need to provide sample scripts that cover all the usage scenarios we currently support, but that shouldn't be a big deal.

Thoughts?

Enable native add-in support

Instead of scripting, enable support for native actions using a public interface to check applicability and execution. This surely is the fastest and most powerful option to extend ;).

Release new beta version for TFS 2015 and TFS 2013

Replace .NET scripting api with Roslyn scripting api?

https://github.com/dotnet/roslyn/tree/master/src/Scripting/Core