Feature ideas

Allow users to build their own interface components as widgets, with Port's catalog context at hand.

To address brand logo requirements (i.e. min width 48px, no borders, no rounded corners), custom theming functionality in Organization Settings should be expanded. Current limitations: max-width - 34px border border-radius (rounded corners) 1 image for both themes (light and dark) Suggestions: Add 1 more link for dark theme icon Add input for icon size Remove border and radius, or add checkboxes / toggles to add/remove border and radius

Would be very useful to have the ability to select multiple entities on the page and bulk delete them all

Today, if a user clicks on the Client Secret rotation by mistake, the key will rotate without approval. So the idea here is to add user approval so the user will approve this request.

Today we can only get the first 1000. Would like to see more so we can for example see yesterday's runs. Could also work to have filters

As for now the API route for pages and Sidebars are very complex (and it's still in beta), we need to have a better implementation for it

Today you can only hide certain blueprints in the specific entity dependency graph, but ideally I would want to pick the path that will be presented in the graph, and not hide an entire blueprint because there is a scenario in which I want to see one path and not other, instead of hiding an entire related blueprint

Widgets on an entity dashboard need to be dynamic. For example iFrame implementation on entity dashboard should use the entity info to display the appropriate URL (maybe {{.entity.url}}) - Need to make URL portion dynamic Markdown should be dynamic as well for a better user experience

There are some blueprints that I always want to exclude from global search (e.g. releases). When they are included, it ruins the search results. I want to be able to configure it globally, i dont want to have to add a search expression to the global search

The GitHub sync currently enforces a hard cap of 100 closed pull requests per repository (or those closed in the last 60 days) with no way to adjust. This prevents users from ingesting their full PR history and forces manual workarounds. We need to expose a configuration option or alternate mechanism to allow fetching beyond the 100-PR limit so that customers can ingest all closed PRs on demand.