Merge branch 'feature/2273-incident-list-merge-frontend' of github.co…

…m:keephq/keep into feature/2273-incident-list-merge-frontend

docs/deployment/configuration.mdx

@@ -69,7 +69,7 @@ Resource provisioning settings control how Keep sets up initial resources. This
 <Info>
 Authentication configuration determines how Keep verifies user identities and manages access control. These settings are essential for securing your Keep instance and integrating with various authentication providers.
 </Info>
-<Tip>For specifc authentication type configuration, please see [authentication docs](/deployment/authentication/overview).</Tip>
+<Tip>For specific authentication type configuration, please see [authentication docs](/deployment/authentication/overview).</Tip>
 
 
 | Env var | Purpose | Required | Default Value | Valid options |

docs/deployment/ecs.mdx

@@ -102,7 +102,7 @@ sidebarTitle: "AWS ECS"
             - Configuration Type: Configure at task definition creation
             - Volume type: EFS
             - Storage configurations:
-                - File system ID: Select an exisiting EFS filesystem or create a new one
+                - File system ID: Select an existing EFS filesystem or create a new one
                 - Root Directory: /
                 ![Volume Configuration](/images/ecs-task-def-backend5.png)
             - Container mount points:

docs/deployment/kubernetes/installation.mdx

@@ -46,8 +46,11 @@ To read about more installation options, see [ingress-nginx installation docs](h
 </Info>
 ```bash
 # simplest way to install
+# we set snippet-annotations to true to allow rewrites
+#   see https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#allow-snippet-annotations
 helm upgrade --install ingress-nginx ingress-nginx \
   --repo https://kubernetes.github.io/ingress-nginx \
+  --set controller.config.allow-snippet-annotations=true \
   --namespace ingress-nginx --create-namespace
 ```
 

docs/deployment/kubernetes/overview.mdx

@@ -14,5 +14,6 @@ We maintain an opinionated, batteries-included Helm chart, but you can customize
 ## Next steps
 - Install Keep on [Kubernetes](/deployment/kubernetes/installation).
 - Keep's [Helm Chart](https://github.com/keephq/helm-charts).
+- Keep with [Kubernetes Secret Manager](/deployment/secret-manager#kubernetes-secret-manager)
 - Deep dive to Keep's kubernetes [Architecture](/deployment/kubernetes/architecture).
 - Install Keep on [OpenShift](/deployment/kubernetes/openshift).

docs/deployment/secret-manager.mdx

@@ -59,18 +59,97 @@ Usage:
 
 ## Kubernetes Secret Manager
 
-The `KubernetesSecretManager` interfaces with Kubernetes' native secrets system. It manages secrets within a specified Kubernetes namespace and is designed to operate within a Kubernetes cluster.
+### Overview
 
-Configuration:
+The `KubernetesSecretManager` interfaces with Kubernetes' native secrets system.
+
+It manages secrets within a specified Kubernetes namespace and is designed to operate within a Kubernetes cluster.
+
+### Configuration
 
-Set `K8S_NAMESPACE` environment variable to specify the Kubernetes namespace. Defaults to default if not set. Assumes Kubernetes configurations (like service account tokens) are properly set up when running within a cluster.
+- `SECRET_MANAGER_TYPE=k8s`
+- `K8S_NAMESPACE=keep` - environment variable to specify the Kubernetes namespace. Defaults to `.metadata.namespace` if not set. Assumes Kubernetes configurations (like service account tokens) are properly set up when running within a cluster.
 
 Usage:
 
 - Secrets are stored as Kubernetes Secret objects.
 - Provides functionalities to create, retrieve, and delete Kubernetes secrets.
 - Handles base64 encoding and decoding as required by Kubernetes.
 
+### Environment Variables From Secrets
+The Kubernetes Secret Manager integration allows Keep to fetch environment variables from Kubernetes Secrets.
+
+For sensitive environment variables, such as `DATABASE_CONNECTION_STRING`, it is recommended to store as a secret:
+
+#### Creating Database Connection Secret
+```bash
+# Create the base64 encoded string without newline
+CONNECTION_STRING_B64=$(echo -n "mysql+pymysql://user:password@host:3306/dbname" | base64)
+
+# Create the Kubernetes secret
+kubectl create secret generic keep-db-secret \
+  --namespace=keep \
+  --from-literal=connection_string=$(echo -n "mysql+pymysql://user:password@host:3306/dbname" | base64)
+
+# Or using a YAML file:
+cat <<EOF | kubectl apply -f -
+apiVersion: v1
+kind: Secret
+metadata:
+  name: keep-db-secret
+  namespace: keep
+type: Opaque
+data:
+  connection_string: $(echo -n "mysql+pymysql://user:password@host:3306/dbname" | base64)
+EOF
+```
+
+#### Update the helm Values.yaml
+
+After creating the secret, update the `values.yaml` so the helm chart will inject the secret as env var:
+```bash
+backend:
+  enabled: true
+  waitForDatabase: true
+  databaseConnectionStringFromSecret:
+    enabled: true  # Enable using secret for database connection
+    secretName: "keep-db-secret"  # Name of the secret we created
+    secretKey: "connection_string"  # Key in the secret containing our connection string
+```
+
+#### Apply with Helm
+
+```bash
+# If installing for the first time
+helm install keep keephq/keep \
+  -f values.yaml \
+  --namespace keep
+
+# If updating existing installation
+helm upgrade keep keephq/keep \
+  -f values.yaml \
+  --namespace keep
+```
+
+#### Verify the installation
+
+Check if the secret is properly created:
+```bash
+kubectl get secret keep-db-secret -n keep
+```
+
+Verify the content of the secret is correct:
+```bash
+kubectl get secret keep-db-secret -n keep -o jsonpath='{.data.connection_string}' | base64 -d
+```
+
+Verify the pod using the secret:
+```bash
+kubectl get pod -n keep -l app.kubernetes.io/component=backend -o yaml | grep DATABASE_CONNECTION_STRING -A 5
+```
+
+
+
 ## GCP Secret Manager
 
 The `GcpSecretManager` utilizes Google Cloud's Secret Manager service for secret management. It requires setting up with Google Cloud credentials and a project ID.

docs/deployment/stress-testing.mdx

@@ -27,7 +27,7 @@ The primary parameters that affect the specification requirements for Keep are:
 3. **Number of Workflows**: How many automation run as a result of alert.
 
 ### Main Components:
-- **Keep Backend** - API and buisness logic. A container that serves FastAPI on top of gunicorn.
+- **Keep Backend** - API and business logic. A container that serves FastAPI on top of gunicorn.
 - **Keep Frontend** - Web app. A container that serves the react app.
 - **Database** - Stores the alerts and any other operational data.
 - **Elasticsearch** (opt out by default) - Stores alerts as document for better search performance.

docs/overview/comparisons.mdx

@@ -17,7 +17,7 @@ Keep is different because it’s able to correlate alerts between different obse
 |                                       | Keep                                                           | Alternative                  |
 | ------------------------------------- | -------------------------------------------------------------- | ---------------------------- |
 | Aggregates alerts from one platform | ✅                                                           | ✅                            |
-| Aggregates alerts from mutliple platforms | ✅                                                             | ❌                            |
+| Aggregates alerts from multiple platforms | ✅                                                             | ❌                            |
 | Correlates alerts between multiple sources | ✅                                                    | ❌                            |
 | Alerts enrichment                     | ✅                                                             | ❌                            |
 | Open source                           | ✅                                                             | ❌                            |

docs/overview/deduplication.mdx

@@ -20,7 +20,7 @@ Alert deduplication is a crucial feature in Keep that helps reduce noise and str
 Partial deduplication allows you to specify certain fields (fingerprint fields) that are used to identify similar alerts. Alerts with matching values in these specified fields are considered duplicates and are grouped together. This method is flexible and allows for fine-tuned control over how alerts are deduplicated.
 
 Every provider integrated with Keep comes with pre-built partial deduplication rule tailored to that provider's specific alert format and common use cases.
-The default fingerprint fields defined using `FINGERPRINT_FIELDS` attributes in the provider code (e.g. [datadog provider](https://github.com/keephq/keep/blob/main/keep/providers/datadog_provider/datadog_provider.py#L188) or [gcp monitoring provder](https://github.com/keephq/keep/blob/main/keep/providers/gcpmonitoring_provider/gcpmonitoring_provider.py#L52)).
+The default fingerprint fields defined using `FINGERPRINT_FIELDS` attributes in the provider code (e.g. [datadog provider](https://github.com/keephq/keep/blob/main/keep/providers/datadog_provider/datadog_provider.py#L188) or [gcp monitoring provider](https://github.com/keephq/keep/blob/main/keep/providers/gcpmonitoring_provider/gcpmonitoring_provider.py#L52)).
 
 ### Full Deduplication
 When full deduplication is enabled, Keep will also discard exact same events (excluding ignore fields). This mode considers all fields of an alert when determining duplicates, except for explicitly ignored fields.

docs/overview/examples.mdx

@@ -6,10 +6,10 @@ title: "Examples"
 
 
 ## Create an incident only if the customer is on Enterprise tier
-In this example we will utilze:
+In this example we will utilize:
 
 1. Datadog for monitoring
-2. OpsGenie for incident managment
+2. OpsGenie for incident management
 3. A postgres database that stores the customer tier.
 
 This example consists of two steps:
@@ -45,7 +45,7 @@ alert:
         type: opsgenie
         config: " {{ providers.opsgenie-prod }} "
         with:
-          message: "A new alert on enteprise customer ( {{ steps.check-if-customer-is-enterprise.results[1] }} )"
+          message: "A new alert on enterprise customer ( {{ steps.check-if-customer-is-enterprise.results[1] }} )"
 ```
 
 ## Send a slack message for every Cloudwatch alarm

docs/overview/introduction.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Introduction"
-description: "Keep is an open-source alert management and automation tool that provides everything you need to collect, enrich and manange alerts effectively."
+description: "Keep is an open-source alert management and automation tool that provides everything you need to collect, enrich and manage alerts effectively."
 ---
 <Note> You can start using Keep by logging in to the [platform](https://platform.keephq.dev).</Note>
 

docs/overview/keyconcepts.mdx

@@ -23,7 +23,7 @@ A Provider can either push alerts into Keep, or Keep can pull alerts from the Pr
 #### Push alerts to Keep (Manual)
 You can configure your alert source to push alerts into Keep.
 
-For example, consider Promethues. If you want to push alerts from Promethues to Keep, you'll need to configure Promethues Alertmanager to send the alerts to
+For example, consider Prometheus. If you want to push alerts from Prometheus to Keep, you'll need to configure Prometheus Alertmanager to send the alerts to
 'https://api.keephq.dev/alerts/event/prometheus' using API key authentication. Each Provider implements Push mechanism and is documented under the specific Provider page.
 
 #### Push alerts to Keep (Automatic)

docs/providers/adding-a-new-provider.mdx

@@ -2,7 +2,7 @@
 title: "Adding a new Provider"
 sidebarTitle: "Adding a New Provider"
 ---
-<Info>Under contstruction</Info>
+<Info>Under construction</Info>
 
 ### Basics
 
@@ -192,7 +192,7 @@ class BaseProvider(metaclass=abc.ABCMeta):
             )
         # else, if we are in an event context, use the event fingerprint
         elif self.context_manager.event_context:
-            # TODO: map all casses event_context is dict and update them to the DTO
+            # TODO: map all cases event_context is dict and update them to the DTO
             #       and remove this if statement
             if isinstance(self.context_manager.event_context, dict):
                 fingerprint = self.context_manager.event_context.get("fingerprint")
@@ -446,7 +446,7 @@ class BaseProvider(metaclass=abc.ABCMeta):
     @staticmethod
     def parse_event_raw_body(raw_body: bytes) -> bytes:
         """
-        Parse the raw body of an event and create an ingestable dict from it.
+        Parse the raw body of an event and create an ingestible dict from it.
 
         For instance, in parseable, the "event" is just a string
         > b'Alert: Server side error triggered on teststream1\nMessage: server reporting status as 500\nFailing Condition: status column equal to abcd, 2 times'
@@ -459,7 +459,7 @@ class BaseProvider(metaclass=abc.ABCMeta):
             raw_body (bytes): The raw body of the incoming event (/event endpoint in alerts.py)
 
         Returns:
-            dict: Ingestable event
+            dict: Ingestible event
         """
         return raw_body
 

docs/providers/documentation/auth0-provider.mdx

@@ -51,6 +51,6 @@ workflow:
           audience: "https://api.example.com"
           grant_type: "client_credentials"
 
-##Usefull Links
+## Useful Links
 -[Auth0 API Documentation](https://auth0.com/docs/api)
 -[Auth0 as an authentication method for keep](https://docs.keephq.dev/deployment/authentication/auth0-auth)

docs/workflows/state.mdx

@@ -8,7 +8,7 @@ Keep State Manager is currently used for:
 2. Track alerts over time
 3. Previous runs context
 
-State is currently being saved as a JSON file under `./state/keepstate.json`, a path that can be overriden by setting the `KEEP_STATE_FILE` environment variable.
+State is currently being saved as a JSON file under `./state/keepstate.json`, a path that can be overridden by setting the `KEEP_STATE_FILE` environment variable.
 
 ## Example
 One of the usages for Keep's state mechanism is throttling, see [One Until Resolved](/workflows/throttles/one-until-resolved) Keep handles it for you behind the scenes so you can use it without doing any further modifications.
@@ -44,4 +44,4 @@ An example for a simple state file:
 Keep's roadmap around state (great first issues):
 - Saving state in a database.
 - Hosting state in buckets (AWS, GCP and Azure -> read/write).
-- Enriching state with more context so throttling mechanism would be flexer.
+- Enriching state with more context so throttling mechanism would be flexible.

docs/workflows/syntax/basic-syntax.mdx

@@ -4,7 +4,7 @@ description: "At Keep, we view alerts as workflows, which consist of a series of
 ---
 ## Full Example
 ```yaml title=examples/raw_sql_query_datetime.yml
-# Notify if a result queried from the DB is above a certain thershold.
+# Notify if a result queried from the DB is above a certain threshold.
 workflow:
   id: raw-sql-query
   description: Monitor that time difference is no more than 1 hour
@@ -52,7 +52,7 @@ workflow:
 - Metadata (id, description. owners and tags will be added soon)
 - `steps` - list of steps
 - `actions` - list of actions
-- `on-failure` - a conditionless action used in case of an alert failure
+- `on-failure` - an action with no condition used in case of an alert failure
 
 ### Provider
 ```yaml
@@ -126,5 +126,5 @@ on-failure:
       config: " {{ providers.slack-demo }} "
 ```
 
-On-failure is actually a condtionless `Action` used to notify in case the alert failed with an exception.
+On-failure is actually an `Action` with no condition used to notify in case the alert failed with an exception.
 The provider is passed a `message` (string) to it's `notify` function.

docs/workflows/syntax/context-syntax.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Working with context"
-sidebarTitle: "Content Syntax"
+sidebarTitle: "Context Syntax"
 description: "Keep uses [Mustache](https://mustache.github.io/) syntax to inject context at runtime, supporting functions, dictionaries, lists, and nested access."
 ---
 
@@ -12,7 +12,7 @@ Here are some examples:
 - `keep.first({{ steps.this.results }})` - First result (equivalent to the previous example)
 - `{{ steps.step-id.results[0][0] }}` - First item of the first result
 
-If you have suggestions/improvments/bugs for Keep's syntax, please [open feature request](https://github.com/keephq/keep/issues/new?assignees=&labels=&template=feature_request.md&title=) and get eternal glory.
+If you have suggestions/improvements/bugs for Keep's syntax, please [open feature request](https://github.com/keephq/keep/issues/new?assignees=&labels=&template=feature_request.md&title=) and get eternal glory.
 
 ### Special context
 

docs/workflows/syntax/foreach-syntax.mdx

@@ -1,7 +1,7 @@
 ---
 title: "Foreach"
 sidebarTitle: "Foreach Syntax"
-description: "Foreach syntax add the flexability of running action per result instead of only once on all results."
+description: "Foreach syntax add the flexibility of running action per result instead of only once on all results."
 ---
 
 ## Usage

docs/workflows/throttles/one-until-resolved.mdx

@@ -8,7 +8,7 @@ For example:
 1. Alert executed and action were triggered as a result -> the alert status is now "Firing".
 2. Alert executed again and action should be triggered -> the action will be throttled.
 3. Alert executed and no action is required -> the alert status is now "Resolved".
-4. Alert exectued and action were triggered -> the action is triggered
+4. Alert executed and action were triggered -> the action is triggered
 
 ## How to use
 

examples/workflows/cron-digest-alerts.yml

@@ -2,6 +2,7 @@ workflow:
   id: alerts-daily-digest
   description: run alerts digest twice a day (on 11:00 and 14:00)
   triggers:
+    - type: manual
     - type: interval
       cron: 0 11,14 * * *
   steps:
@@ -10,18 +11,16 @@ workflow:
       provider:
         type: keep
         with:
-          filters:
-          # filter out alerts that are closed
-          - key: status
-            value: open
+          version: 2
+          filter: "status == 'firing'"
           timerange:
-            from: "{{ state.workflows.alerts-daily-digest.last_run_time }}"
+            from: "{{ last_workflow_run_time }}"
             to: now
   actions:
     - name: send-digest
       foreach: "{{ steps.get-alerts.results }}"
       provider:
-        type: slack
-        config: "{{ providers.slack }}"
+        type: console
+        config: "{{ providers.console }}"
         with:
-          message: "Open alert: {{ foreach.value.name }}"
+          message: "Open alerts: {{ foreach.value.name }}"

keep-ui/app/incidents/[id]/incident-activity.tsx

@@ -15,7 +15,7 @@ import {
 import { AuditEvent, useAlerts } from "@/utils/hooks/useAlerts";
 import Loading from "@/app/loading";
 import { useCallback, useState, useEffect } from "react";
-import { getApiURL } from "@/utils/apiUrl";
+import { useApiUrl } from "@/utils/hooks/useConfig";
 import { useSession } from "next-auth/react";
 import { KeyedMutator } from "swr";
 import { toast } from "react-toastify";
@@ -68,7 +68,7 @@ export function IncidentActivityChronoItemComment({
   mutator: KeyedMutator<AuditEvent[]>;
 }) {
   const [comment, setComment] = useState("");
-  const apiUrl = getApiURL();
+  const apiUrl = useApiUrl();
   const { data: session } = useSession();
 
   const onSubmit = useCallback(async () => {