This provider helps you managing your cidaas instances in an automated way. It enables you to configure and maintain apps and registration fields as part of a Terraform deployment. Secure – Fast – And unrivaled Swabian.
This PR fixes two issues regarding the integration registration fields into terraform.
The field className from the cidaas fields api was omitted which lead to the use of the default class name of FieldSetup in cidaas even if the correct class name for fields of type SYSTEM is de.cidaas.core.db.RegistrationFieldSetup AFAIU. This made System fields unusable when defined in TF. The change sets className based on the field type (SYSTEM or CUSTOM).
IMHO this should be fixed on the cidaas api level as the className field is not documented in the API documentation and seems to be some internal field an api user should have no business messing around with.
The serialization of the RegistrationFieldConfig was broken for boolean. The field tag json:"someField,omitempty" in conjunction with booleans leads to booleans with the value false to be omitted. This lead to fields not to be editable via the admin UI. As all the values are configured as required in the TF schema there is no need for to omit empty fields here.
Hi @resterle, we appreciate your effort to fix the bug. We have released the required fix in the version 2.5.3 with the fix that you shared in this PR. Sorry, we could not accept the pull request as we need to update our internal codebase. Closing this. Thank you!!
This PR fixes two issues regarding the integration registration fields into terraform.
className
from the cidaas fields api was omitted which lead to the use of the default class name ofFieldSetup
in cidaas even if the correct class name for fields of typeSYSTEM
isde.cidaas.core.db.RegistrationFieldSetup
AFAIU. This madeSystem
fields unusable when defined in TF. The change setsclassName
based on the field type (SYSTEM or CUSTOM).IMHO this should be fixed on the cidaas api level as the
className
field is not documented in the API documentation and seems to be some internal field an api user should have no business messing around with.RegistrationFieldConfig
was broken for boolean. The field tagjson:"someField,omitempty"
in conjunction with booleans leads to booleans with the valuefalse
to be omitted. This lead to fields not to be editable via the admin UI. As all the values are configured as required in the TF schema there is no need for to omit empty fields here.