Feature ideas

We take your ideas seriously! Read more on our prioritization process in our blog https://productmanagement.port.io/posts/managing-feature-ideas
Support Dynamic Referencing of Indirect (nested) Entity Relations
Currently, if we have blueprints with relations as follows A -> B -> C, it is not possible to reference C from A using jq since only B is defined in A's entities YAML. This limitation creates issues in scenarios where we have a relations hierarchy such as Team -> Group -> Department. We would like to create an SSA (Self-Service Application) that accepts a team as an input and then references and auto-populates the team's group and department from the provided team, making this data available to downstream systems. We would like this capability to be available across all Portal areas, not just for SSA, but also for dashboards, etc. Current Workarounds: Create Form Inputs for All Variables: This approach is tedious and results in a poor user experience. Use Mirror Properties to Create Direct Relations Between Indirect Relations (e.g., A -> C): This workaround is not ideal because: * It is a high-maintenance solution that requires altering the model (blueprints) each time indirect data is needed, even though it is defined and logically accessible. This would necessitate defining each such property multiple times, impacting our velocity and time to market. * This approach would make the related entities graph view effectively unusable, as each entity would have direct relations to every other entity. Request: We request the implementation of a feature that allows dynamic referencing of nested entity relations, enabling us to reference and auto-populate nested entities without the need for cumbersome workarounds or loss of functionality of other areas as the graph view.
0
Terraform Provider - Separate calculation properties into their own resource
The current Terraform provider (v2.13.4 at the time of raising this) has distinct resources for port_blueprint and port_aggregation_properties . This enables developers to avoid circular dependencies between blueprints and aggregate properties in various scenarios. thumbs up However, the same circular dependency problems can arise with calculation properties. Take the following example of calculating the DORA "Change Fail Rate" metric: Blueprints: service , incident and deployment (both incident and deployment have a relationship back to service ) The service blueprint includes aggregate properties; count_incidents_in_last_week and count_deployments_in_last_week (both counting entities, with a filter on a date property in the respective blueprints) The service blueprint then also includes a calculation property for the DORA metric: (.properties.count_incidents_in_last_week / .properties.count_deployments_in_last_week) * 100 Port lets you set this up via the web app. But when deploying via Terraform we create circular dependencies: resource "port_blueprint" "service" { calculation_properties = { dora_change_fail_rate = { # Depends on port_aggregation_properties.service_aggr else we cannot add property calculation = "(.properties.count_incidents_in_last_week / .properties.count_deployments_in_last_week) * 100" } } } resource "port_aggregation_properties" "service_aggr" { # Depends on port_blueprint.service, else the aggregates cannot be added blueprint_identifier = port_blueprint.service.identifier properties = { count_incidents_in_last_week = {...} count_deployments_in_last_week= {...} } } If calculation properties were a distinct resource type, rather than embedded in the port_blueprint resource, then we could avoid such circular references.
0
Load More