Notifications Improvement - Duplication, Notification Service Object and Contacts

[jordantrizz]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

The Notification system is great; it's extremely customizable. However, repetitive tasks are cumbersome. For instance, a common task would be to add a monitor and then add an SMTP Notification for a new email address. This requires configuring a Notification using the SMTP Notification Type, filling out all of the details the are already within the database.

✔️ Solution

Any of the following can be a solution.
1. Notification Service Object
Allow the creation of a Notification Service object that can be attached to Notification Types and utilize the Notification Service object's details. This would be beneficial for SMTP or SMS types, especially if you need to roll API keys for these services as it would be a single change versus going to each Notification Type object

2. Allow duplication of existing objects
Allow duplication of existing Notifications instance configuration; this, in turn, would save time when creating a new Notification Type that uses the same service for SMTP or SMS.

3. Contacts
Going a step further, creating a Contact Object would allow for defining specific details that can be used for a Notification Type. The fields would be as follows.

• Name
• Phone 1
• Phone 2
• Email 1
• Email 2

There could be an option to create custom fields with data.

4. Contact Groups
Creation of a new object called Contact Groups, which holds multiple Contact objects and be attached to a Notification Service object.

❓ Alternatives

None.

📝 Additional Context

🐲

[jordantrizz]

Instead of responding, I just updated the issue. Hopefully this helps.

[CommanderStorm]

Could you deduplicate with existing issues and contribute there? ^^

• Service/Copy is covered in Multiple notifications using same connection details #954

I think the contacts is also covered in this issue (but your description is likely better)

• Notications to Contact groups instead to notication providers #541

=> Could you limit this issue to just contacts

[jordantrizz]

I'm just a reporter, I think what you're asking is the tasks of an issue manager. I've spent the time to articulate my feature request, and as you said it's better than others.

Perhaps a new issue should be created under the control of a project contributor that encompasses all of the issues related to overhauling Uptime Kuma's notifications system. Link to all the issues and then close them. That issue can then be changed and updated as needed.

I'm closing this for now, It can be linked as needed.

[CommanderStorm]

what you're asking is the task of an issue manager

We are all just volunteers here. This is not a company.
=> not creating duplicates is a shared responsibility

a new issue that encompasses all of the issues related to overhauling Uptime Kuma's notifications system

Feature-dump-issues does not work for us because of the sheer amount of work required to update them.
Please see #21 for a good example how these issues age poorly.

Link to all the issues and then close them

The problem with this idea is that then all discussion would happen in as single thread => too messy to be productive

[jordantrizz]

We are all just volunteers here. This is not a company.

I appreciate your efforts, I could dump my descriptions as comments on those issues. But now my better description is buried in the comments. Hence why I mentioned a contributor who will be working on the feature requests creating a single issue to encompass the issues and come up with proper descriptions for what changes will happen.

=> not creating duplicates is a shared responsibility

Yes, and hence why I closed this as there are two newer issues that cover the one I created. I shouldn't have created my issues at all, I fault myself for this, I searched too specifically. I should have put comments on the issues, which I've just done.

Feature-dump-issues does not work for us because of the sheer amount of work required to update them.
Please see #21 for a good example how these issues age poorly.

I agree. However, my idea would not be an issue that has features requests spanning every part of Uptime Kuma, similar to the issue you linked. It's would be specific to the notification system and shouldn't include more than 5-10 feature requests, otherwise it would be unmanageable. Perhaps request a "comments and suggestions" period, then lock it.

The problem with this idea is that then all discussion would happen in as single thread => too messy to be productive

Yes, for the issue you posted. What I'm suggesting is an issue that targets a very specific part of Uptime Kuma, so all comments would be specific.

As you mentioned previously, my description is better than most, this can be duplicated by core contributors which decision making powers.

This is just an idea to try and trim down the issues you have, provide better descriptions and encompass similar feature requests together without being overwhelming.

I could be 100% wrong here, but thought I'd share regardless.