--- last_review: "2026-05-07" last_reviewer: "" documented_code: [ ] --- ```{tags} explanation, webinterface, edit-mode ``` # Understanding the Edit Mode The Edit Mode is the primary way to create, change, and delete entities in LinkAhead through the web interface. This page explains the concepts and design decisions behind it. ## What the Edit Mode Is The Edit Mode is a state of the LinkAhead WebUI that reveals interactive controls for modifying entities. In the default (view) mode the interface is read-only. When Edit Mode is active, each entity card gains create, edit, and delete controls, and the edit mode toolbox appears on the right side of the screen listing all available properties and RecordTypes. ## Permissions The Edit Mode is only accessible to users with sufficient privileges. Whether a particular user can create, edit, or delete specific entities depends on their role and the permissions configured by the LinkAhead administrator. User and group permissions are explained in detail in [Permissions](/explanation/general/permissions.md). ## Property Datatypes Every property has a datatype that determines which kind of values it can hold: - **TEXT** properties hold short and long strings of text. Newlines are also allowed. - **DOUBLE** properties hold numeric floating point values, such as 3.142. DOUBLE properties may have a unit; you can set a default unit (for example `kg` or `mm`) when creating or editing the property. - **INTEGER** properties hold (signed) integer values such as …, -2, -1, 0, 1, 2, …. They can have units just like DOUBLE properties. - **DATETIME** properties are for dates or datetimes (date plus time of day). LinkAhead does not distinguish between dates and datetimes — users can freely choose whether to include a time. - **BOOLEAN** properties can be either `TRUE` or `FALSE`. - **FILE** properties reference a File entity. Files are similar to normal Records, but do not require a RecordType and are connected to a binary file stored in the file system. - **REFERENCE** properties are links to other Records. You can optionally restrict which Records are accepted by specifying a RecordType. See the [datatype specification](/explanation/general/Datatype.md) for the full technical details. ## List properties A List property holds multiple values of the same datatype within a single property instance on an entity. This is useful when, for example, an experiment has multiple authors, or a sample has several measured values. When adding an existing property to a RecordType, you can choose whether it behaves as a list or a single-value property for that RecordType. This means you do not need to create separate "author" and "authors" property definitions — the same underlying property can serve both roles. ## REFERENCE properties and inheritance For REFERENCE properties, LinkAhead inheritance applies when determining which Records qualify as valid values. If you configure a REFERENCE property to accept "Experiment" Records, Records of any subtype — such as "Magnetism Experiment", if it inherits from "Experiment" — are also accepted. This lets you build flexible schemas where a single reference property accommodates an entire family of RecordTypes. ## Implicit REFERENCE properties via Drag-and-Drop It is not always necessary to explicitly create a REFERENCE property. In many cases when editing a RecordType, you can simply drag the target RecordType into the property area. For example, dragging "CellLine" into the properties of "CellCultureExperiment" automatically creates a REFERENCE property whose type is "CellLine", named after the dragged RecordType. **When to use drag-and-drop (implicit) vs. explicit REFERENCE properties:** - Use **drag-and-drop** when the reference relationship is straightforward and the RecordType name clearly conveys its meaning. - Create an **explicit REFERENCE property** when you need a custom name to distinguish the relationship's semantics — for example, two distinct REFERENCE properties to "Person", one named "experimenter" and one named "author". These carry different meanings and can coexist within the same RecordType. The same logic applies to list properties: rather than creating a separate list property, you can check the "List" checkbox when adding an existing non-list property to a RecordType. ## Lazy loading of Reference Dropdowns Dropdown menus for reference properties are not populated automatically when you start editing an entity. This is done for [performance reasons](https://gitlab.com/linkahead/linkahead-webui/-/issues/262): loading all possible values for all reference dropdowns at once can be slow when many entities exist in the database. Click the pencil icon next to the reference property to load its values on demand. To load all reference dropdowns immediately on entering edit mode, start LinkAhead with the `BUILD_EDIT_MODE_LAZY_DROPDOWN_LOADING = DISABLED` configuration option. ## Records vs. RecordTypes When Editing When editing entities in the WebUI, two key differences between Records and RecordTypes are relevant: - **Records must always have at least one parent RecordType.** Removing the last parent of a Record is not permitted. - **Properties on RecordTypes carry no values.** They define the schema — what properties a Record of that type may or must have. Only Records carry actual property values. - **Removing a property from a RecordType does not delete the property entity.** The property continues to exist in the database and can be re-added to the RecordType at any time. ## Entity Dependencies and why deletion can fail An entity cannot be deleted if other entities depend on it. Examples of such dependencies are: - A Record that uses the entity as a reference value. - A RecordType that is used as the parent of other entities. This constraint preserves the integrity of the data. Before attempting to delete an entity, check whether it is in use with queries such as: - `FIND Record WITH myentity` — finds Records that have `myentity` as a property or reference value. - `FIND Record MyRT` — finds Records of RecordType `MyRT`.