# MetadataType (Complex Type)

### Namespace: http://midpoint.evolveum.com/xml/ns/public/common/common-3

Meta-data about data creation, modification, etc. It may apply to objects but also parts of the object (e.g. assignments).

Meta-data only apply to successful operations. That is obvious for create, but it also applies to modify. For obvious reasons there are no metadata about delete. We keep no metadata about reading. That would be a huge performance hit.

Meta-data only describe the last operation of its kind. E.g. there is a record of last modification, last approval, etc. There is no history. The last operation overwrites data about the previous operation.

These data are informational only. They should not be used for security purposes (use auditing subsystem for that). But presence of metadata simplifies system administration and may provide some basic information "at the glance" which may be later confirmed by the audit logs.

Meta-data are also supposed to be searchable. Therefore they may be used to quickly find "candidate" objects for a closer examination.

Item Summary
Name | Type | Multiplicity | Description
--- | --- | --- | ---
requestTimestamp | property dateTime | [0,1] | The timestamp of "create" operation request.
requestorRef | reference ObjectReferenceType | [0,1] | Reference to the user that requested the "create" operation for this object or assignment.
requestorComment | property string | [0,1] | Comment of the user that requested the "create" operation for this object or assignment.
createTimestamp | property dateTime | [0,1] | The timestamp of data creation.
creatorRef | reference ObjectReferenceType | [0,1] | Reference to the user that created the data.
createApproverRef | reference ObjectReferenceType | [0,-1] | Reference to the user that approved the creation of the data (if there was such a user).
createApprovalComment | property string | [0,-1] | Comments of the approvers during the creation of the data.
createApprovalTimestamp | property dateTime | [0,1] | The timestamp of creation approval.
createChannel | property anyURI | [0,1] | Channel in which the object was created.
createTaskRef | reference ObjectReferenceType | [0,1] | Reference to the task that created the object (if it was a persistent one).
modifyTimestamp | property dateTime | [0,1] | The timestamp of last data modification.
modifierRef | reference ObjectReferenceType | [0,1] | Reference to the user that modified the data.
modifyApproverRef | reference ObjectReferenceType | [0,-1] | Reference to the user that approved the last modification of the data (if there was such a user).
modifyApprovalComment | property string | [0,-1] | Comments of the approvers during the last modification of the data.
modifyApprovalTimestamp | property dateTime | [0,1] | The timestamp of last modification approval.
modifyChannel | property anyURI | [0,1] | Channel in which the object was last modified.
modifyTaskRef | reference ObjectReferenceType | [0,1] | Reference to the task that last modified the object (if it was a persistent one).
lastProvisioningTimestamp | property dateTime | [0,1] | The timestamp last provisioning operation that was based on this object.
certificationFinishedTimestamp | property dateTime | [0,1] | When last certification related to this item was finished.
certificationOutcome | property string | [0,1] | Outcome (URI) of the last certification.
certifierRef | reference ObjectReferenceType | [0,-1] | Reference to the user that certified the data.
certifierComment | property string | [0,-1] | Comments of the certifiers during the last certification of the data.
originMappingName | property string | [0,1] | Identifies the mapping that caused the automated creation of this object or assignment.

- ### Items

  - #### requestTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    The timestamp of "create" operation request. It is set once and should never be changed.

    In case of "background" processes to create object (e.g. create with approval) this should be the timestamp when the process started. I.e. the timestamp when the operation was requested.

  - #### requestorRef

    Flags: RAM,oper

    Multiplicity: [0,1]

    Reference to the user that requested the "create" operation for this object or assignment.

  - #### requestorComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Comment of the user that requested the "create" operation for this object or assignment.

  - #### createTimestamp

    Flags: RAM,runtime,oper,I

    Multiplicity: [0,1]

    The timestamp of data creation. It is set once and should never be changed.

    In case of "background" processes to create object (e.g. create with approval) this should be the timestamp when the process ended. I.e. the timestamp when the operation was executed.

  - #### creatorRef

    Flags: RAM,oper

    Multiplicity: [0,1]

    Reference to the user that created the data.

  - #### createApproverRef

    Flags: RAM,oper

    Multiplicity: [0,-1]

    Reference to the user that approved the creation of the data (if there was such a user). This is multi-value reference therefore multiple approvers may be recorded. However the order and hierarchy of the approvers is lost.

  - #### createApprovalComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,-1]

    Comments of the approvers during the creation of the data. Note that these comments are in no particular order, so basically it is not known who entered which comment.

  - #### createApprovalTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    The timestamp of creation approval.

  - #### createChannel

    Flags: RAM,runtime,oper,I

    Multiplicity: [0,1]

    Channel in which the object was created.

  - #### createTaskRef

    Flags: RAM,oper

    Multiplicity: [0,1]

    Reference to the task that created the object (if it was a persistent one). If the task was a subtask, then the reference to the task tree is stored here.

  - #### modifyTimestamp

    Flags: RAM,runtime,oper,I

    Multiplicity: [0,1]

    The timestamp of last data modification. It should be updated to a current time when the object is modified. The modifications that change only operational attributes may not update the modify timestamp.

  - #### modifierRef

    Flags: RAM,oper

    Multiplicity: [0,1]

    Reference to the user that modified the data.

  - #### modifyApproverRef

    Flags: RAM,oper

    Multiplicity: [0,-1]

    Reference to the user that approved the last modification of the data (if there was such a user). This is multi-value reference therefore multiple approvers may be recorded. However the order and hierarchy of the approvers is lost.

    Even though this is multi-value reference it will get overwritten after each approval. The multiple values are used only if all the approvers are known at the same time, e.g. if multi-level approval is evaluated at the same time. But generally this refers only to the last approval event.

  - #### modifyApprovalComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,-1]

    Comments of the approvers during the last modification of the data. Note that these comments are in no particular order, so basically it is not known who entered which comment.

    Even though this is multi-value property it will get overwritten after each approval.

  - #### modifyApprovalTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    The timestamp of last modification approval.

  - #### modifyChannel

    Flags: RAM,runtime,oper,I

    Multiplicity: [0,1]

    Channel in which the object was last modified.

  - #### modifyTaskRef

    Flags: RAM,oper

    Multiplicity: [0,1]

    Reference to the task that last modified the object (if it was a persistent one). If the last modification was carried out by synchronous task, this reference will be empty. If the task was a subtask, then the reference to the task tree is stored here.

  - #### lastProvisioningTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    The timestamp last provisioning operation that was based on this object. E.g. the timestamp of last modification of any account based on the data from the user. This value is only updated if there was any real change in the resource.

    This meta-datum is used as an informational property that tells when the data were last synchronized in outbound direction. But it has another important role. It is used indirectly to trigger optimistic locking conflicts that are used to detect a "clean" recompute (i.e. recompute that is processing data without any outside interaction).

  - #### certificationFinishedTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    When last certification related to this item was finished. Only certifications that resulted in non-null outcome are taken into account.

  - #### certificationOutcome

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Outcome (URI) of the last certification. Only certifications that resulted in non-null outcome are taken into account.

  - #### certifierRef

    Flags: RAM,oper

    Multiplicity: [0,-1]

    Reference to the user that certified the data. Contrary to approver/modifierRef, this field is filled-in also when certifier denies the item status. Only certifications that resulted in non-null outcome are taken into account.

  - #### certifierComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,-1]

    Comments of the certifiers during the last certification of the data. Note that these comments are in no particular order, so basically it is not known who entered which comment.

    Even though this is multi-value property it will get overwritten after each approval.

    Only certifications that resulted in non-null outcome are taken into account.

  - #### originMappingName

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Identifies the mapping that caused the automated creation of this object or assignment.