Feature ideas

Right now the data of GitHub code-scanning-alerts does not allow to filter alerts based on the repository metadata. (e.g. only get alerts for non-archived repos) The repository metadata is present for most of the other kinds (e.g repository, file, dependabot-alert) but not for code-scanning-alerts.

Currently, when creating a new property in the blueprint, the cursor does not automatically focus on the first field, "Title." Enabling this behavior could enhance both accessibility and user experience.

As a Port builder, I want to apply weights to scorecard rules. For example, if my rules are has a README has a team had an outage within the past week I would want to weigh the third rule more heavily than the previous two. The total number of rules passed above is 67%, but if I were able to add the following example weights to the rules, the overall score or grade would be 50% has a README (25% weight): 25/25 has a team (25% weight): 25/25 had an outage in the last week (50% weight): 0/50

Today we have a Terraform & Pulumi provider Some companies use K8s to manage configuration using tools operators, so it would be great to have a Port operator, which will allow creating Port CRDs (Blueprints, entity, pages, etc) that contain the IDP configuration

We have over 14k+ repos in our Port inventory at the moment. Only about a 1/4 are active (not archived). If we set the query in the selector to ".repo.archived == false", the GitHub integration pulls all repos, and then filters at the point of mapping. The list organization repos in the REST API (doc) doesn't support using the archive filter. But the search api (REST, GraphQL) allows active repos to be fetched using the following query: archived: false : https://docs.github.com/en/rest/search/search?versionId=free-pro-team%40latest&productId=search-github&restPage=searching-on-github%2Csearching-for-repositories&apiVersion=2022-11-28#search-repositories https://docs.github.com/en/graphql/reference/queries#search We would like the filter to apply before and not after (like it currently does). It would make the github integration faster and reduce load.

For some use cases the 30 character limit is restrictive and limits the capacity for some advanced workflows for auto-generating blueprints from a service prepended with some prefixes. An increase in the character limit would enable advanced use cases/workflows without having to resort to brittle workarounds.

I want to be able to insert entities by batch or bulk through webhook/REST api to prevent calling the same endpoint many times. I also want to be able to do the same when deleting entities. Having checkboxes in catalogs to select and do a specific action for selected entities can also help :)

Hi, We have an on_call_duty blueprint where we define the triager for each week. We would like to fill the assignee based on the current week's triager on a user form. I managed to do this with the following configuration ```json "week_number": { "type": "string", "title": "Week number", "blueprint": "on_call_duty", "format": "entity", "default": { "jqQuery": "now | strftime(\"%V\") | \"week_\"+." } }, "assignee": { "type": "string", "title": "Assignee", "format": "user", "dependsOn": [ "week_number" ], "default": { "jqQuery": ".form.week_number | .properties.triager" } } ``` On the first load of the form, the week number gets filled but not the assignee . If I close the form and reopen, the assignee gets filled properly. Could you make the dependsOn configuration to be aware of dynamically set default values? Thanks in advance!

Today we have a static and strict small schema we bring about users and teams when integrating with an identity provider (user names, mails, team names) The idea here is to have the whole payload coming from the SSO provider (the schema should be known based on the SSO protocol) and for Port builders to be able to decide what they want to map to the user and team blueprints.

As admin users, we have full visibility on everything that's available in Port. We can already control what users see and interact with, but we cannot easily confirm if the changes we have made are correctly tailored to them. It would be very helpful to be able to preview the changes.