Frontend Project Technical Description

and Requirements
DISCLOSURE AGREEMENT
The recipient acknowledges that the documents provided contain confidential and
proprietary information. The recipient agrees not to disclose, in any form, either directly
or indirectly, any information contained within these documents to third parties without
the prior written consent of the owner(s) of the confidential information. This obligation
of confidentiality shall survive the termination or completion of any engagement or
relationship between the parties involved.

Introduction:
This document provides a comprehensive overview and requirements for the frontend project.
The objective is to guide developers in understanding the scope, components, and
specifications of the project.

Goal:
The role of the front end in this project is to serve as a user interface that allows non-technical
users to interact with an API and manage configurations within a given system. The front end
will act as a simple interface through which users can view, modify, and update configurations
using the provided API.

System Architecture:
The front-end communication with a single REST API in JSON format. The front end will interact
exclusively with this API for retrieving, creating, updating, and deleting configurations.

[Frontend]
└── Communicates via HTTP/JSON
─┬─ [REST API] ─ Data Storage
└─ (Backend Logic)

User Interface Design:

The user interface design of the frontend project utilizes Next.js framework with Tailwind CSS.
The design incorporates basic Shadow UI components to create an intuitive and visually
appealing interface for users. Additionally, the frontend aims to support both white and black
themes, which can be toggled from the menu.

Main Pages:

1- Dashboard View:
This page presents an overview of relevant information, providing users with basic key insights
and data visualizations.

2- Configs View:
This page allows users to manage configurations. It provides a clear overview of existing
configurations and enables users to create, update, and delete any type of configuration.

3- Playground View:
This page serves as a testing ground for users to experiment with configurations and observe
the results in real time.

All pages are supported by dedicated endpoints on the REST API. The responsibility of the
frontend is to fetch data from the API, display it in the correct format, and ensure that the
displayed information is always up to date by automatically synchronizing and refreshing the
data.

Details about the pages :

1- Dashboard View:
below is a screenshot of the current page
In the dashboard view, the main objective is to present all the available configurations. Each
configuration will be displayed as a card component, showcasing the configuration name and
the number of alerts raised by that configuration. Considering the substantial number of
configurations expected in the database, the page will feature a left-side scroll functionality to
accommodate the extensive list of cards. Cards can be displayed in grid to take the place in
whole page.

The card component could be something simple like below, where the text is actually the name
of the config and the number is the count of alert raised:

All the necessary data is retrieved in a single API call, providing efficiency and reducing the
number of network requests. To enable users to quickly find specific configurations, a text filter
will be implemented on the page. The filter will be applied to the configuration names, allowing
users to search and locate desired configurations with ease.

2- Configs View:
below is a screenshot of the current page
The Config View holds significant importance in the application. Currently, the displayed data is
a mock representation, and the required implementation entails a REST API call to populate the
actual data. While the existing table layout can remain as is, there are a couple of
enhancements to be made to the table, namely :
- Filter Functionality: The existing filtering function needs adjustment. Currently, the filter
operates on a word basis, requiring an exact match. To improve usability, the filter should
be modified to allow filtering based on individual characters, rather than whole words. So
when the user starts typing letters, the filter starts presenting matched config names.
- The checkbox at the beginning of the row can be removed, no grouped actions will be
supported for now.
The rest of the layout can be kept as is, the columns display the exact fields.

To Add :
It Is important to note that there are two distinct types of configurations: "Notification Service
Config" and "Dsmon Config". These configuration types have specific characteristics and
functionalities. It is also important to understand the purpose of the Notification Service and the
relationship between these two configuration types. Additionally, the Dsmon Config type should
support multiple channels for alerting.

- Notification service config (this item is not implemented on the provided project)
 -
The Notification Service Config represents configuration settings related to the
notification service functionality.
- It is essential to provide a means for users to configure how alerts and
notifications are sent. This can include channels such as email, Jira
- DSMON config (this one is implemented, which is the table inside configs view)
- Dsmon Config represents configuration settings specific to the Dsmon system

To provide a user-friendly interface for managing Notification Service Config and Dsmon Config,
it is proposed to implement both configurations in a tabular format within a Tab component,
utilizing Shadow UI.

Tab: Notification Service Config:

- Display: Within the Notification Service Config tab, present a table that shows the
existing Notification Service Configurations in a tabular format same as the provided
one. Each row should represent an individual configuration entry.
- Actions: Enable users to perform create, edit, and delete actions specific to Notification
Service Configurations. These actions should be available for each configuration entry
through corresponding buttons or icons within the table.
Tab: Dsmon Config:

- Display: Within the Dsmon Config tab, present a similar table structure (but with different
column names) to showcase the Dsmon Configurations in a tabular format. Each row
should represent an individual configuration entry.
- Actions: Provide create, edit, and delete functionality for Dsmon Configurations. Users
should be able to perform these actions for each configuration entry within the table.

Action items on configs view:

- Add Config button for Notification Service Config tab:
The whole tab, table, and buttons need to be implemented.

Example of jira notification service

{
"name": "string-name",
"kind": "jira", # enum value for now can jira or email
"service_specific_configuration": {
"url": "url of jira server",
"username_ref": "JIRA_USERNAME",
"password_ref": "JIRA_PASSWORD",
"custom_fields": [listo of custom field need for jira client]
},
"secret_backend": "env" # enum value can be env or vault
}

