Feature ideas

Currently, the "Sync status" tab, which includes metrics to monitor integration sync, shows data only from the latest sync. We would like to add the ability to choose a specific historical sync and see its metrics and sync status as well.

Currently the ADO File Kind does not support Wildcard/globs as per https://docs.port.io/build-your-software-catalog/sync-data-to-catalog/git/azure-devops/examples#capabilities-and-limitations . This is required to help map things like mono repos.

Provide a hosted MCP solution with Oauth methods to enable easier installation experience.

Currently the Azure DevOps pipeline metadata that is ingested lacks context of the originating repo. The Azure DevOps API for pipelines is capable of returning a configuration object which contains all the necessary repository data. This will allow for easier linking of pipelines to repositories.

There is the integration in the port-experimental repo, it would be great to have this as a support Ocean integration https://github.com/port-experimental/aikido-integration

As a Port admin, I want to be able to mirror aggregation properties to carry aggregated data from one blueprint through another blueprint into the "central" blueprint upon which I am building a scorecard.

Introduce support for service accounts within Port to enable automated, non-human access to the platform for integration, automation, and management purposes. This feature would allow systems and services to interact with Port directly, facilitating seamless workflows and enhancing operational efficiency.

Right now API tokens have Admin permissions, they can perform any operation - CRUD operations on the catalog, as well as triggering self-service actions. This feature aims to add support for permissions and RBAC support to API tokens. This would enable for example API tokens with read only access, tokens that can only trigger actions but are unable to directly change the catalog and more.

Ability to assign permissions according to the data model you defined for your organization. How it will work: When assigning permission (for example, to execute an action), the new capability will allow to query the catalog entities and create a permission condition based on the queries. For example: Allowing a developer to execute the "Deploy" action only if the developer is related to the same domain as the service Allowing a user to execute the "Lock/unlock deployments" action only if the user appears in the catalog as the "team leader" of that service The first version will support assigning dynamic permission for executing an action, in the future we will add the support for editing entities.

Support retrieving service dependencies from the Datadog integration.