Hide building block inputs from end users
complete
Thomas Abbe
As a platform owner, I dont't want to see end users to see the input values (provided by platform owners) of building block, since many variables are potentially sensitive (Entra ID Object identifiers, AWS Access Keys, client certificates, ...). Although it is possible to encrypt variables, this could lead to huge security issues in case of a configuration error.
However, as a platform owner, I still need to see the bb input values for debugging purposes.
J
Johannes Rudolph
marked this post as
complete
Update: Static Inputs Now Hidden by Default
We've improved the building block inputs view in meshStack v2026.14.0.
What's available now:
- When viewing a building block's details, only user-relevant inputs are shown by default
- Static inputs (managed automatically by the platform, e.g. credentials, identifiers) are hidden by default
- Users can always reveal static inputs by clicking the "Show static inputs" button. Note: Users (as well as platform teams) can never reveal sensitive input values.
This focuses the building block view on the fields that matter to end users by default, reducing noise. We hope this strikes a good balance in terms of usability for platform teams and end users.
Future work:
At this time we have decided to not integrate a toggle for building block definition owners to add fine-grained control over which specific inputs are visible to end users. We believe the benefits do not outweigh the added complexity of this feature. We discussed the design options and see some fundamental problems for implementing this consistently for an API first use case. This is important to us as we see more and more application teams managing their building blocks via terraform as well.
If you'd like to share feedback on this implementation, or need help, reach out to support@meshcloud.io.
F
Fabian
Hi Jelle den Burger,
regarding 1.:
this is currently the case while ordering a new building block - but not when updating. so there is a mismatch what the user sees when creating vs updating.
this is a viable option (to make it the same when creating and updating), but does not allow full flexibility for the building block owner.
regarding 2.:
this would be my preferred option. there may be instances, where the block definition owner
wants
to show a static or predefined field to the user. this option allows that.of course, it also allows to hide credentials, etc. which are set by the block definition owner and is only relevant for backend processes, not to the user.
regarding 3.:
i think users who want to get a building block should not have that much information about what is set in the background. the user is only interested in "getting the functionality", not which AWS credentials are set in the background and used for e.g. the terraform state.
it might be an option though, combined with option 2.
my opinion is not strongly held here...
regards,
fabian
Jelle den Burger
Fabian I merged your post into this one. I would be very interested to learn what your desired behavior would be. I'm currently exploring a few possible options.
- Never show inputs that the user did not enter -> In this case we just always only show the inputs that the user can influence (if any)
- Let you as a building block definition owner decide what should be and should not be visible.
- Never show anything but let the user open a small window "View all inputs".
Or maybe you also have some ideas how you'd like to decide (or not decide) what should be shown.
Jelle den Burger
Merged in a post:
Hide input fields from users
F
Fabian
When users create a building from the marketplace, they are presented with the input fields they can control.
However when updating the building block, users see
all
inputs - even those which contain credentials (though encrypted), defined by the building block owners.There should be an option to hide those inputs from the user. The user shouldn't have to know that there is an AWS_ACCESS_KEY or similiar defined, the user should just see the parameters that are applicable to him.
Jelle den Burger
Thanks a lot for your feature request. We will discuss this internally how we can make this possible - either by making this the default or by giving you the ability to control this behavior.