Adding Custom Fields
Administration -> Custom Fields -> Custom Fields
Last updated
Administration -> Custom Fields -> Custom Fields
Last updated
In older versions of Converia, custom fields are still referred to as EAV fields.
Custom fields (formerly EAV fields) are additional fields that can query further information during participant registration, submission of contributions, and in personal data (C3).
Typically, each custom field requires a data field and two associated form references. In total, you need three entries for a functioning additional field: one form reference in the frontend to display a fillable form field, and one form reference in the backend to retrieve the information in the backend.
New Custom Fields can be created by adding an entry via Add data field.
Name
The Name is used to uniquely identify and assign the Custom Field and the associated field references in the system.
Reference
The Reference depends on whether the Custom Field is intended for the registration or personal data (in this case: type = PERSON) or for the submission of contributions (in this case: type = PAPER).
Data type
Selecting the Data type determines what type of information is stored in the Custom Field.
It is important to select the correct Data type, otherwise the information in the additional field will not be saved correctly or at all.
A file upload in the frontend registration (step personal data) is currently not implemented or possible!
Sobald das Feld angelegt wurde, fehlen noch die Formularbezüge. In der Regel ist immer ein Formularbezug im Backend (BE Person / BE Paper) nötig und ein Formularbezug im Frontend an der gewünschten Stelle. Für ein Zusatzfeld müssen also zwei identische Felder erstellt werden.
As soon as the field has been created, the Form references are still missing. As a rule, a form reference is always required in the backend (BE Person / BE Paper) and a form reference in the frontend at the desired location. Two identical fields must therefore be created for an additional field.
Name of the field
For the sake of clarity, the field name should be the same as for the Custom field. In this case, it would be “Transport”.
The Displayed name is always displayed above the additional field in the frontend, while the Description is displayed below. If the event is multilingual, the Displayed name and Description must be entered in all languages.
Form
The correct form must be selected here.
It is always advisable to start with the front-end form. The settings and view can then be conveniently checked there. If everything is as expected, the entries for the backend can be duplicated.
Element type
When choosing the element type, consider the specific needs of your form and ensure it aligns with the intended functionality. Select the appropriate checkboxes to determine whether the field should be mandatory for the user and if it should be visible in the form.
Note: The types "Headline" and "Paragraph" do not require a link in the backend form as they provide structure rather than data input. These only need a field in the frontend form to describe and divide other fields.
After selecting the element type, ensure it is compatible with the chosen data type or adjust it accordingly.
Element types: Exception for Headline and Paragraph
The field types Headline and Paragraph are not input fields but serve to describe and divide additional fields.
Headline and Paragraph should only be a single entry on a form and should not have a field reference or data field assignment, as this may cause errors when saving.
Once the EAV field has been created with the field reference to the BE field, the link to the frontend must be established.
To do this, go back to the EAV homepage by selecting Back to list. The previously created form can be accessed via the ⚙ (e.g., BE Person).
In this form, the field just created can be found. This entry can be duplicated. The duplicate (identified by the suffix _copy) can be further edited.
It is important that the original field and the duplicate have the same content to avoid distortions and misrepresentations in the system.
The only part that is changed in the duplicate is the form. Here, the desired location in the frontend is selected, in this example FE Registration step 3 participant details.
Possible locations for an additional field in the frontend are:
Once everything is correctly configured, the completed additional field appears in both the frontend and backend.
In step 3 of the registration, it looks as follows:
In the backend, all custom fields of type PERSON can be found in the personal data under the tab Additional Fields.
For the type PAPER, the additional fields can be found in the contribution details under the tab Configurable Fields.
So far, there are four validators for additional fields:
File size for file upload
File type for file upload
Number of characters for text fields
Number of words for text fields
Validators can be created by our developers on request.
Type: PERSON | Type: PAPER | Custom Fields | |
---|---|---|---|
Type: PERSON | Type: PAPER |
---|---|
Person - Numerical value (Integer)
Paper - Numerical value (Integer)
Select, checkbox, file (=Upload), Radio
Numerical value/ Selection
Person - Text single-line (Varchar)
Paper - Text single-line (Varchar)
TText (single line)
Short text (max. 250 char.)
Person - Text multi-line (Text)
Paper - Text multi-line (Text)
Text (multi line)
Text
Registration - Step personal data
Submission - step 1 general
Submission - step 3 author data
Submission - step 2 abstract
C3 - personal data
Session submission - step 1