Feature ideas

In GitLab v2 , discovery calls now use a fixed setting of min_access_level=30 (Developer). Because of this, service or admin tokens cannot access projects unless they are added as members to each group or project. By contrast, In GitLab v1 , the filterOwnedProjects:false flag made it possible to include projects where the token was not an owner or member, using admin or auditor tokens with built-in read permissions. For enterprises managing thousands of projects, this change is not scalable due to: Security and privacy concerns – service accounts would become visible across all groups. Operational overhead – maintaining explicit membership for thousands of projects is not feasible. Proposed Solution : Re-introducing the filterOwnedProjects:false flag (which bypasses min_access_level), OR. Allowing users to configure min_access_level instead of enforcing it at Developer. This would enable users to use admin/auditor tokens without explicit project membership.

Currently, when a relation is set to "List of entities" and a mirrored aggregation/number property is created, the dashboard filters treat the property as an array of numbers rather than a single number. As a result, only array-based filter operators (e.g., contains, not contains) are available, while numeric operators (>, <, =) are not supported. This creates a limitation in dashboards (e.g., filtering "Number of Open Critical Issues" > 0) for services with multiple related entities. Numeric operators should be supported for number arrays. For example, if a mirrored aggregation returns [0, 2] and the filter is "> 1", the system should allow clear logic for handling arrays (e.g., match if any element satisfies the condition, or if all do).

Using the createMissingRelatedEntities flag (like in API and the integration mappings) would be helpful and practical when we have Automations with create/update entity backends.

While the administrator can currently control all of the parameters for a chart, users having the ability to customize their own version of the data being presented has been requested by several of our users (similar to how an administrator can create a table widget, but then users can control the searching/sorting/filtering of the table within the bounds of the data that the administrator has designated to be included). As an example, we have created line charts to show the number of pending messages in a messaging queue (this can be helpful both in determining current performance of a service, as well as identifying throughput issues for further investigation). As an administrator, we have configured the displayed line graph to show the past week's worth of data in hourly increments - but not all messaging queues are equal, and so changing the range and/or granularity might be helpful to a user looking at a particular queue. (I fully recognize that this is a bit more complex of an ask than adding searching/sorting/filtering to tables, given the different chart variants and their associated types - but I am hopeful that some of the same UI logic involved in the administrative modal for configuring a given chart could be grabbed/repurposed/trimmed down a bit to offer end users the ability to have some of the same same-session data manipulation that they do in the table UI today.)

Add the secret-scanning-alerts kind to the Github Ocean (self-hosted) integration.

In order to make it easy to re-use the structure of a dashboard page, an option to duplicate a dashboard page can really help

Add support for the delete_dependents flag in Terraform and Pulumi providers for entity deletion. Currently, the API suggests using this flag when dependent entities exist, but it isn’t supported in IaC, causing operations to fail. Supporting the flag (configurable at the provider level, defaulting to false) would align IaC with API behavior, reduce customer confusion, and provide flexibility for advanced users, while requiring clear safeguards and documentation to mitigate risks of unintended data loss.

Particularly CREATE actions with the create/update entity backend. CREATE actions will fail if there is an empty required related entity, and the ability to create that entity upon execution using this param like in the API or integration mapping would address this.

Currently Terraform has only partial page management, with the ability to edit basic pages such as dashboard and blueprint-table; but it has no support yet for specific entity pages.

Bring your own MCP. Port’s AI today only sees what’s inside Port. By bringing in a customer's MCP Server and their AI Agents, they are already pulling in external context from Confluence, Jira, and other systems. Their AI Agents may have deep context surrounding their business. Customer wants Port to be able to tap into that external intelligence so the AI inside Port can act with full awareness of both Port and non-Port data.