#5378
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Enhanced error handling for invalid stream names during ingestion,
ensuring appropriate logging and response for empty or invalid entries.
- Updated assertions in tests to reflect the correct handling of invalid
bulk payloads by the API, ensuring errors are present for invalid
submissions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: hengfei yang <hengfei.yang@gmail.com>
There are 3 types of partial responses:
1. VRL error
2. Super cluster error
3. Range error (max_query_limit)
Cache partial results only if there is a range error.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced search functionality with improved error handling for query
ranges.
- Introduced caching logic for partial results based on specific error
conditions.
- **Bug Fixes**
- Streamlined response generation and error reporting in search-related
functions, ensuring clarity and efficiency.
- **Documentation**
- Updated method signatures to reflect the latest changes in
functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: oasisk <ashish.j.kolhe@gmail.com>
In this [other PR
](https://github.com/openobserve/openobserve/pull/5390) I need to be
able to add logic to create a default "alerts" folder.
In order to do that, we first need to enable callers to pass a
`folder_type` parameter to different internal methods for
getting/creating/updating/deleting/listing folders. Previously those
methods assumed that the folder type was always `Dashboards` since thus
far that was the only folder type that existed.
This fixes two bugs -
1. The _values api used `Count(*)` function in query to get count.
However in case of distinct streams we already aggregate the count in
`count` field. Thus we need to use `sum(count)` instead.
2. In https://github.com/openobserve/openobserve/pull/5220 , the logic
which adds/removes the distinct values when dashboard is added/deleted
was removed accidentally. This Also re-adds that logic back.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced bulk deletion of dashboards with associated distinct
values.
- Added new methods for managing distinct fields in dashboards.
- Enhanced search functionality with improved handling of distinct
streams.
- **Bug Fixes**
- Improved error handling for dashboard operations and search requests,
including new error messages.
- **Documentation**
- Updated documentation for methods to clarify functionality and usage.
- **Refactor**
- Streamlined query variable extraction logic for dashboards.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Signed-off-by: Yashodhan Joshi <yjdoc2@gmail.com>
Co-authored-by: Yashodhan Joshi <yjdoc2@gmail.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new endpoint for listing user roles, excluding certain
roles.
- Added a new endpoint for token exchange requests for service accounts.
- **Enhancements**
- Improved role management logic and error handling in user management
functions.
- Enhanced error handling for authentication and token validation
processes.
- Updated the handling of claims and user roles based on login flow.
- Enhanced the logic for retrieving login URLs and managing
authentication states.
- **Bug Fixes**
- Prevented unauthorized updates and retrievals for external service
accounts.
- **Documentation**
- Updated method signatures to reflect new parameters and functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
#4871#5127
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Introduced a new "sankey" chart type in the chart selection.
- Added a configuration section for trellis layouts in dashboard panel
settings.
- Enhanced error handling and data validation for various panel types.
- New utility function `deepCopy` for creating deep copies of objects.
- Enhanced grid management capabilities for trellis layouts.
- Improved rendering logic for charts and dynamic height adjustments.
- Introduced new computed properties for dynamic chart panel height and
trellis configuration.
- New parameter `chartPanelStyle` added for enhanced customization in
data conversion.
- Improved handling of no data scenarios for metric and heatmap panel
types.
- Added new localization keys for layout and dashboard settings.
- **Bug Fixes**
- Improved error messages for dashboard retrieval and data validation
logic.
- **Documentation**
- Expanded localization options for layout and dashboard settings.
- **Chores**
- Minor formatting and consistency improvements across multiple files.
- Added trailing commas for improved code consistency in various files.
- Updated import paths to reflect codebase restructuring.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new migration for creating an alerts table, enhancing the
database capabilities.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced access control by preventing the removal of root users from
organizations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Hengfei Yang <hengfei.yang@gmail.com>
Fix the env variable name for the HASH URL
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Updated the environment variable name for improved accuracy regarding
the ASN database.
- **Documentation**
- Clarified the naming of the configuration fields to better reflect
their purposes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced precision for storage size metrics across various components
by updating data types to floating-point numbers.
- **Bug Fixes**
- Adjusted calculations for size metrics to ensure accurate
floating-point operations.
- **Chores**
- Updated test cases to reflect new floating-point type handling for
storage metrics.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
# Summary
This is preparatory work for migrating Alerts into folders as part of
#5253 .
# Context
The migration logic inside `/src/common/migration/schema.rs` currently
references a number of data structures and logic that are defined
outside of this migration module. Specifically...
- The migration script references various `set...` functions and a
`delete...` functions from the `service::db` module which serialize
alerts (and other data structures) into JSON and write them to the
`meta` table in the DB.
- The migration script references various data structures from the
`config::meta` module and uses the JSON serialization and
deserialization logic derived on those structs to read and write the
data structures to the `meta` table as part of the migration.
This poses a number of risks:
1. Most immediate: The behavior of the referenced `set..` and
`delete...` functions from the `service::db` module will be changing
extremely soon as part of my work to migrate Alerts out of the `meta`
table and into their own `alerts` table. These functions will be changed
to interact with the `alerts` table rather than the `meta` table.
Therefore, if this migration script continues to reference those
functions then it's behavior will be completely changed - leading to
inconsistent and likely unpredictable results when different clients run
the migration starting from different application versions.
2. Less immediate:
- Since the migration currently uses the serialization/deserialization
logic derived on structs defined in `config::meta`, any change to those
structs (even non-breaking API changes like the addition of a new field)
could result in changes to the behavior of the migration script
itself....
- ...And I think it's important for long-term stability and
maintainability that developers be able to make non-breaking API changes
to those data structures without accidentally breaking an existing
migration, especially since the compiler would not be able to catch any
such errors.
- ...More practically, my understanding is that we plan to overhaul the
structure of `Alert`s at some point in the future. If the logic in this
migration module continues to reference that data structure then that
change could also break this migration script.
# Alternatives
I realize that a main point of concern with this PR may be the fact that
we are copying all structs that are serialized or deserialized into this
module. If we still strongly object to including this additional code in
the migration script I think there are two alternatives, outlined below.
**Alternative 1 - Don't worry about the referenced structs and continue
referencing the data structs in `config::meta`**
The first alternative is that we can just keep referencing the data
structs in `config::meta`. Personally, I think this is risky for reasons
outlined above, but it could work as long as we are careful that those
structs do not change. (Though, as mentioned, this seems like it will
happen eventually.)
**Alternative 2 - Serialize/deserialize the objects into
`serde_json::Value` rather than `Alert` or other structs**
If we want to mitigate the risks I described while avoiding copying a
large chunk of code into this module, we could refactor the migration
logic so that rather than deserializing/serializing to/from structs in
`config::meta` we could instead deserialize/serialize to/from the
`serde_json::Value` type. We would have to update the logic in the
migration script a bit to account for the reduced type guarantees due to
working with JSON objects rather than an actual Rust structs, but I
think this could definitely work. (And this is probably what I would do
if I were writing a migration like this from scratch.)
My one concern with this approach is just I'm more worried about
introducing a change/bug into the logic of this script with this
approach than I would be with copying the currently referenced structs
into a submodule. However this isn't an extremely large concern.
# Update 2024-12-13
As of `v0.14.0` this migration script has been deprecated. It will
remain in the codebase until it is removed in `v0.17.0`. Therefore, I
feel like the particular approach we decide to take here will have less
long-term ramifications than I originally imagined.
My own bias continues to be to go with the approach in this PR since
this PR is now blocking another task I'm working on, all the extra code
and structs that are added in this PR will be removed in `v0.17.0`, and
this continues to be the lowest-risk approach I can think of (though
given the upcoming deletion of this script, the other approaches may
have limited risk as well).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Introduced a new `meta` module for improved migration logic.
- Added methods for managing alerts, destinations, and templates,
enhancing migration capabilities.
- **Documentation**
- Added detailed comments in the `meta` module to clarify function
purposes and data structures.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
#5307
### Summary
From the issue description:
> We would like to deprecate various old migrations. If these migrations
are marked as deprecated in v0.14.0, then they will be officially
removed from the app initialization logic in v0.17.0.
>
> The ramification of this is that users will not be able to upgrade
directly from versions < 0.14.0 to versions >= v0.17.0. Instead, for
example, a user on v0.13.0 would first need to upgrade to v0.14.0, and
then from v0.14.0 they could upgrade to v0.17.0.
>
> Removing these migrations will reduce the risk that the behavior of
some of these migrations, particularly those that reference data
structures or logic in other parts of the application code base,
accidentally changes in the future resulting in inconsistent migration
behavior.
### Technical details
This PR just marks certain sections of the code as deprecated. This
deprecated logic will be removed some time after v0.17.0.
### 📣 Note to reviewers
Please comment on any additional migrations that we would like to
deprecate for v0.14.0 and I can include it in this PR. Or feel free to
commit to this branch to mark additional migrations as deprecated. If
you commit to this branch please use the `#[deprecated]` attribute if
possible or include the word `deprecated` in a comment on the code; I
plan on searching the source code for the word `"deprecated"` after
v0.17.0 to remove the deprecated code, so this would help with that.
### Todo in v0.14.0 release
We will want to include information in our official v0.14.0 release
notes about...
- The deprecation of migration/upgrade logic
- The incompatibility of direct upgrades from < v0.14.0 to >= v0.17.0
- Instructions for upgrading from < v0.14.0 to >= v0.17.0
- Users will first need to upgrade to some version >= v0.14.0 and <
v0.17.0. And then they will be able to upgrade to v0.17.0
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced error handling for the `delete-parquet` command, providing
clearer feedback on deletion success or failure.
- Added deprecation warnings for several commands and functions,
indicating future removals.
- **Bug Fixes**
- Improved feedback for unsupported components in the `view` command.
- **Documentation**
- Added comments clarifying the deprecation status of certain migration
logic and functions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
impl #5273
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a method to enrich dashboard-related context in search
events.
- Added a new field to specify the index type in search requests.
- Implemented a new function to retrieve a dashboard and its associated
folder by their IDs.
- Enhanced usage data ingestion for detailed processing of search
events.
- **Bug Fixes**
- Improved error handling for reporting usage data, ensuring robustness.
- **Refactor**
- Updated function signatures for in-place modifications of usage data.
- Minor cosmetic adjustments for clarity in report handling processes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR introduces the service accounts with tokens
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
- **New Features**
- Introduced a new module for managing service accounts, including
functionalities for listing, creating, updating, and deleting service
accounts.
- Added a new tab for "Service Accounts" in the Identity Access
Management interface.
- Enhanced user management interfaces to support service account
operations, including the ability to add and edit service accounts.
- Implemented a new component for managing service accounts within
groups and roles.
- Added new API endpoints for service account management, including
token operations.
- Introduced a comprehensive Vue component for managing service accounts
with enhanced features, including filtering, searching, and token
management.
- Enhanced permission checks and error handling for service accounts
across various functions.
- Added support for external user permissions in service account
operations.
- Enhanced error handling for various components to prevent unnecessary
notifications on permission-related issues.
- Added localization support for service account functionalities,
providing necessary labels for user interface elements.
- **Bug Fixes**
- Improved error handling and validation across user management and
service account functionalities.
- **Documentation**
- Updated localization files to support new service account features and
labels.
- **Style**
- Adjusted styles in various components to enhance usability and
consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: oasisk <ashish.j.kolhe@gmail.com>
Co-authored-by: Subhradeep Chakraborty <chakrabortysubhradeep556@gmail.com>
Previously the `GetDashboard` and `DeleteDashboard` endpoints required
the client to pass in the `folder_id` query parameter. The query
parameter was actually superfluous because the `org_id` and
`dashboard_id` URL parameters provided to each endpoint already uniquely
identified a dashboard. Therefore, this PR removes `folder_id` as a
query parameter from those endpoints.
This PR introduces the optional `page_size` query parameter to the
`ListDashboards` endpoint. When set this will limit the size of the
result set to the specified value. The client/frontend will be able to
set this query parameter in calls to `ListDashboards` to limit the
number of results returned - specifically in requests to search
dashboards across folders.
This PR only implements limiting the result set size and does not
actually expose pagination as functionality of the `ListDashboards`
endpoint. My hope however is that this implementation will put us in a
good place to easily expose pagination on this endpoint if that's
something we want to do in the future - though it would by no means be
necessary.
There are a couple of idiosyncrasies here.
1. The `ListDashboards` endpoint does not read or use any `page_idx` or
`page_number` query parameter, as one might expect from a paginated
endpoint. Therefore if the client sets the `page_size` parameter to some
number N then the `ListDashboards` endpoint will always return the top N
results. (Considered in a different way, the endpoint always acts as if
the requested page index is `0`.)
- In the future we might want to add an additional `page_idx` query
parameter as well to enable "true" pagination (rather than simply
limiting the result set to the first N results). However there are no
immediate plans for this.
2. The `page_size` query parameter is only read/used by the endpoint
when the `title` parameter is **also** set. This means that when the
`title` parameter is **not** set the endpoint will ignore the
`page_size` parameter and will always return all dashboards that match
the other query parameter, `folder`.
- In the future we could choose to use this parameter any time it is
provided, not just when `title` is also provided. To do that there would
need to first be an update to the UI to address the issue described
below.
- For the time being this is necessary in order to not break the UI.
This is because currently the UI always sends the query parameter
`page_size=1000` to the endpoint, even though before now that query
parameter was never recognized by the endpoint. Additionally, the UI
assumes that the calls it makes to `ListDashboards` in order to show the
dashboards in a selected folder always return **all** dashboards, and in
such requests the frontend sets the `folder` query parameter but not the
`title` query parameter. Therefore, if we actually to use the
`page_size` parameter in **those** requests, then in its current
implementation the UI would fail to show all dashboards when a folder
with over 1000 dashboards is selected.
## Summary
This PR only refactors code and should not result in any behavioral
changes.
This PR follows #5220 and creates separate "HTTP Layer" models for each
our dashboard HTTP API endpoints.
By separating the "HTTP Layer" models from the "Service Layer" dashboard
models we will now (in future PRs) be able to...
- add folder name and folder ID fields to each item returned by the
`ListDashboards` endpoint - Step 3 of #5198
- remove dashboard details from the each item returned by the
`ListDashboards` endpoint - Step 1 of #5196
Unfortunately, this PR does not yet accomplish fully decoupling the
"HTTP Layer" dashboard model from the "DB Layer" dashboard model since
both layers still use the same same JSON de/serialization logic defined
on the structs inside `config/meta/dashboards`. So changes to that model
and the corresponding JSON de/serialization logic could still introduce
silent breaking changes into both the interface with the DB and the HTTP
API. This PR moves us closer to decoupling those models, though future
work will be necessary to fully decouple them.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced new data structures for handling dashboard-related HTTP
requests and responses, enhancing clarity and type safety.
- Added support for creating, updating, and listing dashboards with
structured request and response bodies.
- **Documentation**
- Updated OpenAPI documentation to reflect new schemas for dashboard
operations, improving API clarity and specificity.
- **Refactor**
- Removed outdated dashboard structures and streamlined request handling
logic for improved maintainability.
- Updated integration tests to align with the new dashboard data
structures.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
This PR only refactors code and should not result in any behavioral
changes.
This PR follows #5206 and attempts to refactor dashboards in a similar
way to how that PR refactors folders. This PR aims to divide our
dashboard code into distinct "HTTP Layer" and "Service Layer"s - where
the "HTTP Layer" contains only logic and models related to
serializing/deserializing for the REST HTTP API, and the "Service Layer"
contains only domain models/logic and is agnostic to the REST HTTP API.
This PR only partially achieves the above goals. Specifically, it makes
following changes...
1. Move all HTTP responses out of the `service` module and and into the
`http/request` module.
2. Introduce a new `DashboardError` in the `service` module to model all
types of "domain logic" errors that occur when interacting with folders.
3. Remove the `service/db/folders` module since, after the migration of
folders from the `meta` table to the `folders` table, this module mostly
just acted as a wrapper around the `infra/table/folders` module.
This PR is still missing the following changes. These changes will be
saved for a subsequent PR in order to keep the scope of this PR limited:
- Introduce new `...Response` and `...Request` types in the
`http/request/models` module whose role is specifically to define
serialization/deserialization definitions for the REST HTTP API.
⚠️ Notably, at this point the "HTTP Layer", "Service Layer", and "DB
Layer" models for dashboards are still tightly coupled together since
all still use the shared JSON serialization/deserialization logic
defined on the shared `Dashboard` struct in `config::meta`. Decoupling
the models and de/serialization logic at each layer will take more
effort than folders since the `Dashboard` struct is large and
complicated. I plan to start on this decoupling in the follow-up PR,
though that PR likely won't complete the process.
## Overall design goals
The design goals here are the same as in #5206 . Please see that PR's
description for a detailed explanation.
## Immediate motivation and next steps
Motivations and next steps are generally the same as in #5206 . Please
see that PR's description for a detailed explanation.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
- **New Features**
- Enhanced dashboard creation and update processes with improved error
handling and response management.
- Added support for parsing dashboard data across multiple versions.
- **Bug Fixes**
- Streamlined error handling for dashboard operations, ensuring more
consistent and informative responses.
- **Chores**
- Refactored dashboard management logic to remove unnecessary
complexity, improving maintainability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
This PR only refactors code and should not result in any behavioral
changes.
This PR divides our folder code into distinct "HTTP Layer" and "Service
Layer"s - where the "HTTP Layer" contains only logic and models related
to serializing/deserializing for the REST HTTP API, and the "Service
Layer" contains only domain models/logic and is agnostic to the REST
HTTP API.
Specifically, the following changes are made to the code...
1. Move all HTTP responses out of the `service` module and and into the
`http/request` module.
2. Introduce a new `FolderError` in the `service` module to model all
types of "domain logic" errors that occur when interacting with folders.
3. Introduce new `...Response` and `...Request` types in the
`http/request/models` module whose role is specifically to define
serialization/deserialization definitions for the REST HTTP API.
4. Remove the `service/db/folders` module since, after the migration of
folders from the `meta` table to the `folders` table, this module mostly
just acted as a wrapper around the `infra/table/folders` module.
## Overall design goals
The design goal here is to create a clearer divide between the "HTTP
Layer" and "Service Layer" of the application and to decouple the models
in these layers so that models in one layer can change without
introducing breaking changes to models in the other layer. Changes to a
model in one layer only need to be accompanied with appropriate changes
to the translation functions between that model and others.
## Immediate motivation and next steps
I would like to replicate this pattern with Dashboards as well as Alerts
and Reports. Implementing this pattern in Folders seems like a
reasonable place to start since Folders are much less complicated that
Dashboards or Alerts, and Dashboards (and soon-to-be Alerts) are
dependent on Folders since each Dashboard belongs to a parent Folder.
With Dashboards, I have an immediate need to divide "HTTP Layer" and
"Service Layer" models because as parts of #5198 and #5196 I need to
change the data structure of dashboards that are returned by
`ListDashboards` so that they are different from the `Dashboard` data
structure defined in the "Service Layer" - specifically I need each
"dashboard" returned by `ListDashboards` to contain the parent folder's
name and ID, and I need each "dashboard" returned by `ListDashboards` to
exclude the details inside the `v1`,...,`v5` fields.
Additionally, when implementing the migration of dashboards from the
`meta` table to the `dashboards` table, I ran into a lot of avoidable
bugs because our "HTTP Layer", "Service Layer", and "DB Layer" models
for dashboards are all coupled together - reusing the same structure and
serialization/deserialization logic. Therefore, when I changed the model
in which we stored dashboards in the DB, this also accidentally
introduced a breaking change (with no compiler error) to the way
dashboards are serialized/deserialized in the HTTP API. Maintaining
separate models and translation functions for these 3 layers would have
prevented these issues. Therefore, when I start migrating alerts to
there own table, I would like to start by dividing our models for alerts
into "HTTP Layer", "Service Layer", and "DB Layer" models to avoid the
same problems I faced while migrating dashboards.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
- **New Features**
- Introduced new data models for folder management in the API, enhancing
request and response structures.
- Added an asynchronous function to check for folder existence by ID.
- **Improvements**
- Enhanced error handling with a new `FolderError` enum for better
clarity in folder management operations.
- Improved type safety by specifying request body types for folder
creation and updates.
- Refactored folder management API endpoints for clearer response
structures.
- **Bug Fixes**
- Updated folder management API endpoints to ensure more accurate
responses and error handling.
- **Documentation**
- Updated OpenAPI documentation to reflect new folder management schemas
and remove outdated components.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
In my previous PR for distinct values,
https://github.com/openobserve/openobserve/pull/5087 the schema defined
for `distinct_values_fields` table did not work with mysql, and OO
failed to start. In this PR I fix that by updating the schema.
The core issue was that mysql does not allow unbounded (text) data type
cols in its index/primary keys whereas sqlite and pgsql do. To fix the
issue, I have updated the table schema to instead used bounded length
columns. The following considerations has been done for size
determination :
- origin, stream_type and origin_id are given size based on sensible
estimates of what the length of possible values could be
- org and stream_name is matched with org in file_llist table
- field_name is given remaining size around power of 2.
The limit is `sum of sizes *4 <=3072 `.
I have tested this on
- new sqlite, mysql, pgsql to make sure this scheme works with all three
dbs
- existing sqlite and pgsql db, where code form current main was run,
and the table was already created. This works with them too, so it is
backward compatible.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Increased maximum length for several database fields, enhancing data
storage capabilities.
- Updated field types in the data model for better structure and
clarity.
These changes improve the application's ability to handle larger data
inputs while maintaining data integrity.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Signed-off-by: Yashodhan Joshi <yjdoc2@gmail.com>
Co-authored-by: Yashodhan Joshi <yjdoc2@gmail.com>
Addresses the first point of #4996
Alert emails currently sends the alert template body as a html content.
This might create problems for email clients that does not
prefer/support html content. This PR addresses this issue by offering
both text and html version of the same message. Email clients can now
use whatever version it prefers.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced email notifications to support both plain text and HTML
formats, improving compatibility with various email clients.
- **Bug Fixes**
- Adjusted email message construction for better rendering in email
clients without altering the overall functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
As mentioned in the comments of #4996
- [x] When using row templates with emails, O2 automatically adds `\n`
at the last of the row in email body. Since, email body is currently
treated as html body, the below row template -
```
<p> This is an event {alert_start_time} </p>
```
generates this email body -
```
This is an event 2024-12-02T11:25:40
\n
This is an event 2024-12-02T11:26:40
\n
This is an event 2024-12-02T11:27:40
\n
...
```
- [x] Adds new variables to represent when the alert got evaluated -
`alert_trigger_time` (unix timestamp in microseconds) and
`alert_trigger_time_str` (formatted, e.g. - `2024-12-02T11:27:40`)
- [x] Update document add `alert_trigger_time` and
`alert_trigger_time_str`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Enhanced alert notifications with improved timestamp handling.
- Updated alert template documentation to include new variables for
better clarity.
- **Bug Fixes**
- Refined error handling in the notification sending process for better
logging and context.
- **Documentation**
- Added documentation for new variables in the alert template section to
assist users in utilizing timestamps effectively.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
fix#5218
Backend:
- [x] allow condition node to evaluate `null` and `""`, empty, for both
`=` and `!=` conditions
- [x] stop ingestion when resolved dynamic stream name is empty
**How to Use(In ConditionNode):**
To evaluate field value is not empty:
`app_name != ""`
To evaluate field value is not null:
`app_name != null`
Fixes#5009
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced email validation for alert destinations to ensure consistent
formatting (trimmed and lowercased).
- **Bug Fixes**
- Improved error handling during email validation for a more consistent
user experience.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Loakesh Indiranandhengfei yang
Patrick Sullivan
Yashodhan JoshiandYashodhan Joshi
Ashish Kolhe
Omkar Kesarkhane
Taiming Liu
Subhra264andHengfei Yang
Prabhat Sharma
udev
Huaijin
胡同里有猫