You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The initial problem and possible solutions were started to be discussed internally.
As the BTP provider doesn't support changes on subaccountAdmins on existing resources, once a Subaccount has been created with a certain list of users in subaccountAdmins, in case it changes, it will not only refuse to update the admins, but will as well refuse any other change of other attributes in that resource, which will block any updates on older Subaccounts.
Describe the solution you'd like
By renaming attribute subaccountAdmins with initialAdmins (I assume by deprecating one and introducing the other as a new one), the communication becomes clear that future updates of the Subaccount resource will ignore this attribute. Therefore, it's possible to allow Subaccount to be updated even if the list of admin users don't match with the initial one.
Describe alternatives you've considered
Another possibility would be just to turn the validation for subaccountAdmins into a warning, without blocking updates.
Additional context
Not additional context.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The initial problem and possible solutions were started to be discussed internally.
As the BTP provider doesn't support changes on
subaccountAdmins
on existing resources, once a Subaccount has been created with a certain list of users insubaccountAdmins
, in case it changes, it will not only refuse to update the admins, but will as well refuse any other change of other attributes in that resource, which will block any updates on older Subaccounts.Describe the solution you'd like
By renaming attribute
subaccountAdmins
withinitialAdmins
(I assume by deprecating one and introducing the other as a new one), the communication becomes clear that future updates of the Subaccount resource will ignore this attribute. Therefore, it's possible to allow Subaccount to be updated even if the list of admin users don't match with the initial one.Describe alternatives you've considered
Another possibility would be just to turn the validation for
subaccountAdmins
into a warning, without blocking updates.Additional context
Not additional context.
The text was updated successfully, but these errors were encountered: