An object that represents lookup table. The lookup table can be used for two purposes: value enumerations (e.g. for GUI or validation) and value mapping (translation). The same lookup table can serve both purposes at the same time.
The content of the lookup table can be used as enumeration. E.g. the labels for each table row can be displayed in the user interface. When a particular label is selected then the associated key will be stored. Similar approach can be used for validation, e.g. when only a selected set of values is legal for a certain property. In this case the "key" and "label" columns are used.
The content of the lookup table can also be used for value mapping. E.g. in cases when input value needs to be mapped to the output value. In this case the "key" and "value" columns are used.
Even though the lookup table is represented as a prism object, it is designed to be stored and queried efficiently. Therefore the contents of the lookup table will be stored in a specialized table tuned for this purpose. This data type is not designed to be used with the usual midPoint query mechanism (e.g. searchObjects operation). Specialized operations are used to efficiently query the lookup tables. The prism representation (e.g. XML) of the lookup tables is used only for backup, restore, migrations, upgrades and similar purposes.
Name | Type | Multiplicity | Description |
---|---|---|---|
name |
property PolyStringType |
[0,1] | Human-readable, mutable name of the object. |
description |
property string |
[0,1] | Free-form textual description of the object. |
fetchResult |
property OperationResultType |
[0,1] | Result of the operation that fetched this instance of the object. |
extension |
container ExtensionType |
[0,1] | Extension container that provides generic extensibility mechanism. |
parentOrgRef |
reference ObjectReferenceType |
[0,-1] | Set of the orgs (organizational units, projects, teams) that the object relates to. |
trigger |
container TriggerType |
[0,-1] | Triggers for this object. |
metadata |
container MetadataType |
[0,1] | Meta-data about object creation, modification, etc. |
tenantRef |
reference ObjectReferenceType |
[0,1] | Reference to the tenant to which this object belongs. |
lifecycleState |
property string |
[0,1] | Lifecycle state of the object. |
operationExecution |
container OperationExecutionType |
[0,-1] | Description of recent operations executed on this object (or related objects, e. |
policySituation |
property anyURI |
[0,-1] | The policy situation(s) of this object. |
triggeredPolicyRule |
property EvaluatedPolicyRuleType |
[0,-1] | Triggered policy rules for this assignment. |
policyException |
container PolicyExceptionType |
[0,-1] | Recorded exception from a policy rule. |
row |
container LookupTableRowType |
[0,-1] | Data structure that represents entire content of the lookup table, organized into table rows. |
Flags: RAM,runtime
Multiplicity: [0,1]
Human-readable, mutable name of the object. It
may also be an identifier (login name, group name).
It is usually unique in the respective context of
interpretation. E.g. the name of the UserType subtype
is usually unique in the whole system.
The name of the ShadowType subtype is usually unique in the
scope of resource (target system) that it belongs to.
The name may not be human-readable in a sense to display
to a common end-user. It is intended to be displayed to
IDM system administrator. Therefore it may contain quite
a "ugly" structures such as LDAP DN or URL.
Name is mutable. It is considered to be ordinary property
of the object. Therefore it can be changed by invoking
usual modifyObject operations. However, change of the name
may have side effects (rename process).
Although name is specified as optional by this schema, it
is in fact mandatory for most object types. The reason for
specifying the name as optional is that the name may be
generated by the system instead of supplied by the clients.
However, all objects stored in the repository must have a name.
Flags: RAM,runtime
Multiplicity: [0,1]
Free-form textual description of the object. This is meant to
be displayed in the user interface.
Flags: RAM,runtime,oper
Multiplicity: [0,1]
Result of the operation that fetched this instance of the object.
It is mostly used to indicate that the object is not complete or
there is some problem with the object. This is used instead of
exception if the object is part of larger structures (lists as in
list/search operations or composite objets). If not present then
the "SUCCESS" state is assumed.
This field is TRANSIENT. It must only be used in runtime. It should
never be stored in the repository.
Flags: dyn,RAM,runtime
Multiplicity: [0,1]
Extension container that provides generic extensibility mechanism.
Almost any extension property can be placed in this container.
This mechanism is used to extend objects with new properties.
The extension is treated exactly the same as other object
properties by the code (storage, modifications, etc), except
that the system may not be able to understand their meaning.
Flags: RAM,oper
Multiplicity: [0,-1]
Set of the orgs (organizational units, projects, teams) that the object relates to.
This usually means that the object belongs to them but it may have other meanings as well
(e.g. user manages an organizational unit).
Flags: RAM,runtime,oper
Multiplicity: [0,-1]
Triggers for this object. They drive invocations of corresponding trigger handlers
at specified time.
Flags: RAM,runtime,oper
Multiplicity: [0,1]
Meta-data about object creation, modification, etc.
Flags: RAM
Multiplicity: [0,1]
Reference to the tenant to which this object belongs. It is a computed value set automatically
by midPoint. It is determined from the organizational structure. Even though this value is
compted it is also stored in the repository due to performance reasons.
Flags: RAM,runtime
Multiplicity: [0,1]
Lifecycle state of the object. This property defines whether the
object represents a draft, proposed definition, whether it is active,
deprecated, and so on.
There are few pre-defined lifecycle states. But custom lifecycle states
may also be defined. Pre-defined lifecycle states are:
Flags: RAM,runtime,oper
Multiplicity: [0,-1]
Description of recent operations executed on this object (or related objects, e.g. shadows
in case of a focal object). The number of operations to be kept here is configurable.
Flags: RAM,runtime,oper
Multiplicity: [0,-1]
Flags: RAM,runtime,oper
Multiplicity: [0,-1]
Flags: RAM,runtime
Multiplicity: [0,-1]
Flags: RAM,runtime
Multiplicity: [0,-1]