Add `@everyone`, `@userId`, `@userNr` to DingTalk notifications

[凯观生活]

📑 I have found these related issues/pull requests

I didn't find any related questions

🏷️ Feature Request Type

Change to existing notification-provider

🔖 Feature description

It is recommended that in the dingding notification, you can add parameters such as whether to @ everyone and the user ID of the @ person and the mobile phone number of the @ person according to the official development documentation of DingTalk. It is supported to configure these parameters when configuring the notification message. Three parameters make reminders richer~

✔️ Solution

I want to support the @Designated person’s mobile phone number, the userId of the @Designated person, and whether to @everyone when notifying DingTalk messages.

❓ Alternatives

Try to use webhook to customize notification messages, but this is more troublesome.

📝 Additional Context

Currently, the message type used in the dingding notification type is markdown type. The following parameters need to be added:
{ "msgtype": "markdown", "markdown": { "title":"杭州天气", "text": "#### 杭州天气 @150XXXXXXXX \n > 9度，西北风1级，空气良89，相对温度73%\n > ![screenshot](https://img.alicdn.com/tfs/TB1NwmBEL9TBuNjy1zbXXXpepXa-2400-1218.png)\n > ###### 10点20分发布 [天气](https://www.dingtalk.com) \n" }, "at": { "atMobiles": [ "150XXXXXXXX" ], "atUserIds": [ "user123" ], "isAtAll": false } }

in:
atMobiles is the mobile phone number of the person being @ (the mobile phone number of the @ person must be included in the text content. Only members in the group can be @, and the mobile phone numbers of non-members in the group will be desensitized.) The data type is Array;
atUserIds is the userId of the @ person (add the userId of the @ person in text.) The data type is Array;
isAtAll is whether @ everyone. The data type is Boolean.

For details, please refer to the markdown type in this article.
https://open.dingtalk.com/document/orgapp/custom-bot-send-message-type

[Frank Elsinga]

The problem with adjusting notification providers is that there always is manual testing involved (how does this look?, does it work as documented?)
=> changes to notification providers are both simpler and more reliant on our community as testing them is very manual.
=> If you want a change like a "Notify"-selector and conditional input, we would be open to that. Our contribution guide is found here. The guideance on new notification providers is likely the most relevant.

[凯观生活]

The problem with adjusting notification providers is that there always is manual testing involved (how does this look?, does it work as documented?) => changes to notification providers are both simpler and more reliant on our community as testing them is very manual. => If you want a change like a "Notify"-selector and conditional input, we would be open to that. Our contribution guide is found here. The guideance on new notification providers is likely the most relevant.

Okay, I'll take a look at this guide and study this. Thanks if you have any questions, please askThanks for your support