Feature Requests

Summary When re-running/retrying an IDP workflow that uses conditional inputs (e.g., fields that depend on connectionType), values from the previous selection remain in the workflow form data. This causes the Review step to show fields from both the old and new selections, which is confusing and can lead to incorrect submissions. Problem / Current behavior • Workflows with conditional parameters (dependencies / oneOf / if-then) behave correctly while filling the form. • However, on Retry/Re-run, if the user changes the selector (e.g., azureblob → documentdb), the previous branch fields remain in the underlying formData. • The Scaffolder Review page reads from the full formData, so it displays “old + new” fields together. Expected behavior On Retry/Re-run, when the user changes a dependency-driving field (like connectionType), fields not in the active schema branch should be removed from the form data so only the current branch appears on Review and is submitted. Why this matters (Impact) • Confusing UX during Review • Higher risk of submitting stale/irrelevant parameters • Common use-case for connection/config workflows (Azure Blob vs Cosmos DB vs SQL, etc.) Requested enhancement Enable (or provide a supported configuration option to enable) RJSF behavior that removes inactive fields from formData, such as: • omitExtraData • liveOmit so that hidden/inactive fields do not persist across Retry/Re-run and do not appear on Review.

Summary Currently, when a component's catalog-info.yaml is updated with new metadata (e.g., adding a Slack channel, updating an owner, or adding a repository tag), the associated Scorecard checks do not reflect these changes until a user manually navigates to the UI and triggers a "Rerun Checks" action. This proposal requests an automated trigger to re-evaluate scorecards whenever the underlying Catalog entity is updated. The Problem Stale Data: Scorecards often show "Failing" grades for checks that have actually been resolved in code, leading to a lack of trust in the dashboard. Manual Overhead: Developers must remember to manually trigger a refresh, adding unnecessary steps to their workflow. Delayed Feedback: There is a "lag" between fixing a metadata issue and seeing the visual confirmation of that fix. Proposed Solution Implement an event-driven refresh mechanism. The system should listen for lifecycle events from the Catalog (specifically EntityUpdated or CatalogUpdate) and automatically queue a scorecard re-scan for the affected entity.

The goal is to move away from static, manual-entry text fields—which are prone to "fat-fingering" and input errors—and move toward a real-time, validated lookup component. Core Functionality Asynchronous Lookup: The UI component should perform an asynchronous GET request to a customer-defined REST API endpoint as the user types. Search Debouncing: To prevent overwhelming the external API, the request should only trigger after a specific character threshold (e.g., 3 characters) or a short delay (300ms) in typing. Key-Value Separation: * Display Value: What the user sees (e.g., "Payment-Processing-Service"). Stored Value: The actual unique identifier (e.g., "V-99827") that is passed into the underlying YAML and used for provisioning. Validation Enforcement: The workflow should prevent submission if the user tries to enter a value that was not returned by the API search, ensuring that only "existing and valid" entities are used.

Core Problem The current UI renders arrays by generating a new, full-width row for every single item added. When a workflow involves multiple inputs (e.g., several environment IDs or service tags), the form becomes excessively long. This "vertical bloat" makes it impossible for users to see the entire form at once and complicates the review of entered data. The Requirement A single input container that "tokenizes" multiple entries into compact, removable pills. Behavior: When a user types a value and presses Enter, the string is converted into a Tag (Pill). Spatial Layout: Tags must wrap horizontally within a single field. The field should only expand its height if the horizontal line is full, rather than creating a new row for every single value. Editing: Each tag must include a clear "X" button for instant removal. Validation: The system should support entering a value, pressing enter, and immediately typing the next one without manual clicks between rows. Specific Use Case In workflows with nested arrays (arrays within other arrays), the current vertical expansion causes a compounding effect where the UI becomes "unbounded." Condensing these into tags ensures even complex, multi-layered forms remain visible within a single screen view.

