What a type consists of
A type consists of four definitions side by side:
73 of the 98 types carry a
viewDefinition. The rest have no structured view —
they hold data but no detail page of their own; Software, Software Product
and the seven integration types are such cases.
Identifier and inheritance
Every type carries an identifier made of a prefix and a name:typedef::windows, typedef::proxmoxLxc, typedef::integrationSftp. It is
stable and language-independent; the label is neither.
Below it lies a second level. Every shipped type builds on a base definition of
the same name — typedef::windows on basedef::windows — and every base
definition in turn goes back to basedef::object. The export covers the
shipped level; the base definitions themselves are not part of it.
From the label to the field
A field on the detail page carries its label in both languages and, next to it, the property its value comes from. That is the path from what somebody sees to what you query:
A field also states how its value is to be read — as text, integer, decimal,
yes/no value, point in time, data volume, duration, frequency or network speed.
If it points to a value list, that list is named next to it: License Status
carries the property
licenseStatus and the list LicenseStatus.
Fields can be hidden out of the box. They then stand in the definition but not in
the view — Active User on the type Windows is one of them. Showing and hiding
is done under Adjusting the Data Model.
Value lists
Each type carries the value lists its own fields point to; across all types there are 241 different ones. Every entry holds three things: a key, a technical name and the label in both languages. Example for the integration types:The keys have gaps —
3 is missing in the example. Rely on the key, not on the
position in the list.The field level
The 73 views carry some 11,100 fields between them. Which fields a type carries is shown by the interface itself under Administration › Data Model › Types and Fields in the tab Fields — in one list, with standard fields and custom fields side by side. Custom fields do not change the shipped type. They sit next to it as a type extension: delete the extension and the custom fields are gone while the type remains — see Adjusting the Data Model.Technical names of custom fields
As with the shipped types, the label of a custom field points to a technical name. Docusnap365 derives it from the Display Name (German) when the field is created:- All letters are lowercased, umlauts are transliterated (ä → ae, ö → oe, ü → ue, ß → ss).
- All other characters separate words; at the start and the end they are dropped.
- The words are joined in camel case.
- The prefix of your subscription is put in front: six lowercase letters or digits, the
first character from
atof.
anzahlKerne, and with the prefix, for example,
f71378AnzahlKerne. The prefix keeps custom fields apart from the properties of
the shipped types: a custom field “Name” does not coincide with the name of the
asset.
If the derivation yields a technical name that is already taken, Docusnap365
appends a number without a message (f71378AnzahlKerne2). On creation, only
the display name is checked. The interface does not show the technical name
anywhere.