Feature Requests

As a Project Reader, I am supposed to have Read-Permisisons on my cloud tenant (e.g. Reader Role in Azure). However, as a Project Reader in meshstack, I am still able to provision/delete building blocks. The aim is to harmonize these permissions also in meshstack: Project Reader -> Only Read-Access to marketplace

Problem / Use Case When a tag is defined with a default value (e.g. on a Landing Zone), the default value is not actually applied to existing entities right away. The Landing Zone table view already shows the default value as if it were set, but the value is only really applied once you open the entity and press "Save", even without making any changes. This becomes confusing when the tag is used as a Building Block input: the Building Block reports the tag as missing and appears to be "waiting for input", even though the table view already shows a value for it. There is no indication that opening and saving the entity is what's needed to resolve this.

Problem / Use Case When building a backplane for a Building Block Definition (BBD), we need to configure trust (e.g. an Azure federated credential, AWS IAM role trust policy, or GCP WIF pool) for the Workload Identity Federation (WIF) issuer and subject that the BBD's runs will actually present. Today there is no direct, supported way to read this WIF information via Terraform for a given BBD. As a workaround, we read the WIF issuer from meshstack_integrations (which exposes the replicator's WIF info) and derive the BBD's subject via string manipulation, relying on the fact that the replicator and the runner happen to share the same issuer but use different subject/audience claims. This workaround is fragile since it depends on undocumented implementation details that could change, and it makes backplane code harder to read and maintain. Proposed Solution Provide a supported way to retrieve a BBD's WIF issuer and subject via Terraform. A few possible solution directions (not mutually exclusive): Expose the WIF configuration ( issuer , subject ) as a computed attribute on the meshstack_building_block_definition resource/data source. Add a Terraform data source for meshstack_building_block_runner that, given a runner_ref (which is already required when deploying a BBD with a backplane), exposes the runner's workload_identity_federation configuration. The runner-based approach has an added benefit: since different runners can be configured with different WIF issuers, referencing WIF info through the runner would also provide a clean seam for migrating individual BBDs to a new WIF issuer over time, by switching their runner_ref to a differently-configured runner. We're not attached to a specific implementation, just to having a reliable, supported way to get this information without relying on undocumented cross-object assumptions.

The marketplace tag filter currently only offers tags defined on Building Block Definitions. Tags defined on Landing Zones cannot be used to filter the catalog and platforms disappear from the results entirely as soon as any tag filter is active. As a platform team, we classify our landing zones with tags such as Confidentiality (public / internal / confidential). Application teams browsing the marketplace should be able to filter by these classifications to quickly find platforms that offer a landing zone matching their workload's requirements. Today the only workarounds are indirect: policies hide non-compliant entries (invisible to the user, not an interactive filter), and duplicating landing zone tags onto building block definitions doesn't cover platforms at all.

Problem / Use Case When ordering something from the Marketplace (a service, building block, or tenant), the confirmation/submit action at the end of the form is not visually obvious. There's no distinct button (e.g. with an arrow or clear call-to-action styling) indicating how to proceed. This is especially confusing for short forms with little content below the fold, where users don't expect to need to scroll or look further for a next step. Proposed Solution Add a clearly visible, consistently placed call-to-action button at the end of every order form, styled to stand out so users immediately recognize how to continue. Ideally the wording adapts to what's actually being ordered, for example: "Add building block to workspace/tenant" "Add tenant to project" "Add service to workspace/project"

Anyone in our organization can create a workspace. When people are offboarded, their user in meshStack is deleted via SCIM. The problem we face is, that sometimes the last person in a workspace is offboarded and no one has an eye on costs that are accumulating in this workspace. Would be great to see this in the Actions Needed section in the meshStack admin area.

Problem / Use Case Preflight runs let platform engineers preview changes before they're applied. Today, Terraform-based Building Blocks support this well, but Building Blocks that trigger pipelines (GitHub Actions, GitLab, Azure DevOps) don't have a reliable, consistent way to distinguish a preflight run from a real apply run inside the pipeline itself. This makes it hard to build a pipeline that safely previews changes without risking an unintended apply. Proposed Solution Give pipeline-based Building Blocks (GitHub Actions, GitLab, Azure DevOps) first-class, consistent support for preflight runs, so pipeline authors can reliably detect and handle a preflight the same way across all three integrations.

When a project deletion is requested, meshStack immediately removes every user and group role assignment on the project. If an administrator then denies the deletion, the project returns to active and its tenants are reinstated — but the roles are not. The project comes back empty, and someone with workspace-level rights has to add every member again by hand. They also have to know who held which role beforehand, since nothing in the restored project records what was there. We'd like a denied project deletion to leave the project exactly as it was before the request: Roles restored — every user and group role assignment on the project is reinstated, with its original role and expiry date Cloud access restored — the reinstated assignments are replicated, so application teams regain access to the project's tenants in the cloud platforms

As the owner of a workspace I want to receive a summarized e-mail of everyone that is about to lose access in my workspace so I can be made aware of the fact and timely do the role recertification in my workspace.

Problem / Use Case In the Admin Area under Access Control - All Users, it is not possible to filter the user list by status (e.g. "deactivated"). On large meshStack deployments with many users, this makes it difficult to identify and act on deactivated accounts. Proposed Solution Add a status filter to the Access Control - All Users table so platform engineers can quickly filter for deactivated (or active) users, making user lifecycle management more efficient.