# Notifications

The goal of this document is to specify the logical design for notifications service within the Alkemio platform.

The service specifically targets out-of-band notifications, such as e-mail, sms, push notifications.

Notes:

* Notifications events are consumed from a RabbitMQ AMQP PubSub implementation (consuming a queue)
* The notification service is not handling GraphQL subscriptions - these are managed on API (GraphQL) level
* Notifications are transient and not guaranteed (even if they will work 99.9%); they are a convenience. There is no state management.

Aspects to consider:
- Email templates should be supported
- SMTP relay should be supported and is first priority

## Notifications Design

### [Architecture](https://miro.com/app/board/o9J_lvqstFI=/)

The architecture of the notifications is the following:

1. GraphQL mutations publish events to the alkemio-notifications event queue on RabbitMQ through AMQP.
2. RabbitMQ queue alkemio-notifications is connected with a RabbitMQ exchange to support AMQP PubSub.
3. AMQP RabbitMQ consumer (Alkemio Notifications Service) reads the event and sends an event to a 3rd party service for out-of-band communication. There are different strategies how to send it and channels to send to. The implementation is wrapping notif.me, using NestJS.

### Email templates

Email templates can be implemented with [notifme-templates](https://github.com/notifme/notifme-template). A template would look like:

    email: {
      from: '{{emailFrom}}',
      to: '{{user.email}}',
      subject: 'Welcome {{user.firstname}}',
      html: `{% extends "templates/_layouts/email-transactional.html" %}
        {% block content %}
          Hi {{user.firstname}},<br><br>
          We're very happy to welcome you on board.<br><br>
          See you soon!
        {% endblock %}`
    }

### Events

| Event Name | Purpose | Message types / audience | Payload |
| ------------------------------------- | ------------------------------------------ | ---------------------------------------------------- | --- |
| COMMUNITY_APPLICATION_CREATED | New application for a community | User that signed up; Community admins; Global admins |HubId, ApplicationId |
| COMMUNITY_APPLICATION_UPDATED | Application approved / rejected / archived | User that signed up; Community admins; Global admins |HubId, ApplicationId |
| ORGANIZATION_VERIFICATION_REQUESTED | Org verification has been requested | Org admin/owner; global admins |OrgId |
| ORGANIZATION_VERIFICATION_UPDATED | Org verification has been updated | Org admin/owner; global admins |OrgId |
| USER_PROFILE_CREATED | New user has signed up | User; global admins |UserId |
| COMMUNICATION_UPDATE_MESSAGE_RECEIVED | User has received an update message | User |HubId, CommunityId |
| OPPORTUNITY_CREATED | A new opportunity has been created | Challenge / Ecoverse admins / Global Admin |HubId, OpportunityId |

Note: EventAgent(User)Id is sent in all payloads.
## Open discussion points

* Management of notification preferences
* Users need to be able to control the notifications that they receive
* Authorization
* Framework needs to ensure that only users that are eligible to receive events do so