Feature Requests

Use Case: As a Platform Operator, I want to group related Building Blocks (BBs) together using tags (e.g., from the tagging catalog) so that Application Teams can easily discover "sets" of services that belong to a specific platform offering. Example: I create an IDP with services K8s namespace, git repo, container registry and database -> they are designed to work together (but not necessarily dependent). I would tag them with "K8s IDP" and if I could switch on that filter in the marketplace (best via URL to also share it), I could point users to my specific platform BBs. It would be a first step towards the "Platform view" suggested elsewhere. Value Created: Improved Discoverability: Prevents specialized BBs from getting "lost" in a crowded marketplace. Enhanced Sales/Demo UX: Allows meshies and customers to demo a cohesive platform experience from the Developer Portal perspective rather than just the Platform Builder. Logical Organization: Aligns the marketplace view with the organization's existing tagging and governance structures.

When selecting a workspace from the dropdown list in the 'Contributing Workspace' section of the platform configuration, a user enters a workspace ID, but the dropdown displays only workspace names. Showing the workspace ID alongside the display name would help users confirm they are making the correct selection.

The Landing Zone and Platform UIs should include links that make navigation between platforms and landing zones easier. For customers managing multiple landing zones and platforms with similar names, navigation can be challenging without these shortcuts.

As a platform team when one of my building blocks require my input (because operator input required) I want to see that immediately in the dashboard and get to the BB input fields with one click. Otherwise, I have to go to (and know how to get there): Building Blocks section -> Building Blocks nav entry -> Switch to Tenant Building Blocks tab -> find "Operator Input required" in a potentially long list -> click on "Operator Input" to finally be at the form. This is not very transparent. meshStack should provide a better insight into the state of my platform in the overview. I know there is an email notification. When is it not enough? When I build and test my platform, I run the BBs I create and work solely in meshStack during that time without looking at my inbox. Therefore, the UI should give me sufficient feedback and guidance about what's happening with my platform's components.

It is already possible to upgrade an individual building block without triggering a new run. I would like to have the same feature available as well when upgrading building blocks in bulk. This is useful in cases where the change does not affect the configuration of the resources deployed by the building block. One example could be changing the private key for accessing the git repo where the terraform code is stored.

meshstack API should support defining and updating workspace quotas programmatically. Specifically, this feature would allow setting API quotas via the API and enable end users to immediately create API keys through self-service.

Use Case: As a Platform Engineer, I want to define the mapping between Terraform variables and meshStack Building Block inputs (including source types like User Provided, Tenant ID etc.) via a YAML file in the Git repository of the terraform module. This means, I just put e.g. a meshStack.yaml file next to my .tf files to pre-configure the meshStack BB definition. Value: This would enable a "Configuration as Code" approach for BB definitions, making it easier to version-control the interface alongside the implementation and reducing manual configuration steps in the meshStack Admin UI. Import of terraform repos into meshStack BB definitions could skip the mapping step in the UI and read it from the mapping file instead. Value Created: * GitOps Workflow: Enables "Configuration as Code" for Building Block definitions. * Consistency: Ensures that every time a module is imported or updated, the input mapping is already predefined by the module author. * Efficiency: Reduces manual configuration errors in the meshStack Admin Area. * "meshStack-enabled": Terraform modules could very easily be extended in out-of-the-box BB definition (e.g. in the meshStack hub) to be consumed in one go

As a meshstack user, I don't want to be aware of the mandatory building blocs in a landing zone in order to order platforms more hazzlefree. Actually, as an end user, the bb name has to be confirmed, althoug I do not know the purpose and the meaning of the building block since it comes automatically with the landing zone.

Certain UI elements, such as platforms and landing zones, currently provide only an 'Edit' option and lack a 'View' mode. Users often want to review existing settings without making changes, and selecting 'Edit' in such cases can be confusing and inappropriate. Introducing a 'View' option would enable a clear, read-only experience.

We love using the new building block readme to convey to our developers what service they will receive right when browsing the meshStack marketplace. I'd love to include similar instructions for our landing zones.