Feature ideas

Adding support for Contextual Query Rules (as documented here: https://docs.port.io/search-and-query/structure-and-syntax/#contextual-query-rules ) to Port's Terraform provider

Currently, the major navigation options in the Port UI are: home, catalog, and self-service. Ideally, Port administrators may select one or a few other major elements that can be added. For example, a "Favorites" tab, or a tab that contains daily-use items (like deploying a specific version to a specific environment). This would cater further to those end users who come to Port to "do" (have a commonly-used action in mind and execute it, no search required). The effect of this would be similar to having a "Favorite Actions" or "Commonly/recently viewed items" section as you might see in other user interfaces.

### Request a new search operator for beginsWithAny , with semantics such as: { "operator": "beginsWithAny", "property": "myArrayProperty", "value": ["prefix1", "prefix2"] } This would return entities where at least one element of myArrayProperty starts with any of the provided prefixes. i.e. prefix1-example or prefix2-example would match. ## Motivation / Use cases: Improved path matching across multiple sources. (e.g., issue exists on file /abc/def/issue.txt and team A is responsible for all issues on path /abc/def/ . - Build Scorecard rules that validate naming conventions on arrays of strings (e.g., Kubernetes labels, GitHub topics) without needing extra calculated properties. Simplify complex queries that currently require preprocessing or additional properties just to support prefix checks on arrays. ## What Port currently supports: beginsWith / doesNotBeginsWith for checking whether a string/number property starts with a given value. https://docs.port.io/search-and-query/operators/comparison-operators/#beginswith https://docs.port.io/search-and-query/operators/comparison-operators/#doesnotbeginswith containsAny for checking whether any of the specified strings exist in a target array. https://docs.port.io/search-and-query/operators/comparison-operators/#containsany However, no operator allows checking whether any element in an array property begins with a given prefix (or one of several prefixes) Therefore, this proposed operator would complement the existing beginsWith and containsAny operators and make array-based filtering more expressive and consistent with current string/number capabilities. ## Extra scope: I'm sure endsWithAny would also be appreciated by others, but not needed for my use cases. { "operator": "endsWithAny", "property": "myArrayProperty", "value": ["suffix1", "suffix2"] }

Problem Statement Port's 100-character identifier limit makes it impossible to reliably create unique, deterministic identifiers for documentation entities using natural keys (repository + filepath), which frequently exceed this limit. There is currently no built-in way to generate SHA hashes from property values during entity creation, forcing users to choose between: Truncated paths → Risk of identifier collisions Manual hash generation → Inconsistent, error-prone, requires external tooling Filename-only identifiers → Guaranteed collisions (multiple README.md files) Current Constraints Identifier Limit Maximum identifier length: 100 characters Pattern requirement: ^[A-Za-z0-9@_.:\\/=-]+$ Real-World Examples Exceeding Limit Example 1: GitHub Documentation Path Repository: tr/platform-engineering-kubernetes-infrastructure File path: .github/PULL_REQUEST_TEMPLATE/pull_request_ template.md Natural identifier: tr/platform-engineering-kubernetes-infrastructure/.github/PULL_REQUEST_TEMPLATE/pull_request_ template.md Character count: 109 characters Example 2: Deep Documentation Structure Repository: atpa-gst-ai-assistant File path: documentation/architecture/backend-services/authentication/ oauth-integration-guide.md Natural identifier: atpa-gst-ai-assistant/documentation/architecture/backend-services/authentication/ oauth-integration-guide.md Character count: 114 characters Example 3: Long Repository Names Repository: thomson-reuters-legal-technology-innovation File path: docs/deployment/kubernetes/ production-configuration.md Natural identifier: thomson-reuters-legal-technology-innovation/docs/deployment/kubernetes/ production-configuration.md Character count: 117 characters This is critical for us as: Blocks core functionality: Can't reliably upsert entities Forces workarounds: External scripting required for all integrations Data quality issues: Identifier collisions cause data loss Operational overhead: Manual identifier management doesn't scale Architecture constraint: Limits usefulness of Port for documentation management

When pressing the browser back button (or the back icon in Port) you are taken back to the previous entity you had selected and not the previous page (which is what I would've expected).

Allow global/Spotlight search to be filtered or ranked by type, with admin controls to exclude noisy entities and prioritize services.

Currently, global search results are based solely on the keyword(s) entered. For organizations with many entities, it would be helpful to do a few things with global search, such as: filtering (provide filters to the search using a search dropdown for blueprint, properties, relatedTo, etc), semantic search, and adding filters within the search query (such as in:<blueprint>, <search query A> AND <search query B>, NOT <blueprint>)

When querying the Audit Log API for entity updates, the actor is returned as a userId. There’s no direct way to resolve that ID to a name/email. Today we must fetch all users in the org and filter those results client-side. Please add a direct resolution path (such as GET /v1/users/{userId} or GET /v1/users?ids=<id,...>) or allow filtering the Users API by id.

Today you can only use relatedTo to check if an entity is connected to a certain entity on a related blueprint. When using Port I'd want also to check the entities that are not connected at all to any entity in the related blueprint. For example - All Workloads that are null in the "Namespace" relation