It might make sense to introduce a new notification kindcustom rather than reusingsystem.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 in203668d
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 tonot 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 updatecompute_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¬!