Problem Statement "Sometimes the color mismatching looks completely different. It should just blend in so the user doesn't have doubts." Currently, there is a significant visual disconnect between the core Harness UI and custom-built Catalog plugins. Because developers must build their own design and CSS styling from scratch, plugins often fail to match the Harness aesthetic. This lack of synchronization creates a fragmented user experience, making custom plugins feel like external, untrusted additions rather than native features. Developers are currently forced to "guess" styles, leading to: Color Mismatching: Inconsistent palettes between the platform and the plugin. Theming Friction: Difficulty supporting Light/Dark mode transitions automatically. Design Silos: High effort required to recreate standard Harness components (buttons, cards, inputs). Proposed Solution The introduction of a Standardized Plugin Boilerplate and Theme Provider SDK. This solution will provide a "Harness-native" foundation for all new plugins, ensuring they inherit the global design system automatically. By exposing Harness design tokens and providing a pre-configured starter kit, developers can focus on plugin functionality while the UI "blends in" by default. Key Functional Requirements Universal Design Tokens: Provide a library of CSS variables (e.g., primary colors, surface backgrounds, font scales) that stay updated with the Harness brand. Theme Provider Wrapper: A wrapper component that detects the user's active theme (Light/Dark/System) and propagates those styles to the plugin's CSS context. Ready-to-Use Boilerplate: A CLI or repository template that comes pre-integrated with the Harness Design System (HDS) styling bridge. Standardized Component Library: Access to lightweight, pre-styled UI elements (buttons, typography, tables) that match the platform’s look and feel. User Benefits Seamless UX: Users experience a cohesive interface where plugins look and feel like native parts of the Harness ecosystem, increasing trust and adoption. Accelerated Development: Developers save hours of CSS work by using a "plug-and-play" boilerplate instead of recreating styles from scratch. Future-Proofing: When the Harness UI evolves or updates its brand colors, plugins utilizing the boilerplate will update automatically without requiring manual code changes. Reduced Cognitive Load: A consistent UI reduces the learning curve for users interacting with new custom-built features.

Proposed Solution We propose a two-tier enhancement to the IDP: A Component Framework: A way to build and publish "Custom Pickers" as reusable libraries. A Visual Canvas: A drag-and-drop interface (similar to Power Platform or Harness) that allows users to assemble workflows using these pre-defined components. Key Functional Requirements Custom Picker Framework: * The ability to define a picker once (e.g., a "Service Selector" or "Cloud Region Picker") and publish it to a central library. Standardized APIs to fetch data into these pickers (e.g., connecting to internal CMDBs or Cloud providers). Visual Drag-and-Drop Editor: A canvas-based UI where users can see an "Inventory of Things" (the components). Ability to drag components onto the stage to generate the underlying YAML automatically. Consistency with Existing Tooling: Mirror the functionality of the existing Project and Org pickers but allow for user-defined logic. User Benefits Efficiency: Reduces the time to create a new workflow from hours to minutes. Governance: By publishing pickers as a library, we ensure every team is using the same approved data sources and input formats. Lower Learning Curve: Users who aren't "YAML-fluent" can contribute to and build their own automation.

Please enable Harness IDP portal I wanna explore features of this module

Currently there are many manual clickops are required when deploying IDP components into Production: IDP layout Plugin config and setup (native & custom plugin) Scorecard configuration Workflows creation SSEM (self service environment management) To avoid the issues with manual configuration, it would be great if Harness can have a mechanism to automate the promotion of config/setup to Prod in an automated manner.

Please enable the flag IDP_STO_INTEGRATION for this account so that we can see the STO insights in IDP

Problem at Hand: The current mapping in Harness does not align with the hierarchy used on the NAB side. Ideally: Harness “Organisation” should align with NAB CIOs Harness “Projects” should align with NAB Domains However, over time, the NAB hierarchy (NAB → CIO → Domain → Service) has drifted out of sync with how it is represented in Harness (NAB → Orgs → Projects → Services). Proposal We attempted to use System Entities to replicate NAB’s hierarchy inside Harness: Created one System Entity for CIO Created another System Entity for Domain Differentiated the two using tags The goal was to link Domain as a child of CIO The challenge: We are currently unable to display Domain entities under a CIO in a tabular format, even though we have linked Domain system to CIO system. We already have reliable mapping at the service level. So during service ingestion, we can: Map each service to its corresponding Domain (System) Map each service to its corresponding CIO (System) This effectively reconstructs the true NAB hierarchy inside Harness without relying on the “Hierarchy” construct