Docs Release 2024-03-004

CHANGELOG.md

@@ -1,6 +1,8 @@
 # Quix product changelog
 
-This is the changelog for the current year. 
+This is the product changelog for the current year. 
+
+See [here](https://github.com/quixio/quix-docs/wiki/Docs-Releases) for the docs changelog.
 
 ## Changelog archives
 
@@ -9,6 +11,140 @@ Changelogs for previous years can be found [here](#changelog-archives).
 * [2022](./changelogs/2022-archive.md)
 * [2023](./changelogs/2023-archive.md)
 
+## 2024-03-02-topic-details-hf | 13 MARCH 2024
+
+`IMPROVEMENTS`
+
+- Topics
+    - Improved performance and memory consumption in Topics message browser feature
+
+`BUG FIXES`
+
+- Fixed "Missing 're-captcha-response' header" error
+- Non-admin users were losing some permissions after editing their name
+- Fixed an error where Users couldn't modify their name
+- Topics message browser feature was not showing RAW messages produced by Quix Streams v2
+- Fixed some errors caused by some Deployment builds being deleted prematurely
+- Fixed an error where users couldn’t introduce new YAML variables in quix.yaml before creating the variable in the environment.
+
+## 2024-03-01-topic-details | 04 MARCH 2024
+
+`NEW FEATURES`
+
+- Topics
+    - Topic detail view: Users can explore information and data on a centralized topic view.
+    - Topic messages browser: Added new options to query data of the topic from Newest, Oldest, or Custom Kafka offsets.
+- Deployments
+    - Real-time build logs: view build logs in real time during the build process.
+- Users
+    - Audit information: admin users can now get audit information of users actions via Quix CLI
+- Other
+    - Added Upstash broker type on the available message brokers integrations
+
+`IMPROVEMENTS`
+
+- Topics
+    - Checkbox for toggling *Topics* view to filter by `Compacted topics`
+- Code samples library
+    - Added support for secrets input type in Code samples library items
+- Personal Access Tokens
+    - Sort by state: active/expired/revoked
+    - Added ability to update token permissions via Quix CLI
+- Applications
+    - User can now modify `app.yaml` from the IDE
+- Secrets
+    - Added *unsaved changes* modal
+    - Updated error UI of invalid secrets
+- Deployment Details
+    - Error icon for when application associated with deployment does not exist
+    - Use `RAW` icon for messages with unknown types
+- YAML
+    - Added Default column on YAML variables so that they can be used on a Project-wide scope
+    - Added `latest` version support for Deployment. Sync process will keep the deployment updated with the latest version of the code available in the branch of the environment.
+    - Starting/stopping a `service` deployment no longer creates a commit in the YAML
+        - Use `DesiredStatus: Running` or `DesiredStatus: Stopped` to define the default running status
+- Pipeline
+    - Pipeline boundaries updated to prevent user getting lost
+- Users
+    - Return email verification link on sign up: Icon in user table, that contains email verification link, when inviting users to an organisation.
+    - Landing page for when a user is not an authorized user of the portal
+    - Added validation when creating a Personal Access Token
+    - Hide user update notifications
+    - Remove email from url when redirecting from the signup confirmation
+    - Added timezone to maintenance page
+- Other
+    - Improved Git service behavior when dealing with big files. Now it will fail before filling the memory of the service.
+    - Reduced the number of calls Git service is doing to the remote relying now more on manual pulls instead of periodic pulls.
+    - Printing full errors returned by *GIT*
+    - Drag supported on onboarding carousel
+    - Disabling/deleting an environment doesn’t kick you out of a *Project* anymore
+    - Pressing `enter` key in dialogues now invoke primary CTA
+    - Reinstated middle-click functionality for links (to open in a new tab)
+    - Alignment of variables displayed in *Applications* and *Deployment details*
+    - Added *Environment name* to error notifications to idenfity which *Environment* the error originated from
+    - Updated external Kafka setup guides
+    - Minor UI styling and alignment fixes
+    - Minor spelling and grammar fixes
+    - Added loading spinners on various CTAs to improve visiblity of click feedback
+
+`BUG FIXES`
+
+- Applications
+    - Modifying a variable now loads app.yaml file again
+    - Switching to a V1 project was trying to call V2 endpoint
+    - Switching to another environment was trying to open the same application in the other environment (returns error if the application doesn’t exist)
+    - Clear *secret key* input field when switching application vairable to a *secret*.
+    - Send session setup with `force` when user clicks “Install dependencies”
+    - `Run` should not move vertical scroll in the code editor
+- YAML
+    - Disable editor when saving changes
+- Topics
+    - Changing retention to a non-numerical value causes the field to be empty
+    - If topic update/create fails, users were unable to revert their changes
+    - Fixed an issue when deleting and recreating a topic using the same name
+- Data explorer
+    - Query selector
+        - switching topic causes the selected streams to disappear but look selected
+        - Location dropdown selection was behaving weirdly
+        - Double `x` icon in stream selection
+        - *Persist* option disappears if it triggers *out-of-sync* modal
+        - If *search* returns no results, *next* button is disabled, even if there are streams selected (The modal thinks nothing is selected)
+        - If *search* returns no results, the empty-state text displayed was incorrect
+    - Code is not resizing when resizing the panel
+    - Toggling *aggregation* sometimes rendered an empty waveform
+- Code samples
+    - *Create* *application* was calling *projects* (v1) endpoint
+- Pipeline
+    - Disable sync button for ungated users
+    - Draft applications with no input and output were not visible
+- Deployment details
+    - Previous logs from a crashed deployment were not retrieved correctly
+    - Clicking cancel on a docker file download caused it to be stuck in a loading state
+    - Clicking *edit code* was navigating to latest version, not the deployed version
+    - Missing tooltip when topic metrics were loading
+    - Deploying was not navigating user to deployment details
+    - Paginated scrolling in logs were not working
+    - Refreshing the page in an external source/destination was rendering a blank screen
+- Deployment modal
+    - “Missing secret” still visible, even after adding said missing secret
+    - Disabling statesize should not trigger a `Reducing StateSize is not allowed` error
+- Ungated demo
+    - Urls weren’t navigating user directly to a workspace
+    - Disable sync button on header
+    - Banner height was pushing content off the screen
+    - Cloning a template while logged into the platform in another tab cause the other tab to reload in a half-ungated state
+- Persisted data
+    - Dialogue was not appearing when *unpersisting* a topic
+    - Updated empty state and disabled next &
+- Users
+    - Disable email field if you are editing your own user
+    - *Disable account* dialogue CTA was stuck in loading state
+    - UI getting stuck on loading screen during onboarding
+    - Removed link to *billing* on “Payment confirmed” modal during onboarding
+- Other
+    - Various external links fixed
+    - Local storage issues causing `undefined` for repository/workspace ID arguments in network calls
+
 ## 2024-01-06 | 30 JANUARY 2024
 
 `BUG FIXES`

docs/develop/integrate-data/read-csv.md

@@ -14,7 +14,7 @@ You'll need a streaming token to authenticate with Quix if you're going to run a
 
     In Quix Cloud, the streaming token is automatically set in the project environment.
 
-Once you [get your streaming token]((../../develop/authentication/streaming-token.md)), you can subsequently load it from a suitable `.env` file:
+Once you [get your streaming token](../../develop/authentication/streaming-token.md), you can subsequently load it from a suitable `.env` file:
 
 ```
 Quix__Sdk__Token="<your_streaming_token>"

docs/integrations/databases/influxdb/migrating-v2-v3.md

@@ -0,0 +1,65 @@
+# Migrating InfluxDB from v2 to v3
+
+If you have data in a v2 InfluxDB database, and you want to migrate it to InfluxDB v3, then Quix can help.
+
+Quix provides the following InfluxDB [connectors](../../../connectors/index.md):
+
+* InfluxDB v2 source
+* InfluxDB v3 source
+* InfluxDB v3 destination
+
+A summary of the procedure is:
+
+1. Add the Quix InfluxDB v2 connector to Quix, to connect your InfluxDB v2 database to Quix.
+2. Add the Quix InfluxDB v3 connector to Quix, on the output of your InfluxDB v2 connector.
+
+You'll have the following pipeline:
+
+![Migration pipeline](../../../tutorials/influxdb-migration/images/influxdb-migration-pipeline.png)
+
+Data is read from InfluxDB v2 and published to InfluxDB v3. 
+
+No coding is required, unless you also want to make changes to data as it is migrated. If you want to do this you can add a transform (or multiple transforms) between the two connectors.
+
+## Configuring the source connector
+
+You'll need to configure the following variables for your source connector:
+
+| Environment Variable | Description|
+|---|---|
+| `output` | Output topic. Add a new topic called `influxdb-v2-data`. |
+| `INFLUXDB_DATABASE` | Database name in InfluxDB where the data is stored. In InfluxDB this is also called a bucket. |
+| `INFLUXDB_HOST` | Host address for the InfluxDB instance. Default: `eu-central-1-1.aws.cloud2.influxdata.com`. |
+| `INFLUXDB_ORG` | Organization name in InfluxDB. |
+| `INFLUXDB_TOKEN` | Authentication token to access InfluxDB. Configure as a secret type, so that your token is never revealed. |
+| `task_interval` | The polling period for queries of the database. Set this to `1s` (one second) to ensure you see any new data promptly (this make testing a little easier as you don't need to wait too long for updates). |
+
+!!! tip
+
+    To see more documentation on these variables, and examples, you can refer to the [detailed README](https://github.com/quixio/template-influxv2-to-v3?tab=readme-ov-file#influxdb-v2-source){target=_blank}.
+
+## Configuring the destination connector
+
+You'll need to configure the following variables for your destination connector:
+
+| Environment Variable | Description|
+|---|---|
+| `input` | Input topic. Example `influxdb-v2-data`. |
+| `INFLUXDB_DATABASE` | Database name in InfluxDB where the data is stored. In InfluxDB this is also called a bucket. |
+| `INFLUXDB_HOST` | Host address for the InfluxDB instance. Default: `eu-central-1-1.aws.cloud2.influxdata.com`. |
+| `INFLUXDB_ORG` | Organization name in InfluxDB. |
+| `INFLUXDB_TOKEN` | Authentication token to access InfluxDB. Configure as a secret type, so that your token is never revealed. |
+| `INFLUXDB_FIELD_KEYS` | These are the columns of rows of data that you want to write to the InfluxDB v3 database. |
+| `INFLUXDB_TAG_KEYS` | The metadata that you want to write to the InfluxDB v3 database. |
+
+!!! tip
+
+    To see more documentation on these variables, and examples, you can refer to the [detailed README](https://github.com/quixio/template-influxv2-to-v3?tab=readme-ov-file#influxdb-v3-sink){target=_blank}.
+
+## See also
+
+If you are new to Quix you could try our [Quickstart](../../../get-started/quickstart.md) and then complete the [Quix Tour](../../../get-started/quixtour/overview.md). This gives you a good overview of how to use Quix, for a minimal investment in your time.
+
+There is an [in-depth step-by-step tutorial](../../../tutorials/influxdb-migration/overview.md) available on migrating InfluxDB v2 data to InfluxDB v3.
+
+A tutorial featuring a more complex pipeline is also available. See the [InfluxDB alerting tutorial featuring PagerDuty](../../../tutorials/influxdb-alerting/overview.md).

docs/integrations/databases/influxdb/overview.md

@@ -17,7 +17,9 @@ Quix currently supports the following connectors for InfluxDB:
 | [InfluxDB 3.0](https://github.com/quixio/quix-samples/tree/main/python/sources/InfluxDB){target=_blank} | Source | Enables you to publish data from an InfluxDB v3 bucket into a Quix topic. |
 | [InfluxDB 3.0](https://github.com/quixio/quix-samples/tree/main/python/destinations/InfluxDB){target=_blank} | Destination | Enables you to publish data from a Quix topic into an InfluxDB v3 bucket. |
 
-Note if you want to move data from InfluxDB v2 to v3 you could use the v2 source and v3 destination to do this.
+!!! tip
+
+    If you want to [migrate data from InfluxDB v2 to v3](./migrating-v2-v3.md) you could use the Quix InfluxDB v2 source and v3 destination connectors to do this.
 
 <div>
 <a class="md-button md-button--primary" href="../influxdb/quickstart.html" style="margin-right:.5rem;">Try the Quickstart</a>

docs/integrations/databases/influxdb/replacing-kapacitor.md

@@ -0,0 +1,46 @@
+---
+title: Replacing Kapacitor with Quix
+description: Shows how to use Quix to replace Kapacitor. Instead of using Kapacitor to run Flux or TICKscript tasks, use Quix Streams, and Python to implement your processing pipeline, and run them it Quix.
+search:
+  boost: 3
+---
+
+# Replacing Kapacitor
+
+It's possible to replace Kapacitor with Quix. The basic process is:
+
+1. Use Quix's prebuilt connectors to connect to InfluxDB v2 or InfluxDB v3 databases, as required.
+2. Implement your Flux or TICKscript tasks in Python, using the Quix Streams client library. 
+
+The code you create to query and process your InfluxDB data runs in Quix, and has all the flexibility of using Python. Quix Streams also includes many common processing facilities, such as aggregations, windowing, filtering, and so on, reducing the amount of code you need to write.
+
+The following illustrates a typical processing pipeline running in Quix.
+
+![Processing pipeline](../../../tutorials/influxdb-alerting/images/alerting-pipeline.png)
+
+## Kapacitor / Quix feature comparison
+
+| Feature | Kapacitor | Quix |
+|----|----|----|
+| Streaming data processing | Kapacitor enables users to process streaming data in real-time, enabling actions to be taken as soon as data is received. | Quix was built from the ground up as a stream processing platform. |
+| Data processing tasks | Kapacitor supports a variety of data processing tasks such as downsampling, aggregations, transformations, and anomaly detection. These tasks can be defined using TICKscript, a domain-specific language (DSL) specifically designed for Kapacitor. | Quix uses Python as its main programming language. Code is implemented using the Quix Stream Python stream processing client library. [Quix Streams](https://quix.io/docs/quix-streams/introduction.html) has many built-in stream processing features such as aggregations, windowing, and filtering. Read the guide on how to [replace Flux/TICKscript](./replacing-flux.md) with Quix Streams. |
+| Alerting and monitoring | Kapacitor enables users to define alerting rules based on predefined conditions or anomalies detected in the data. Alerts can be sent through various channels such as email, Slack, PagerDuty, etc. | Quix supports alerts by writing code in Python to detect events and determine if thresholds have been crossed. Connectors to alerting services are provided, or can easily be added with minimal code. For a detailed example read the [InfluxDB alerting with Quix Streams and PagerDuty tutorial](../../../tutorials/influxdb-alerting/overview.md). |
+| Integration with InfluxDB | Kapacitor seamlessly integrates with InfluxDB, enabling users to perform advanced analytics and processing on the time-series data stored in InfluxDB. | Quix connects to both InfluxDV v2 and InfluxDB v3 using prebuilt connectors. The v3 connectors include both source and sink. For v2, only source is currently available. If you want to migrate data from InfluxDB v2 to InfluxDB v3 then read [the tutorial](../../../tutorials/influxdb-migration/overview.md). |
+| Scalability | Kapacitor is designed to be horizontally scalable, enabling it to handle large volumes of data and scale alongside the rest of the TICK Stack components. | Quix was designed to be both vertically and horizontally scalable. It is based on [Kafka](../../../get-started/what-is-kafka.md), using either a Quix-hosted broker, or an externally hosted broker. This means all the horizontal scaling features of Kafka, such as consumer groups, is built into Quix. Quix also enables you to configure the number of replicas, RAM, and CPU resources allocated on a per-service (deployment) basis, for accurate vertical scaling. |
+| High availability | Kapacitor supports high availability setups to ensure uninterrupted data processing and alerting even in the case of node failures. | As Quix uses a Kafka broker (including Kafka-compatible brokers such as Redpanda), it has all the high availability features inherent in a Kafka-based solution. In addition, Quix uses a Kubernetes cluster to seamlessly distribute and manage containers that execute your service's Python code. |
+| Replay and backfilling | Kapacitor enables users to replay historical data or backfill missing data, enabling them to analyze past events or ensure data consistency. | Quix leverages Kafka's persistence capabilities. Once a topic is persisted, you can use Quix's built-in [replay](../../../manage/replay.md) facility, to replay persisted data into topics. This is useful for testing and evaluating processing pipelines, and examining historical data. This is also enhanced by the ability to use the built-in Quix Data Explorer, or connect to external tools, using Quix connectors. |
+| Extensibility | Kapacitor provides an extensible architecture, enabling users to develop and integrate custom functions, connectors, and integrations as per their specific requirements. | Quix is fully extensible using Python. Complex stream processing pipelines can be built out one service at a time, and then deployed with a single click. It is also possible to use a wide range of standard [connectors](../../../connectors/index.md) to connect to a range of third-party services. Powerful [integrations](../../overview.md) extend these capabilities. In addition, [REST and real-time APIs](../../../develop/apis-overview.md) are available for use with any language that supports REST or WebSockets. As Quix is designed around standard Git development workflows, it enables developers to collaborate on projects. |
+
+## See also
+
+Read the [general overview of Quix](../../../get-started/what-is-quix.md).
+
+If you are new to Quix you could try our [Quickstart](../../../get-started/quickstart.md) and then complete the [Quix Tour](../../../get-started/quixtour/overview.md). This gives you a good overview of how to use Quix, for a minimal investment in your time.
+
+You can read more about [stream processing](../../../get-started/why-stream-processing.md).
+
+You can read more about Kafka in our [What is Kafka?](../../../get-started/what-is-kafka.md) documentation.
+
+You can read the guide on [Replacing Flux with Quix Streams](./replacing-flux.md), which includes some common use case examples.
+
+The [predictive maintenance tutorial](../../../tutorials/predictive-maintenance/overview.md) provides a large scale example of what you can do with Quix, Quix Streams, and InfluxDB.

docs/tutorials/clickstream/overview.md

@@ -1,5 +1,9 @@
 # Clickstream analysis
 
+!!! warning
+
+    This tutorial uses a template that is implemented with a deprecated version of Quix Streams (v0.5). For a tutorial that uses [Quix Streams v2](https://quix.io/docs/quix-streams/introduction.html) read the [InfluxDB alerting tutorial](../influxdb-alerting/overview.md).
+
 In this tutorial you learn about a project template that analyzes a clickstream in real time, and generates events based on behavior. You use Python, rather than kSQL to perform aggregations and implement event logic based on user behavior.
 
 This tutorial uses the [Quix Clickstream analysis template project](https://github.com/quixio/template-clickstream){target=_blank}.