Tags should be mandatory and restricted at the same time
L
Lars Töpfer
Why?
We use the TAGS from input values for building blocks.
At the moment we can only say that the TAG is mandatory or immutable by the end user. Both together is not possible.
Yes, there is the option "Immutable", but in some cases it is important that at least the administrators could adjust the value.
Current workaround is to adjust the config of the TAG, change it and then bring the TAG config back to the original state -> but this is time-consuming and cumbersome...
Photo Viewer
View photos in a modal
J
Johannes Rudolph
Hi Lars, we looked into our history and found a closely related request from 2022:
"Immutable tags should be editable by Partner Admin"
- which is why we merged those two threads.Here is a summary of where things stand with the current tag restriction modes:
Immutable
- the user sets the value once during creation, and nobody can change it afterward (not even admins, without first removing the immutable flag from the tag definition). This is the closest to your use case, but too strict.Restricted
- only admins can set or change the value. Cannot be made mandatory, because workspace users never see the field to fill it in.What you need
- a mode where the user sets the value once (mandatory at creation), and after that only admins can change it. We sometimes call this "enter-once" or "admin-editable immutable".As Jelle mentioned above, one path forward would be to adapt the Immutable behavior so that admins can still edit the value (with a confirmation step), rather than having to toggle the immutable flag on and off as a workaround. That would cover both this request and the 2022 one.
In the meantime, the Terraform-side options Jelle suggested (e.g.
ignore_changes
or prevent_destroy
) are worth exploring as a short-term mitigation for the building block rename problem.J
Johannes Rudolph
Merged in a post:
Immutable tags should be editable by Partner Admin
Y
Young-Hwan Kim
Immutable tags are a really nice thing as it enables normal user to setup the tag value in the customer or project creation workflow.
In some cases it is required that Parter Admins can change the value of the immutable tag
Use Case:
Customer is created with the tag Cloud "marketplace only" - as the customer can only consume services from the marketplace.
After a certain time period the need arises for a AWS Account. Therefore the Cloud tag must change to "Public Cloud + Marketplace".
The Tag cannot be change by anyone. The only workaround is:
The Partner Admin must first change the Tag definition and remove the immutable flag, change the tag value and set the immutable flag again.
Jelle den Burger
Hi Lars, thanks for the feedback
I assume we do it this way because restricted tags need to be entered by admins, and those cannot be entered by workspace users.
So if we would allow this, the user would skip this tag and then it's empty and that kind of defeats the purpose of "mandatory".
But if you are okay with that it might be fine and we could show a warning to you accepting the drawback of empty tags.
Could you maybe explain a bit more what you're trying to do? Perhaps there are some other options.
L
Lars Töpfer
Jelle den Burger
Hi Jelle,
I asked for the following reason.
We create resources in azure via building blocks. so that these are always unique, I pull the values from the TAGs and use them to create the name in azure.
If these tags are now changed and a new run of the building block is started, the resources are deleted and recreated. This is of course a no go in a prod environment.
But the TAGs have to be entered by the user, otherwise we will get lost in low brain work.
Therefore we wanted to set the TAGs mandatory and restricted at the same time.
Jelle den Burger
Lars Töpfer
Hi Lars, thanks for the extra context!
Before we go down the route of a new restriction mode, I'd like to explore whether this could be solved on the Terraform/Building Block side first:
- Is there a way to generate the resource name independently of the tag (e.g. from a random suffix or a dedicated input that's separate from the tag)?
- Or could you use a Terraform lifecycle rule like prevent_destroy = trueorignore_changesto protect the resource from being recreated even if the input changes?
That might avoid the problem at the source without needing any platform changes.
Also, as I mentioned in another feature request, we're currently working on drift detection & approvals, which will give you much more control over when Building Block changes actually get applied. That could be another safety net for exactly this kind of scenario.
If neither of those options work for your setup, we could look at introducing an "Admin-only editable" restriction mode — similar to Immutable, but where platform admins can still adjust the value when needed.
Alternatively, we might also be able to adapt the "Immutable" implementation to actually allow editing as admins. Because you can also uncheck the "Immutable" from the tag definition we might as well allow you to make edits.
R
Rebecca
In the case described the tag should not be immutable. We advise to use a restricted tag that can only be updated by partner users. For more information please have a look at our documentation here -> https://docs.meshcloud.io/docs/meshstack.metadata-tags.html#how-to-modify-an-existing-tag