Field Definitions and related advanced field topics
Field Definitions (i.e., Field Specifications or Field Specs) were introduced in order to unify the handling of semantic and non-semantic (NS) fields, including custom fields defined by IRM users. That is, field Definitions provide a generic mechanism to describe all fields in the IRM system. From the user's perspective, a Field Definition is a template for the user's custom fields that appear in Managed Objects.
Technical considerations for IRM fields
Non-semantic fields can be added to most of the major IRM object types, including Equipment, Equipment Types, Categories, Cables, etc. A separate set of Field Definitions is kept for each Super Category, which means:
-
Managed (instance) objects and the corresponding Managed object Types share the same set of Field Definitions -- for example, Equipment and Equipment Type share the same Equipment Field Definition list
-
Category objects use Field Definitions from whichever Super Category they are in. In that sense a Category object in the Equipment hierarchy is fundamentally different from a Category object in the Cable hierarchy.
In the Field Settings dialog, Field Definitions are labeled as Available Fields. Just because a Field Definition exists for a Super Category, does not mean that every object in the Super Category carries that field, only that some objects may carry that field. However, it does put an overall bound on the “shape” or total set of fields of objects in the Super Category, which reduces the number of fields that need to be shown in the Grid Configurations for the Object Grid.
As explained in the parent topic, the Field Settings dialog has control over which fields are in which objects; it covers both creating/editing Field Definitions and assignment of Non-Semantic fields to objects. When a given Field Definition is “put into an object” in the Field Settings dialog, what happens is that the object gets an additional Non-Semantic field added to its list of Non-Semantic fields.
For example, if a field is added to an Equipment Category object called Routers all types assigned to that Category will inherit the Non-Semantic field assigned to the Category.
When integrating IRM with other products, REST representations of IRM objects, NS fields, appear no different from semantic fields. Both are ordinary data items in the JSON representation. This design is extremely efficient in terms of network bandwidth and both client and server performance, as added fields carry no overhead and is critical to IRM performance because IRM users often interact with thousands of objects carrying hundreds of fields each over short periods of time.
As explained in section Custom data fields, IRM implements pseudo-inheritance of fields from Categories to Types and from Categories and Types to instance objects. From the user’s perspective, non-semantic fields are inherited from Categories to Types, from Types to Managed objects, and from Categories directly to Managed objects in cases where there is no Type (e.g., Locations, Spaces, Areas, and Vendors). Also, the inherited fields can have their values overridden for specific child Category, Type, or instance objects.
In addition, IRM supports multiple inheritance of fields, which can happen because a single Type object, like an instance of Equipment Type, can be in multiple Categories. Each Category might independently include the same Field Definition, but each of these copies can still be independently overridden in the Type object because the names of the fields are still unique.
IMPORTANT: This inherent capability can lead to the same non-semantic appearing multiple times due to it being assigned to multiple object Categories. To avoid this situation, care should be taken to ensure that any non-semantic field is assigned once to the correct level within the Category and/or Type tree.
If a field is overridden in the Type object (e.g., an Equipment Type object) and then overridden again in the instance (e.g., Equipment object), the Non-Semantic field in the instance contains a reference to the original field. In the Equipment Properties dialog for example, the field only appears once, in the Category tab where it was originally defined, but with the overridden value set for this particular instance.
In this example, Department is a Non-Semantic field assigned by the Sample Equipment Category and it has an instance level override value of Marketing. The actual type, from a code or database point of view, of all non-semantic fields is a String. The Type property is used only as a hint to the IRM user interface of how the field is represented and how the entered data is validated.
As already mentioned, not all fields can be directly edited by the user, that is, not all fields appear in one of the generic fields tabs of an Object Properties dialog (e.g., Object, Type, or Category tabs in the Equipment Properties dialog) and can be edited there.
Whether or not this kind of editing is allowed is determined by the following rules:
-
Visibility - user cannot edit any objects in an Area that they do not have visibility permissions for, because they cannot see the objects in the first place.
-
Permissions - by default a user cannot edit any objects at all; they must be explicitly given permissions. In this case, the object Properties dialog operates in a special read-only mode and clearly indicates that mode.Even if an object is editable by the Visibility and Permissions criteria, any given field in the object may not be editable for any of the following reasons:
-
a derived field is not editable - a derived field is a field whose value is computed by the IRM server as a function of other fields in the object and/or in related objects
-
certain semantic field types are not editable (Reference, Array and Link)
-
some semantic fields are considered to be constant fields; these fields are not editable if the object has a reference in any other IRM object. This mechanism is used to protect certain critical fields in Types that define important characteristics of an object, such as the number and types of Ports it has.
E.g. Imagine what would happen if an Equipment Type was defined with 16 Ports and instances of that Type were created and Cables were connected to all 16 Ports, then the number of Ports was reduced to 8 in the Equipment Type. What should happen to all those connections which have been made to Ports 9-16 that no longer exist? The constant fields feature allows IRM to avoid those problems. Note that the condition of references to other objects can only be evaluated for a specific semantic field, it cannot be determined for the Field Definition. It is possible that one object’s field is editable whereas another object’s field isn’t, even if the two fields use the same Field Definition.
In summary, a given field in a given object is editable if and only if the object itself is editable according to rules 1 and 2 and the field itself is editable per rules a, b, and c. E.g. all non-semantic fields are editable as long as the user has permissions to edit the object.
Field Definition dialog
The following is a sample Field Definition dialog that opens when editing the Equipment Category's Department field:
The dialog is split into 2 sections:
-
Field Details - the top section that has a common layout and does not change.
-
Field Type Options - the bottom half that contains options specific to the selected Field Spec type selection.
The following images and text are examples of different Field Type Options for different Field Types.
