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.

Dynamic form attribute supports data types (persistentType):

• CHAR - one character
• TEXT - strings (long text). Searching by TEXT is not supported, column is not indexed - SHORTTEXT usage is preferred (+ indexed).
• SHORTTEXT - strings (2000 chars). Indexed.
• INT - integer
• LONG - long
• DOUBLE - saved as bigdecimal
• BOOLEAN - true / false / null
• DATE - date (without time)
• DATETIME - date with time
• BYTEARRAY - byte[]
• UUID - uuid identifier. Indexed.
• ATTACHMENT - attachment (~binary file). Read more about attachments.
• CODELIST - referenced code list - persists items "code" into short text. Uses face type as code list code.
• ENUMERATION referenced frontend enumeration - persists items "code" into short text. Uses face type as enumeration name.

with properties:

• readonly
• multi values - Is represented on the front-end by a textarea, where a line is a value (a new line separates the values). This property is supported for persistent types CHAR, TEXT, INT, LONG, DOUBLE and UUID.
• confidential - .The values are stored in an confidential storage). Stored values of these attributes - substitute characters only - are loaded on the front-end. The value can only be changed and determined whether it is filled in. This property is supported for persistent types CHAR, TEXT, INT, LONG, DOUBLE, UUID, BYTEARRAY.
• required - value validation, read more.
• unique - value validation, read more.
• min - value validation, read more.
• max - value validation, read more.
• regex - value validation, read more.
• validationMessage - custom message, when some validation fails, read more.

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:

• id - unique component identifier
• type = form-value - static component type is used for all form-value renderer
• persistentType - which persistent type renderer supports
• faceType - renderer face type ⇒ key. Unique face type should be given (by persistent type). Its optional persistentType is used as default, when no faceType is given.
• component - renderer implementation (AbstractFormAttributeRenderer descendant).
• labelKey - localization key ⇒ renderer name. Its optional, faceType is used, when no labelKey is given.

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 an interface implementation FormableEntity to the new entity,
• creating a manager implementation by inheriting AbstractFormableService for the new entity,
• creating the entity by inheriting AbstractFormValue, which will represent the values of extended attributes for the new entity (owner),
• creating a repository by inheriting AbstractFormValueRepository for the values of the extended attributes,
• creating the manager by inheriting AbstractFormValueService for the values of the extended attributes.

• issuing a REST endpoint for saving the extended attributes from the FE - e.g. IdmIdentityController - controller has to evaluate security to read / save form values by their owner (e.g. by identity),
• creating a service and redux manager communicating with REST by inheriting FormableEntityManager - e.g. IdentityManager,
• using the component EavForm for filling in and sending the values of the extended attributes from the FE to the BE - e.g. IdentityEav content.

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.

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

Read more in tutorial

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.

Value is required.

Value has to be unique.

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

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

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

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

• Form value data migration, when persistent type is changed.
• Attachment renderer: support multiple files, validation support (now is validation on input)
• Created deep copy, when form values are copied ⇒ attachment is linked to two form values and is removed, when the first one is deleted.
• #1874: Support unique validation for multivalued eav attributes