Feature ideas

Currently the Ocean custom integration is supported only in self hosted mode. We would like to support it also in hosted by Port mode, with a UI interface for installation.

Currently there are no relation mappings between the OOTB SNOW kinds. Incidents should be automatically mapped to Assignment groups in the group table

Problem: Customer reported that the "test mapping" feature was not working properly for their GitLab integration The test mapping UI couldn't properly process or validate their data source mapping This made it difficult for customers to test and validate their integration mappings before deployment Description: Improve the test mapping functionality to better handle: Large File Processing: Support for testing mappings on larger YAML files without performance issues Multi-Document YAML: Better parsing and testing capabilities for multi-document YAML structures Business Impact: Reduces customer debugging time Prevents integration failures in production Improves customer confidence in mapping configurations

Currently, the Kubernetes exporter fetches all resources of the specified kinds from the Kubernetes API and applies filtering only after the data is retrieved, using the query selector in the integration config. This can result in large volumes of irrelevant data being fetched and processed, especially in clusters with thousands of pods and nodes. Request: Introduce support for API-level filtering (pre-fetch filtering) in the Kubernetes exporter, similar to how JQL is used in the Jira integration to filter issues at the source. This would allow users to specify filters (e.g., by namespace, resource type, or labels) that are applied directly in the API request, reducing the amount of data fetched and improving sync performance.

We are syncing resources across ~100 AWS accounts and it would be nice to see how long the sync of each resource kind is taking so that we can decide to optimize filters for that resource kind

The incremental sync script can collect changes every x minutes, acting as a "near real time" events processor. Adding this behavior to the Azure Resource Graph integration would provide near real time experience on top of the full resync using the resource graph QL, which would act as a cleanup.

Today it is only possible to integrate using basic auth, and this feautre request is about being able to authenticate to SNOW using OAuth

On startup, log the active mapping hash and the exact blueprint targets (e.g., targets=[cluster,namespace,node,workload,replicaSet,pod,gateways,virtualServices]). This will make configuration drift or unintended merges immediately visible.

Currently, to assign a swagger UI property an openapi.yaml's content, the file kind needs to be mapped with skipParsing: true, which then does not allow other properties to be assigned using jq because the content is passed as a string rather than as an object. That forces us to write to almost identical file mappings with the sole difference of skipParsing: true for the one with the Swagger UI property, and and without it for everything else basically.

It would be helpful if we had a trips and tricks section in the Port UI or in our documentation to show that users can always do trips and tricks on their JQ mapping to avoid some user-specific errors. For example, say the user gets the following error in the Audit logs "last_push" must match format "date-time" Then they could solve it by changing the default mapping from last_push: .pushed_at to last_push: .pushed_at | (if type=="number" then todateiso8601 else . end)