Background

Why field ≠ field type ≠ data field

Field, field type and data field sound alike and mean different things. If you mix them up, you end up asking questions that have no answer: “Why has my text field turned into a date?”, “Why can’t I see the field here?”, “Why does the database contain something different from the form?”

The levels

The field type is the type. There is a fixed list that comes with Moliri: text, selection list, number, date, switch, image, file, address, authority record, geolocation, JSON and a few more. It determines which input appears in the form, in what form the value is stored and which configuration keys exist. You do not create field types, you choose them. Full list under Field types .

The field is the definition in this instance: there is a field called Objekthöhe (object height), it is a number, its units are mm, cm and m, it belongs to the field group Maße (dimensions), and it is defined who may read it and who may write it. Administrators create fields. They apply across the whole instance. Reference: Fields .

The data field is the value of a field on an object: object 10360 has the value 118.5 in the field Objekthöhe. It includes the annotations (colour, comment, source, “uncertain”) and the history. Day-to-day work deals with this level.

That leaves a fourth level, which stores nothing itself: the layout (input form). It is an arrangement of fields on a surface. The same field can sit on three forms, in different places, at different sizes, with different labels. The value is the same everywhere. Reference: Layouts .

What the separation is good for

One form per task instead of one for everyone. Conservation sees twelve fields, loans thirty others, and both work on the same objects.

Relabelling without renaming. In the database the field is permanently called work height. The German form says “Höhe”, the English one “Height”. Templates and filters work with the stable name, the interface with the label.

Permissions per field, not per form. A field can be readable for one group, writable for another and invisible to a third, regardless of which form it sits on.

Values survive rebuilds. Rearranging a form, taking a field off a form, deleting an entire layout: none of these touches the values. Values belong to the field.

What the separation costs

Because the field is the definition, its name is the string that everything else uses to point to it: filters, Excel presets, Word templates ($o[`work height`]), standard mappings, virtual fields. So renaming a field is not a cosmetic change.

If you want a different name, change the label on the layout. You can choose it freely, it can differ from form to form, and it breaks nothing.

The raw value

What the form shows is not always what is stored. A number is kept in the database without thousands separators and in the base unit, and is displayed formatted and with its unit. An image field stores a file ID instead of the file name, an address field a reference to the person in the address book.

Filters and bulk edit work on the stored value. That is why the field metadata shows it explicitly. Details under Field types .

Where the configuration lives

Every field carries a configuration: the values for a selection list, the units and number format for a number, the columns for a JSON field. It is part of the field definition and therefore applies across the instance.

If an institution needs something different in a single project, the setup can override individual keys of the configuration for that project, in the field administration under Per-project overrides. Reference: Field configuration . This is not the same as project-specific values : there it is not the configuration that differs but the stored value.

Further reading