Multiple notifications using same connection details

blockblue47 commented 2 years ago

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

[X] I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

When creating notification types, most of the time I need to create multiple notifications that need to go over to specific users and/or teams but using the same base details (for example, an email SMTP notification using the same connection details but with different TO, CC, BCC and Subject lines). This is important to ensure that everything uses the same connection details (for example email SMTP) but the rest of the information is different.

✔️ Solution

Having a button to allow for the creation of multiple notification connections to be created using the same connection details but we can change the message, subject and sender details, would make it easier for certain types of notifications to be sent to different teams based on what applications or servers they are running and managing.

❓ Alternatives

No response

📝 Additional Context

deefdragon commented 2 years ago

Ideally there would be a clone/duplicate button for a notification. #887 is working on implementing them for Monitors, and I see little reason the same cant be done for Notifications.

jordantrizz commented 5 months ago

I think your solution isn't a good design.

Being able to duplicate the Notification Type object is perfectly fine, I think that should be a separate issue.

However, keeping the same connection details and then only modifying To, CC is problematic for the following reasons.

Are the connection details locked?
Are the connection details linked to a specific Notification Type?
What happens if you delete the Notification Type that was used to duplicate?

Instead I suggest the following. Allow the creation of a Notification Service object that can be attached to Notification Types and utilize the Notification Service object's connection 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. If you change the Notification Service object, it applies to all Notification Types linked to it. See https://github.com/louislam/uptime-kuma/issues/1850

blockblue47 commented 5 months ago

Ahh, yeah that might be a better system for achieving that I didn't think about at the time of creation of this feature request. That way items like the core connection details stay the same while having multiple notification types (like a single SMTP connection, but that has multiple SMTP notifications or parameters for different monitors).

You can close this one if #1850 is similar to this and achieves what you're proposing for its solution.

jordantrizz commented 5 months ago

Ahh, yeah that might be a better system for achieving that I didn't think about at the time of creation of this feature request. That way items like the core connection details stay the same while having multiple notification types (like a single SMTP connection, but that has multiple SMTP notifications or parameters for different monitors).

I think so, but I would want more comments and feedback; there might be something I'm missing.

You can close this one if #1850 is similar to this and achieves what you're proposing for its solution.

I don't know what should be done to get this feature request considered and implemented. I'm open to whatever, so I don't have to copy and paste for new notification-type objects. I think you should get credit for being the first to suggest this, I just came along and articulated it further and different.

@commanderstorm what's the best way forward here?

CommanderStorm commented 5 months ago

Sharing notification settings between multiple notification providers would take a major overhaul of the system. I think the core issue is resolvable via a clone button => less entanglement of different subsystems.

If somebody wants to look into this we would be greatly appreciated. Currently (beginning of 24, gearing up for V2.0, see the pinned issue) our focus is on making the system more stable and predictable performance wise and removing the sharpest of corners.

jordantrizz commented 5 months ago

Sharing notification settings between multiple notification providers would take a major overhaul of the system. I think the core issue is resolvable via a clone button => less entanglement of different subsystems.

I agree; it would be a major overhaul and could be done in the future. For now, a stop-gap solution is the cloning of notification-type objects.

louislam / uptime-kuma