Example of email service:

{
"name": "name of notification service",
"kind": "email",
"service_specific_configuration": {
"smtp": "uri"
},
"secret_backend": "env"
}

In the table, we can display 4 columns, the id, name, kind and secret backend with
action dropdown list to edit and delete a notification service
 - Add Config button for DSMON Config tab: needs to be implemented. Currently, this
button triggers a modal dialog component, although it's worth assessing whether this
component is suitable for the requirements outlined below. The objective is to display a
form where users can define a new configuration, which can then be submitted to the
API for processing.

The displayed element is not complete yet: I will attach the JSON Object that needs to be
pushed to the API to create a new DSMON config :

{
"meta": {
"run_every": "* */1 * * *",
"description": "Alert config for Juniper JUNOS devices in Elastic",
"author": "author_name_here"
},
"name": "name-of-config-here",
"notification_service": [
{
"name": "notifdication service 1r",
"notification_service_id": "64d506d90a54c7660a463d0f",
"template": "needs to be a big text area, the text needs to be encoded to base64 before
sending it to the API",
"additional_variables": {"text area that takes a json object"}
},
 {
"name": "notification service 2",
"notification_service_id": "64dfbed56bcccda574078cc0",
"template": "needs to be a big text area, the text needs to be encoded to base64 before
sending it to the API",
"additional_variables": { "text area that takes a json object" }],
"scoping": {
"method": "query",
"scoping_time_start": "3d",
"scoping_time_end": "1d"
},
"query": {
"filters": [
"Filter1", "Filter2","Filter3"
],
"filter_all": true,
"aggregated_fields": [
"Aggration field 1",
"Aggration field 2"
],
"time_window_start": "48h",
"time_window_end": "1h",
"time_filter_field": "field name in string "
},
"threshold": {
"min": {
"quantity": 1222,
"field": "field name"
},
"max": {
"quantity": 0,
"field": "field name"
}
},
"alert_grouping": {
"grouping_field": "filed name in string"
},
"ignore": ["array that take a json object"],
"alert_sender_kafka_config": {
"topic": "topic name",
"kafka_broker": "broker address "
}
}

Notes:
- Base64 Encoding of Template Field: Before sending a POST call to the API to add a
new configuration definition, the value of the template field should be encoded in
Base64. This ensures that the template is properly encoded and handled during transit.
Implement a mechanism that encodes the template field value in Base64 before
transmitting it to the API.
 - Dynamic Section for Notification Services: Within the configuration form, create a
dynamic section that allows users to define one or more notification channels for a given
Dsmon configuration.

a. Dropdown List: Provide a dropdown list within the dynamic section to enable
users to select a notification client from the available options supported by the backend.
This dropdown should display the supported options and allow the user to choose one
for each notification channel.

b. Template Input: Include a text area where users can input the template specific
to each notification service. This allows users to define templates tailored to the chosen
notification client.

c. Additional Variables: Add an optional text area for users to provide any
additional variables required for the template or notification service.

- Dynamic Section Management: Implement functionality to dynamically add or remove

sections within the form, allowing users to define multiple notification services as needed
for a particular Dsmon configuration. This enables flexibility in managing various
notification channels associated with a configuration.
- After making a call to the API and receiving a 201 response code indicating a successful
configuration creation, it is necessary to display a validation popup with a concise
message confirming the successful creation before returning to the table view.

- Edit Config button for both DSMON config and Notification Service Config :
In the provided table in the project. It includes a dropdown menu for each configuration entry,
offering an "Edit" button action and a "Delete" button action.
When the user clicks the "Edit" button, it should display the same form used for creating a new
configuration. However, the form should be pre-filled with the existing values of the configuration
being edited. This will allow the user to modify any field as needed. Once the edits are made,
the user can submit the updated form to the API for processing. The same requirement applies
to the notification service configuration tab, where the "Edit" button should provide a similar
functionality of editing and updating the existing configuration.

Notes:
- The template field needs to be decoded from base64 format before being displayed in
the form as clear text. This allows the user to view and modify the template in a readable
format. When the form is submitted to the server, the modified template should be
encoded back into base64 format before being sent. This ensures that the data is
properly encoded for processing and storage on the server side.
- After making a call to the API and receiving a 200 response code indicating a successful
configuration modification, it is necessary to display a validation popup with a concise
message confirming the successful edit before returning to the table view.

- Edit Config button for both DSMON config and Notification Service Config :
The delete button action for both configurations should be self-explanatory and straightforward
for users. When a user clicks the delete button, a notification should appear, prompting them to
confirm the deletion or cancel the action. If the user chooses to proceed with the deletion, a
validation message should be displayed to confirm the successful deletion of the configuration.

3- Playground View:
below is a screenshot of the current page
 The playground view is designed to be simple. It consists of one action that allows users to
submit JSON data to the API using a POST call. This can be done in the left text area. The UI
should present the result of the API call in the right-side area.

To enhance readability, the JSON data should be formatted and highlighted correctly. This will
make it easier for users to review and analyze the response from the API.