Feature ideas

The pipeline-run kind should be able to infer branch data directly from the pipeline run's built-in metadata (e.g. sourceBranch or equivalent fields available in the Azure DevOps Pipelines API response) without requiring an explicit Branch parameter to be defined in the pipeline YAML.

As a builder, I want to show data in widgets that comes from a calculation of multiple properties e.g. I want to do a claculation on the number of PRs opened just for this one graph, so I can use jq to calculate the data output.

Where two blueprints have a relationship, we must explicitly set the identifiers of each entity to be linked. I'm proposing something more dynamic - enabling an entity (blueprint A) to be related to one or more entities (blueprint B) based on Search & Query syntax. For example: we want to have a list of "Contributors" to the repository. Given: * a github_repository blueprint * a pull_request blueprint * and a github_credentials blueprint It would be valuable to be able to define a property (aggregate/calculation/other) on github_repository which could list out all github_credentials , related to the repo via the pull_request path, with optional filtering (i.e. only PRs in the last 6 months).

Summary: Port's aggregation properties support $team (entity ownership) as a path segment, but only when it is the first hop in a pathFilter. When $team appears as a mid-path hop, the traversal silently returns 0 — even when the underlying data is correctly modeled. Example path that doesn't work: EntityA → relation_to_EntityB → $team(_team) → domain Why it should work: Every Port entity already carries a .team[] ownership array. The graph connection exists natively — Port just doesn't traverse it mid-path in the aggregation engine. No additional relation is needed; the data is already there. Current workarounds (all have trade-offs): Add a redundant direct relation (e.g. EntityB → domain) — requires ongoing maintenance Add an explicit _team relation — forces internal Port concepts into the data model Expected behavior: $team should be resolvable at any position in a pathFilter path, consistent with how it behaves as a first-hop segment.

Goal: Reduce UI clutter and require explicit opt-in to display new properties. Description: Set newly added properties to be hidden by default. Builder/API: Hidden in Entity Details widget and all tables (only meta properties visible). Table (clicking on + Property): Hidden in Entity Details by default. Visible only in the table where created, hidden in all other tables.

Port's URL and Labeled URL properties are fundamentally different types, once a URL property is created, it cannot be converted to a Labeled URL in place. The only path to migration requires creating a new property, deploying, migrating data, updating all integrations, and deleting the old property, a process that can take ~2 hours for what should be a trivial display change. Proposed Solution Allow a display-layer transformation (e.g., via JQ expression or a simple label mapping) on existing URL string properties, so that: The underlying data remains a plain URL string (no schema change, no integration updates required). The display layer renders the URL with a human-readable label, equivalent to the current Labeled URL behavior. Why It Matters Eliminates data duplication and integration dependencies caused by property recreation. Reduces a ~2-hour migration to a seconds-long configuration change. Aligns with the spirit of the already-shipped Labeled URL feature.

When choosing a property in a widget definition (for example, breakdown by property in pie chart), it would make it easier to navigate and differentiate if I know the types of properties (for example relations and regular properties, number properties etc)

Current Behavior: When adding a property of type "User" via the UI blueprint editor form, Port automatically converts it into a relation to the _user blueprint instead of saving it as a property. This happens regardless of the blueprint or property name chosen. Desired Behavior: Users should be able to create a User-type property (not a relation) directly from the UI blueprint editor form, with the same result as defining it in JSON mode. Impact: The inconsistency between the UI and JSON/API/IaC methods is confusing and undiscoverable — users are not warned that the UI will silently convert their property into a relation. User-type properties created as relations cannot be mirrored to child blueprints, limiting their use in reports and widgets (e.g. Pie Chart breakdowns).

The port_search Terraform data source currently calls POST /v1/entities/search, which requires a property field in every rule. This means relation-based filter rules are not supported, and the following query fails with "rules/0" must have required property 'property': data "port_search" "pd_entities" { query = jsonencode({ "combinator" : "and", "rules" : [ { "relation" : "pagerduty_escalation", "operator" : "isNotEmpty" } ] }) } The blueprint-scoped endpoint POST /v1/blueprints/{blueprint}/entities/search does support relation-based rules (e.g. filtering by isNotEmpty on a relation field), but the port_search data source does not expose this endpoint. Requested change: Add support for relation-based filter rules in the port_search data source, either by: Exposing the blueprint-scoped search endpoint (/v1/blueprints/{blueprint}/entities/search) as an option in the data source, or Updating the global search endpoint to accept relation rules without requiring a property field. Use case: We need to find all entities across blueprints where a specific relation (e.g. pagerduty_escalation) is set (i.e. isNotEmpty). Today this requires a multi-step REST API workaround outside of the Terraform provider, which undermines the goal of managing Port infrastructure as code. Current workaround: Query /v1/blueprints to discover all blueprints that define the target relation. For each blueprint, query /v1/blueprints/{blueprint}/entities/search with a relation rule. This is brittle and forces us to bypass the Terraform provider entirely.

Currently, the maximum number of entities returned by a search query rule when mapping relations is limited to 500. There is no built-in way to exceed this limit. Since 500 may be too low for certain use cases, it would be helpful to provide an option to increase this limit.