Table of Contents

Dynamic forms (eav)

Dynamic form instances (values) are saved in the individual tables according to the entity which they are linked to ⇒ which is their owner (e.g. the entity IdmIdentityFormValue, IdmRoleFormValue). Form values are not saved, if null value (by persistent type) is given ⇒ filled values are saved only.

FormService service for working with the extended attributes on the back-end. FormInstance utility is useful on BE - contains value transformation to maps by attributes etc.. Use this service in your custom module, benefits:
  • single autowired service for work with definitions, attributes and values
  • cache core:form-definition-cache for loading form definitions (with attributes) is effective here.
On the front-end, the editing of dynamic forms is done by the component EavForm.
Saving form values for the form definition work as PATCH. When attribute value has to be deleted, then form value with null has to be given (use it even for multi valued attributes).
If single attribute is saved (FormService#saveAttribute), then event EAV\_SAVE is not published. Save all attributes (FormService#saveValues), if publishing event EAV_SAVE for owner is needed.

Dynamic form attribute supports data types (persistentType):

Changing persistentType and confidential is possible only for attributes without persisted values ⇒ when attribute is not used for some values. Data migration, when attribute's persistentType or confidential is changed is not supported now.

with properties:

Dynamic form attributes can be rendered differently on frontend. Face type (faceType) property is used for choosing frontend renderer. The default renderer is chosen by persistent type (e.g. UUID → UUID).

Renderer is a frontend component, superclass component AbstractFormAttributeRenderer is used for all renderer implementations. Renderer is responsible for IdmFormValue ⇔ input value transformation.

Renderers are registered in module's component-descriptor.js as single component with attributes:

All component descriptor features are supported. Read tutorial, how to create custom form attribute renderer.

Custom configuration can be added to registered renderers (@since CzechIdM 10.8.0) - use AbstractFormAttributeRenderer on backend to define additional renderer properties.

Adding the support of extended attributes for a new entity

Backend

Frontend

Agenda for working with forms

On the FE, there is an agenda of forms - their definition and attributes. Each definition can contain zero or more attributes. To maintain the integrity, an interface UnmodifiableEntity has been created, which allows adding a flag that the entity has been created by the system and cannot be modified (or some of its attributes) and deleted (this logic now needs to be implemented manually into the relevant controllers), for example in IdmFormAttributeController.

Data migration, when attribute's persistentType or confidential is changed is not supported now.

Localization

Beware, form type, form code and attribute code is used for composing the key for localization and in the string all special characters (white spaces, dots, colons etc.) will by replaced by dash (spinal-case or kebab-case on frontend).

Example form code eu.bcvsolutions.idm.acc.entity.SysSystem will be transformed into eu-bcvsolutions-idm-acc-entity-syssystem

Read more in tutorial

Validation

For form attribute values is possible to configure prepared validations. Validation are evaluated (on the backend), when form with extended attributes is saved and sent to backend. Simple validations as required, min, max are evaluated on frontend after value is changed.

Validations are suported for single attribute values only for now (feature request #1874).

Required

Value is required.

Unique

Value has to be unique.

Unique validation is not supported for BYTEARRAY and ATTACHMENT persistent types.

Min, Max

Value has to be greater than (lesser than) or equal given min (max) values. Real number (38,4) can be configured.

Min and max validation is supported for numeric DOUBLE, INT, LONG persistent types.

Regex

Value has to match given regular expression (java pattern is used).

Unique validation is not supported for BYTEARRAY and ATTACHMENT persistent types.
Use single back slash for configure regex on GUI ⇒ use double back slash in java. Example regex for the ip v4 address:
  • GUI: ^([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])$
  • java: ^([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])$

Validation message

Custom validation message. If message is not defined, then default message by invalid validation type will be shown.

Can contain localization key (e.g. core:validationError.invalid.unique). Parameters min, max, regex, unique, required is available for localization message.

Code lists

Use CodeListManager for creating and providing code lists and items through application on backend (e.g. available for scripts, which could be used in provisioning).
Use CodeListSelect and CodeListValue for rendering code lists on frontend.
Frontend localization is supported in the item's name. For example item with name environment.development.title will be localized.

Authorization policies support

Identity form values can be secured by authorization policies when some identity extended attributes have to be secured - see how in configure authorization policies.

Authorization policies only support identity extended attribute values. Support for other entities can be added in the future.

Future development