It might make sense to introduce a new notification kind custom rather than reusing system. system notifications are triggered by events within the system, whereas this custom notification is user-initiated and typically relates to events happening outside the system.

This would also require adding a /notifications/custom endpoint and updating the front-end (e.g., /deployment/notifications) to retrieve both system and custom templates.

Wdyt?

I think we should do this. I don't like the idea of piggy-backing on top of "system" notifications here.

Addressed in 203668d
I will add the front-end changes to /deployment/notifications in a follow-up PR

Note: Custom notifications may have the same issue as test notifications, if a user sends the same notification multiple times in a single day, our deduping will treat later sends as duplicates. Changing this could also mean circumventing a measure intended to reduce noise and prevent spam. For now this shouldn’t be a problem since users can only send notifications to themselves, but that might change in the future.

Should we allow multiple sends of the same custom notification within a single day, or keep the current deduping to limit noise/spam?

That's a good point. I would suggest:

• For requestors sending a notification to themselves, do not dedupe OR reduce the deduplication timeframe to something lower like 1 minute.
• For requestors sending a notification to others, we should enforce similar notification limits to prevent noise.

If a user has some script that alerts them of completion of a task, it might make sense for their notification to have the same content each time. It would definitely be surprising for them to not receive the second one.

If we keep the de-duplicate behavior then we definitely need to ensure this behavior is very obviously documented. We could document a workaround that the user can do by injecting a timestamp in the message.

I'm not opposed to us bypassing the de-duplication logic and just ensuring this endpoint has a rate limit? Would like to hear other peoples thoughts on that though.

@johnstcn @DanielleMaywood Thank you for the feedback. I agree that for the custom notification use case, it might be common to send the same message multiple times in a day, so it makes sense not to dedupe those. Since this feature will evolve to support multiple recipients, I like the idea of not deduping for the requesting user while deduping for other recipients.
For now, I updated the code to bypass deduplication by adding a timestamp to the payload (same as in test notifications).
We might be able to update compute_notification_message_dedupe_hash to produce a different hash when it’s a custom notification and the sender is also the recipient.

I created a follow-up issue to track multi-recipient support: #19768

That's a good point. I would suggest:

• For requestors sending a notification to themselves, do not dedupe OR reduce the deduplication timeframe to something lower like 1 minute.
• For requestors sending a notification to others, we should enforce similar notification limits to prevent noise.

Nice examples!

Obligatory reminder to check migration number before merge¬!