- Organizations actions icon not visible
- User section checkbox deselect not working
- Traces session dropdown fix
- Tooltip for stream field item
- New dashboard save button loading
#12351
Fixed RUM middleware in `middleware_data.rs` to extract
`ootags`/`o2tags` from the request body when the field is not present in
URL query parameters. Previously, the middleware only inspected query
parameters for these fields, but the RUM SDK sends them in the request
body.
## Why
User logs confirmed the issue: `ootags raw=None, o2tags raw=None`
appeared consistently in the middleware logs even when the RUM SDK
included tags like `env`, `service`, `version`, and `sdk_version`. Geo
keys (which come from a different extraction path) were unaffected,
narrowing the root cause to query-param-only parsing of
`ootags`/`o2tags`. The RUM SDK sends these tags in the POST body, not as
query string parameters.
## Approach
Added body-parsing logic to read and decode the request body when
`ootags`/`o2tags` are absent from query parameters. The body is parsed
once using `url::form_urlencoded` and merged into the existing key-value
map before the `filter_tags` step runs, ensuring the same downstream
pipeline works unchanged.
---------
Co-authored-by: Neha P <neha@openobserve.ai>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: Shrinath Rao <shnath@openobserve.ai>
Co-authored-by: Neha P <144308844+neha00290@users.noreply.github.com>
- SDR Save Settings trigger point discrepency
- Edit the existing alert - Ai icon is overlapping
- On stream field Scroller is not working
- With other languages, the Side Navigation UI is broken
- Search box dont having any border (List search view )
- text area color not looks proper
- Pipeline history - pagination is not working properly
- iam page default pagination value change
- Org display on top right should have a bigger width - more real estate
can be used there
- Date - picker does not show selection when selection 27th may to 20th
may
- Date - picker also does not handle selection if use selects 27th may
first and 20th may later, it should select the correct date no matter
what user selects the date in.
- when searching across folders in dashboard, it shows no data instead
of skeleton loading
- https://github.com/openobserve/o2-enterprise/issues/1824
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
## Summary
- The previous PR (#12229) fixed most instances of `200GB` in `en.json`
but missed the `open_source.badge_text` key which powers the \"Get
Enterprise Edition\" dialog shown to OSS users
- Fixed: `about.enterprise_offer.open_source.badge_text` → `Free up to
50GB / day`
## Test plan
- [ ] Open the app as an OSS user (no enterprise license)
- [ ] Trigger the Enterprise upgrade dialog
- [ ] Confirm badge reads "Free up to 50GB / day"
🤖 Generated with [Claude Code](https://claude.ai/claude-code)
fixes:
- [x] In the IAM users view, please show the roles assigned to each user
alongside the user (currently not visible). Currently we only show
system roles.
- [x] If a system role has been assigned to an existing user, there's no
way to modify it. we should allow edits.
- [x] Customer expected to be able to set up users/roles ahead of
ingestion, when we click in IAM, it goes there but when we try to
perform operations then it redirects back to data sources section.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
#11936
## What changed
Fixed `TraceDetails.vue` so that `traceServiceMap` captures services
from **all** root span nodes in a trace, not just the first one.
Previously, traces with two or more root spans (e.g., from misconfigured
instrumentation) would show service data only for the first root.
## Why
When a trace has multiple root spans, the service-map waterfall widget
and trace-graph display were incomplete — only the first root's services
appeared. Users investigating instrumentation issues or multi-root
traces (which the existing UI already supports rendering) were missing
service data for the second and subsequent roots.
Summary
Migrated the "Add Dashboard from Gallery" feature from GitHub API to S3
(direct bucket access), removing the GitHub rate-limit dependency, and
updated all corresponding test mocks to match the new S3 XML response
format.
What changed
1. Data source: GitHub API → S3 List Objects V2
The gallery was previously fetched from
api.github.com/repos/openobserve/dashboards/contents, which is subject
to GitHub's rate limiting (60 req/hr for unauthenticated requests). It
now reads directly from the S3 bucket openobserve-datasources-bucket via
the List Objects V2 XML API.
loadDashboards() — folder listing now calls:
GET
https://...s3.amazonaws.com/?list-type=2&prefix=dashboards/&delimiter=/
And parses the XML response via parseS3Folders(), which reads
<CommonPrefixes><Prefix> elements.
handleNext() — file listing inside a folder now calls the same S3
endpoint with a deeper prefix, parsed via parseS3Files() which reads
<Contents><Key> elements.
confirmAdd() — dashboard JSON download changed from
raw.githubusercontent.com/... to the direct S3 object URL.
2. Test mock format: JSON → S3 XML
All tests that mocked fetch were still returning the old GitHub JSON
format ([{name, type}]). Since the component now calls
DOMParser.parseFromString(xml, "application/xml"), the JSON strings were
unparseable as XML, resulting in empty dashboards arrays and causing the
"sort dashboards alphabetically" test to fail with undefined.
Added two helpers (s3FolderListXml, s3FileListXml) and updated every
affected fetch mock to return valid S3 List Objects V2 XML. Also
strengthened a few assertions that were previously passing vacuously (an
empty array also "doesn't contain .github").
---------
Co-authored-by: Shrinath Rao <shnath@openobserve.ai>
Co-authored-by: Bhargav <BJP232004@GMAIL.COM>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
#11841
## What changed
Added `queryParams.stream = effectiveStreamName.value` to the share URL
generation in `TraceDetails.vue` so the stream name is included when
generating a share/short URL.
## Why
When sharing a URL from the Trace Details view, the stream name
parameter was missing from the generated URL. This caused the shared
link to open without the correct stream context, making it unable to
display the trace properly on navigation.
## Approach
The stream name is already resolved by the `effectiveStreamName`
computed property — which handles both embedded mode (via
`props.streamNameProp`) and standalone mode (via
`router.currentRoute.value.query.stream`). The fix simply passes this
value into the `queryParams` object before the URL is serialized.
ktx-mihir
ktx-vaidehi
Subhra264
Bhargav
ktx-akshay
Sai Nikhil
yujinqiu
ktx-riya
Peter Dave Hello
Ashish Kolhe
