migrate connector to power platform for msteams

[zhan9san]

Fix #3920

The summary is marked as DEPRECATED in this PR because there is no appropriate field in Request Body Schema.

Besides, adding support of more flexible Adaptive Cards is not covered in this PR. It may be in another PR.

Migration plan:

1. Create a workflow from a channel in Teams and get the workflow webhook URL
2. Replace the connector webhook URL with the workflow webhook URL in AlertManager configuration

Test result

Reference

https://support.microsoft.com/en-us/office/creating-a-workflow-from-a-channel-in-teams-242eb8f2-f328-45be-b81f-9817b51a5f0e https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/

an example json can be used in Postman

{
  "type": "message",
  "attachments": [
    {
      "contentType": "application/vnd.microsoft.card.adaptive",
      "contentUrl": null,
      "content": {
        "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
        "type": "AdaptiveCard",
        "version": "1.2",
        "body": [
          {
            "type": "TextBlock",
            "text": "[FIRING:8] LowDiskSpace (CriticalLowDiskSpace foo",
            "weight": "Bolder",
            "size": "Medium",
            "wrap": true,
            "style": "heading"
          },
          {
            "type": "TextBlock",
            "text": "This is some **bold** text\r1. Numbered\r2. List\r"
          }
        ]
      }
    }
  ]
}

[zhan9san]

@simonpasquier

Could you please help review this PR?

Do you know why the test run successfully in Github action but failed in CircleCI?

[jkroepke]

Technically, this is an breaking change. Keep that in mind. Not sure if its worth to setup an msteamsv2 connector and deprecate the old one to increase the awareness for end users.

[zhan9san]

@jkroepke

Thanks for your review.

I don't think v2 is necessary because the original strategy would be abandoned by msteams in a short time window.

The incompatible migration is a must.

https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/

We will gradually roll out this change in waves:

Wave 1 – effective August 15th, 2024: All new Connector creation will be blocked within all clouds

Wave 2 – effective October 1st, 2024: All connectors within all clouds will stop working

[jkroepke]

At least, It worth to mentation that the docs that the connector now requires a Power Automate license.

I'm aware for that situation, however many users maybe not and my create issues here at AM, if wave 2 starts.

[zhan9san]

it makes sense.

I am on vacation, and will be back one week later.

I can add this notice in doc when I am back, if it's not urgent.

[chrisipa]

I'm also desperately waiting for this PR to be merged. Thanks for your help and dedication.

[zhan9san]

@jkroepke

The license has been updated in doc. Do you still have any concern?

@simonpasquier Could you please help review this PR?

[jkroepke]

@jkroepke

The license has been updated in doc. Do you still have any concern?

The doc is clear. That helps.

You can optionally mention, that as of October 1st, 2024, classical Teams webhooks are not longer supported by Microsoft. including a link to the official blog post.

That may help users, that are not fully familiar with Teams. There are a lot users that may had to integrate msteams as receiver, without been in that eco system.

[pascal-hofmann]

In the meantime the timeline has been changed by Microsoft. See the update at the top at https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/:

Update 07/23/2024: We understand and appreciate the feedback that customers have shared with us regarding the timeline provided for the migration from Office 365 connectors. We have extended the retirement timeline through December 2025 to provide ample time to migrate to another solution such as Power Automate, an app within Microsoft Teams, or Microsoft Graph. Please see below for more information about the extension: All existing connectors within all clouds will continue to work until December 2025, however using connectors beyond December 31, 2024 will require additional action. Connector owners will be required to update the respective URL to post by December 31st, 2024.

[jkroepke]

All existing connectors within all clouds will continue to work until December 2025,

At least, they continue to work for more year. From my point of view, the existing receiver should not be changed and a new one should be introduced.

[zhan9san]

Instead of introducing a new receiver, I prefer to add an optional flag in the configuration, such as power_automate.

If power_automate is set to false or not set at all, the alerts will be sent to the Webhook connector. Only if power_automate is explicitly set to true, will the alerts be sent to the Power Automate platform.

Let me know your thoughts.

[grobinson-grafana]

Instead of introducing a new receiver, I prefer to add an optional flag in the configuration, such as power_automate.

If power_automate is set to false or not set at all, the alerts will be sent to the Webhook connector. Only if power_automate is explicitly set to true, will the alerts be sent to the Power Automate platform.

Let me know your thoughts.

I'm not sure about this because it will mean we need to transition users a second time to remove the flag once power automate becomes the only working option and we want to remove the flag.

[zhan9san]

I get your point.

How about using webhook_connector flag?

true: webhook connector not set: power auto platform

After the webhook connector is retired, the users would have to migrate to power auto platform. The we can remove the flag at any time.

It's a one time change for power auto platform user.

For users who still want to use webhook connector, they have to set it to true explicitly after upgrade, and migrate to power auto platform next year.

[jkroepke]

they have to set it to true explicitly after upgrade

Thats an breaking change.

---

What the issue with and v2 notifier which brings the best possible user experience? Why so complicated?

From maintainer point of view, it's much easier to just remove an whole notifier in a year.

Creating an notifier which support both feel counterintuitive. For example, the summary property has no effect, if power flows are used. This my confused people. Then, new property needs to be introduced which must mark instantly as deprecated. Having both logics in one notifier increases the complexity on code.

[zhan9san]

It's okay. I'll add a new receiver.

[zhan9san]

I hope you don’t mind, but I would greatly appreciate another opportunity to discuss this.

There are two services: Webhook Connector and Power Automate.

I attempted to add a new receiver, but I found that detecting the service via URL is much more straightforward.

brings the best possible user experience

If we detect it automatically, the only thing users need to do is to change the URL.

Reference: https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/?commentid=1101#comment-1101

[grobinson-grafana]

I'm afraid I don't see how that makes it more straightforward? What do you plan to do with the summary field when the URL matches the regex logic.azure.com? What if Microsoft change the URL in future, or start to use different URLs for different Teams accounts?

[sschne]

Is this still being worked on, or should i take this over?

[zhan9san]

@sschne

Feel free to take it. Thanks.

[grobinson-grafana]

This can be closed in favor of #3920.