Feature Requests

I would like Dark Mode so my eyes don't scorch when using the UI late at night

Summary In Harness FME, custom attributes defined on a traffic type carry a declared data type (String, Set, Number, Semver, Boolean, Date). However, the rule builder UI in the flag definition page lets users pick any matcher regardless of the attribute's declared type. When a runtime mismatch occurs — e.g. an attribute declared as String is referenced by a matcher that expects Set — the evaluator silently returns no-match with no error, log line, or visual indicator. The rule is effectively dead, but appears correctly configured in the UI. Concrete example Custom attribute client_name is declared as String on traffic type account. A rule was created via the UI: client_name is equal acme-corp → serve treatment A The UI label "is equal" maps to backend matcher type EQUAL_SET, which expects the attribute value to be a Set. SDK sends {"client_name": "acme-corp"} (a String, per the attribute declaration). Result: rule silently evaluates to false. The targeted treatment never serves. Default rule fires instead. Request When a user picks an attribute in the rule builder, the UI should: Filter matchers to those compatible with the attribute's declared type. "is equal" (set semantics) should not appear as an option for a String attribute — only String-compatible matchers (is in list, matches, starts with, contains, etc.). Or, at minimum, validate at save time and block / warn when the chosen matcher's expected attribute type doesn't match the declared attribute type, with a clear error message naming the mismatch. Why this matters The current UX is a silent-failure foot-gun: the most natural-sounding option ("is equal") is the wrong one for the most common attribute type (String). The labels "is equal" and "is in list" appear interchangeable to a user who isn't deeply familiar with Split's matcher taxonomy. The actual difference (set semantics vs string semantics) isn't surfaced anywhere in the UI. Because attribute types are already declared on the traffic type, the system has all the info it needs to prevent this — it just doesn't use it. Severity / impact The blast radius can be large and silent: the targeted treatment never actually serves. Medium-to-high. Easy to introduce, hard to detect (looks right in the UI, no error anywhere)

When using the Jfrog artifactory, the image only has 2019 and 2022 version, we need support for 2025 version. Please add it.

The serviceDefinition YAML of an service types K8s,ECS etc is not fully expanding to the harness pipeline YAML.

Problem Statement Currently, personal API tokens created by users in their profile settings can only be deleted by the token owner. This creates a security control gap where administrators have no ability to revoke a user’s API access in scenarios where immediate token revocation is necessary (e.g., compromised accounts, departing employees, security incidents, policy violations). Current State Service account tokens: RBAC controls exist for deletion User profile tokens: Only the user can delete their own tokens No admin override capability exists Requested Functionality Enable account administrators and authorized service accounts to delete user API tokens created at the user profile level. Specific Requirements: Admin users should be able to delete any regular user’s API tokens Service accounts with appropriate account-level permissions should be able to delete regular user’s API tokens Should maintain audit trail of token deletions (who deleted, when, which token) Use Cases Security Incident Response: Immediately revoke tokens for compromised accounts Offboarding: Ensure complete access revocation when users leave Compliance: Enforce token rotation policies Policy Enforcement: Revoke tokens that violate security policies

We are requesting a native integration between Harness and Azure DevOps (ADO) Boards to automatically create work items for pipeline failures. Currently, we attempted to use Harness → ServiceNow integration for incident management, but we faced a major limitation in our operating model: Applications are supported by multiple PODs (teams) ServiceNow requires a single assignment group at ticket creation Harness does not have sufficient context to dynamically determine the correct assignment group This results in: Incorrect incident routing Manual reassignment efforts Increased MTTR and reduced operational efficiency To address this, we are moving toward using ADO Boards for failure tracking, where: Work items can be mapped to area paths / teams Ownership can be aligned more accurately with POD-based support models

Add dark mode option to Gitness UI

When using hc iacm plan for remote execution, the CLI only streams logs from one step at a time. If your pipeline uses parallel steps (common for IaCM workspaces running Terraform/OpenTofu plans concurrently), only one branch's output appears in the terminal whereas the other branches are completely silent until execution finishes. ## What we need The CLI should stream logs from all parallel step branches concurrently (e.g., prefixed with [step-name] to distinguish output) After execution completes, logs from all parallel children should be fetched, not just the first one This should provide parity with the Harness UI, which shows all parallel step outputs ## Why it matters The primary value of hc iacm plan remote execution is reviewing plan output locally without switching to the browser. For teams using parallel steps (which is the recommended pattern for multi-workspace IaCM pipelines), this currently doesn't work which forces the user to have to open the UI anyway, defeating the purpose of the CLI. ## Use case Large-scale IaCM adoption with 50+ workspaces running parallel Terraform/OpenTofu plans via the Harness CLI for local developer workflows.

We would like to request support for write-only arguments for sensitive fields used in the harness_platform_gitops_repository resource within the Harness Terraform provider. Currently, GitOps repository authentication credentials such as GitHub PATs or SSH private keys are persisted in the Terraform/OpenTofu statefile because the provider does not support write-only attributes for these fields.

Can support for mermaid diagrams please be added when rendering markdown in Code Repositories?