# Subscribe to a notification from the Application Details page {#subscribe-to-a-notification-from-the-application-details-page}


Provide the ability to subscribe to a notification from the Application Details page


## Summary {#summary}


Allow users to subscribe application with a notification from the Application Details page
using provided instruments for selecting available triggers and services.


## Motivation {#motivation}


It is already possible to subscribe to notifications by modifying annotations however this is a pretty
poor user experience. Users have to understand annotation structure and have to find available services and triggers in configmap. 


### Goals {#goals}


Be able to subscribe to a notification from the Application Details page without forcing users to read the notification configmap.


### Non-Goals {#non-goals}


We provide only ability to select existing services and triggers, we don't provide instruments to add/edit/delete notification services and triggers.


## Proposal {#proposal}


Two changes are required:

* Implement notifications API that would expose a list of configured triggers and services
* Implement UI that leverages notifications API and helps users to create a correct annotation.


### Use cases {#use-cases}


Add a list of detailed use cases this enhancement intends to take care of.


#### Use case 1: {#use-case-1}
As a user, I would like to be able to subscribe application to a notification from the Application Details Page
without reading knowing of annotation format and reading notification configmap.


### Implementation Details/Notes/Constraints [optional] {#implementation-detailsnotesconstraints-optional}


Three read-only API endpoints will be added to provide a list of notification services, triggers, and templates.

```
message Triggers { repeated string triggers = 1; }
message TriggersListRequest {}
message Services { repeated string services = 1; }
message ServicesListRequest {}
message Templates { repeated string templates = 1; }
message TemplatesListRequest {}
service NotificationService {
	rpc ListTriggers(TriggersListRequest) returns (Triggers) {
		option (google.api.http).get = "/api/v1/notifications/triggers";
	}
	rpc ListServices(ServicesListRequest) returns (Services) {
		option (google.api.http).get = "/api/v1/notifications/services";
	}
	rpc ListTemplates(TemplatesListRequest) returns (Templates) {
		option (google.api.http).get = "/api/v1/notifications/templates";
	}
}
```


### Detailed examples {#detailed-examples}



### Security Considerations {#security-considerations}


New API endpoints are available only for authenticated users.  API endpoints response does not contain any sensitive data.


### Risks and Mitigations {#risks-and-mitigations}


TBD


### Upgrade / Downgrade Strategy {#upgrade--downgrade-strategy}


By default, we don't have a notification configmap in the system; in that case, API should return an empty list instead of erroring.


## Drawbacks {#drawbacks}




## Alternatives {#alternatives}


Continue to do that manually.