Apply some generic rules at organization level to all projects

[KamranAslamBhatti]

Hi, Is there any way we can apply a common rule at organization level to all projects under that organization and also when any new project created under that organization then that rule by default applies to the new project too. Following is example:

• Whenever a work item created, it's CreateDate field should be auto filled to currentdate. This rule should be default to each project under an organization and also when a new project created this rule should be auto apply so that I do not have to run: aggregator-cli map.rule command against each project in the organization. The above example is simple, it is just to make my question simple. I want some rules to apply at organization level and whenever user creates project they should auto apply to those projects. Is it possible?

[giuliov]

You pose two questions:

1. apply a rule to a whole organisation
2. automatically add rules when a project is created

The first answer is yes: you can deploy a single rule and add a mapping to each and every project in the org so they all invoke the same rule. Clearly the rule has to take in consideration the event context (say project A and B do not have the same set of work item types, like an Agile vs Scrum project) to work correctly. Aggregator has no facility for organisation, you need to invoke it multiple times. I take note and see to add some helpers post 1.0 release.

I am lean to answer no to the second part: TFS/AzDOS have no public event for a new project. You have two ways to work around this limit:

• or you use a tool that invokes TFS/AzDOS create project API first and then invoke Aggregator to map the rules
• you periodically run a script that looks for new projects and maps Aggregator rules on them

I can help you with directions and I will research if this is the definitive answer.

[giuliov]

After more digging I found a positive answer to the second question: there is a way to be notified when a project is created (or removed). Implementation is non trivial so we will implement it after release 1.0.

Please @KamranAslamBhatti share your thinking; do not close the issue as it will help us track the feature in the backlog.

[KamranAslamBhatti]

Giuliov, Could you please share how can we do the following:

• there is a way to be notified when a project is created (or removed).

Thanks, Kamran

[giuliov]

As I said, implementation is non-trivial: one should add many things to Aggregator CLI and its runtime. Things that come to mind:

• add support for Project events in CLI map command
• add listener for Project events in Runtime
• expose Project object(s) to Rules (I guess a read-only object suffices, this would avoid managing object caching and updating)

You can submit a PR that implements the above items, I would be delighted to review and merge it.

[RSMJreck]

@giuliov - Could you point me to where the Project events are? I've been looking everywhere that I can think of to find where you could get notified a project is created and haven't been able to find it. I might be able to start some work around this to get it started.

[giuliov]

I cannot find any notes on the "non trivial" solution and, as I wrote in the initial response, there are no events in public docs.

An idea is to use a Timer binding instead of the normal HTTP binding. The difference should be confined to the aggregator-function project. I guess it would be better to specialise run.csx per "logical" event type: from FunctionTemplate/run.csx to FunctionTemplates/workitem/run.csx, FunctionTemplates/project/run.csx ecc. This has a cascade effect: AzureFunctionHandler.RunAsync method cannot retrieve the workitem, the self object in rules is now a project object; probably need some declaration in the rule to prevent mapping errors (a rule designed for project event mapped to a workitem event). Finally the timer function need some permanent store to note when a project is added/deleted (diff'ing state) and invoke the rule.

We can use Slack for discussing details, if you like the idea.

Also @jessehouwing may have some smart idea on this topic.

[jessehouwing]

You could use the new streaming API for audit events... New project surely is an audit event... I wonder whether the api could scope a service hook at the collection level, haven't tried that yet...

On Thu, Apr 23, 2020, 23:58 Giulio Vian [email protected] wrote:

I cannot find any notes on the "non trivial" solution and, as I wrote in the initial response, there are no events in public docs.

An idea is to use a Timer binding https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-timer instead of the normal HTTP binding. The difference should be confined to the aggregator-function project. I guess it would be better to specialise run.csx per "logical" event type: from FunctionTemplate/run.csx to FunctionTemplates/workitem/run.csx, FunctionTemplates/project/run.csx ecc. This has a cascade effect: AzureFunctionHandler.RunAsync method cannot retrieve the workitem, the self object in rules is now a project object; probably need some declaration in the rule to prevent mapping errors (a rule designed for project event mapped to a workitem event). Finally the timer function need some permanent store to note when a project is added/deleted (diff'ing state) and invoke the rule.

We can use Slack https://slackin-tfsaggregator.herokuapp.com/ for discussing details, if you like the idea.

Also @jessehouwing https://github.com/jessehouwing may have some smart idea on this topic.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tfsaggregator/aggregator-cli/issues/73#issuecomment-618690340, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA724S2ZFWZSNYXUVRSXQHTROC2Y7ANCNFSM4IP6TQNQ .

[RSMJreck]

The audit looks promising. I'll try to play around with it a little.