Many components operate on properties that are retrieved from the database. These properties are accessed using a prefix, followed by a dot and the property name (for example: s.id, p.firstname, m.PV).
Some of these prefixes are base-level and are defined by the backend, such as:
p. — user profile properties, such as first name, email, and other profile-related fields.
m. — marketing plan properties, mostly calculated metrics of the account, for example m.Downline or m.PV.
In addition to these data-driven property types (which may vary dynamically in the database — some properties may be missing, some are always present, and some may exist for one client but not for another), there are also properties that are hardcoded into backend requests and responses. These include:
position. — position-related properties (currently known: position.tree_level).
s. — account properties, such as s.id (account ID). This prefix includes all properties of the AccountVM model.
parent-profile. — parent profile properties (same structure as p.).
parent. — properties of the parent account in the hierarchy (same structure as s.).
More details about these prefixes can be found by inspecting the backend code: api3: EntityPrefixes.ts.
It is important to note that all prefixes listed above fully support filtering and sorting in Downline, Frontline, and similar backend queries. The backend explicitly accounts for these prefixes in its operations.
This is not the case for some properties that are merely returned by the backend as part of different responses and models but cannot be used for filtering or sorting.
In ui2, such properties are prefixed with vm, which stands for View Model. As described above, these properties are suitable for data access and display, but they are not considered fully-fledged fields.
Examples include: vmdl.offset, vmdl.childrenCount, and similar fields.
Another local property type is t. (template). These are frontend-computed properties used only by the UI for internal rendering logic.
Currently available: t.level — an analogue of vmdl.level in downline responses. However, it is a superset and is injected into all hierarchical (tree-like) datasets. Regardless of whether the backend provides vmdl.level, t.level is always available and correctly calculated.
Another group of local, frontend-only properties are macro replacements with the prefix r. (replace). When a component is initialized, these macros are automatically replaced with actual properties.
Currently, there is only one such macro: r.id — before usage inside a component, it is automatically replaced with either s.id or s.externalId, depending on the gravity configuration.
Below is a list of commonly used and useful properties for the :properties attribute of components (without enumerating all p. and m. properties, as those are well-known and dynamic):
- position.tree_level — level relative to the absolute root of the tree
- s.id, s.externalId — account identifiers
- s.status
- s.created_at
- s.activated_at
- parent.id, parent.status, parent.created_at, parent.activated_at — same as s.*, but for the parent account
- parent-profile.* — parent profile fields, for example parent-profile.email
- vmdl.id — position ID
- vmdl.level — level relative to the current root
- vmdl.treeLevel — absolute tree level
- vmdl.number — sequence number in the parent’s frontline
- vmdl.parentPositionId — parent position ID
- vmdl.offset — position offset
- vmdl.childrenCount — number of children
- vmdl.spillLeg — spillover leg
- t.level
- t.fullName
- t.namePlusId
- t.accountPlusOffset
- vmtl.* — properties of the TransactionLog model
- r.id — automatically replaced with s.id or s.externalId depending on gravity settings