ReportType (Complex Type)

Items

• name

  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.

• description

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Free-form textual description of the object. This is meant to be displayed in the user interface.

• documentation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  AsciiDoc-formatted technical documentation of the object.

• subtype

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Type of the object. It is used to distinguish what a specific object represents. Whether it is a different kind of organizational unit, project, team, or different kind of user, etc.

• fetchResult

  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 objects). 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.

• extension

  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.

• parentOrgRef

  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).

• trigger

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  Triggers for this object. They drive invocations of corresponding trigger handlers at specified time.

• metadata

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Meta-data about object creation, modification, etc.

• tenantRef

  Flags: RAM,oper

  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 computed it is also stored in the repository due to performance reasons.

• lifecycleState

  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:

  • draft: Definition of the new object in progress. The object is NOT active. The definition may change at any moment. It is not ready yet.
  • proposed: Definition of a new object is ready for use, but there is still a review process to be applied (e.g. approval). The object is NOT active. However the definition should not change in this state.
  • active: Active and working definition. Ready to be used without any unusual limitations.
  • deprecated: Active definition which is being phased out. The definition is still fully operational. But it should not be used for new assignments. E.g. it should not be requested, it should not be approved, etc.
  • archived: Inactive historical definition. It is no longer used. It is maintained only for historical, auditing and sentimental reasons.
  • failed: Unexpected error has occurred during object lifecycle. Result of that event is that the object is rendered inactive. The situation cannot be automatically remedied. Manual action is needed.

• operationExecution

  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.

• lensContext

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Model context describing executed operation

• policySituation

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  The policy situation(s) of this object. The situations are result of evaluation of the policy rules. This property is recorded for each object and can be used for reporting, diagnostics, target selection in certification campaigns, etc.

• triggeredPolicyRule

  Flags: RAM,runtime,oper

  Multiplicity: [0,-1]

  Triggered policy rules for this assignment. (Not necessarily complete; subject to specified storage strategy.) This is EXPERIMENTAL functionality. It is possibly to change in the near future.

• policyException

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Recorded exception from a policy rule. The exceptions that are approved are recoded here to avoid re-evaluating and re-approving them all the time. This is EXPERIMENTAL functionality. It is likely to change in the near future.

• diagnosticInformation

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Diagnostic information attached to this object.

• assignment

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Set of object's assignments. Assignments define the privileges and "features" that this object should have, that this object is entitled to. Typical assignment will point to a role or define a construction of an account.

  Assignments represent what the object SHOULD HAVE. The assignments represent a policy, a desired state of things (cf. linkRef).

• iteration

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Iteration number. Starts with 0. It is used to iteratively find unique identifier for the object.

• iterationToken

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Iteration token. String value that is usually a suffix to the identifier based on iteration number. E.g. ".007". It is used to iteratively find unique identifier for the object.

• archetypeRef

  Flags: RAM,oper

  Multiplicity: [0,-1]

  References to all applicable archetypes, including "indirect" archetypes such as archetype supertypes. Contains references to active archetypes only.

  Note: the value of this reference is only updated when object is recomputed. Therefore if a role definition changes then all the affected objects must be recomputed for this reference to be consistent.

  This is an operational property. It is set and managed by the system. It is used for efficient use of archetypes.

• roleMembershipRef

  Flags: RAM,oper

  Multiplicity: [0,-1]

  References to abstract roles (roles, orgs, services) that this focus currently belongs to - directly or indirectly. This reference points to all the roles in the role hierarchy. It only points to the roles that were evaluated as active during last recompute (conditions were true, validity constraints not violated).

  Note: the value of this reference is only updated when a focal object is recomputed. Therefore if a role definition changes then all the affected focal objects must be recomputed for this reference to be consistent.

  Roles mentioned here are those that are NOT obtained via delegation, i.e. "deputy" relations. Relations acquired by delegation are listed in delegatedRef item.

  This is an operational property. It is set and managed by the system. It is used for efficient search of all current role members, e.g. for the purpose of displaying this information in the GUI.

• delegatedRef

  Flags: RAM,oper

  Multiplicity: [0,-1]

  References to objects (abstract roles as well as users) obtained via delegation. If A1 is a deputy of A, its delegatedRef contains a union of A, A.roleMembershipRef and A.delegatedRef.

  This is an operational property. It is set and managed by the system. It is used for efficient search of all current role members, e.g. for the purpose of displaying this information in the GUI.

• roleInfluenceRef

  Flags: RAM,oper

  Multiplicity: [0,-1]

  References to abstract roles (roles and orgs) that this focus may directly belong to. This reference only points to the next role in the hierarchy. However, it is backed by a "closure" index in the repository subsystem. Therefore it can efficiently support tree-like queries. This reference points to the roles for whose the condition is not true. Therefore it does not reliably show who actually has a role. It shows potential role members - all the object that are possibly influenced when a role definition changes.

  This is an operational property. It is set and managed by the system. It is used for efficient search of all possible role members, e.g. for the purpose of recomputing all role members after the role definition is changed.

  TODO. NOT IMPLEMENTED YET. EXPERIMENTAL. UNSTABLE.

• reportEngine

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Selects which report engine should be used to render this report.

• parent

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Indicates whether this report is a parent report or subreport. This item is specific to JasperRepors.

• subreport

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Reference to subreport. This item is specific to JasperRepors.

• template

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Report template. This is definition of base query, report structure and so on. This item is specific to JasperRepors. But it may be reused for other report types.

• templateStyle

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Report style template. This defines colors and similar look and feel properties. This item is specific to JasperRepors. But it may be reused for other report types.

• orientation

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Report page orientation (portrait/landscape). This item is specific to JasperRepors. But it may be reused for other report types.

• export

  Flags: RAM,runtime,AVals:14

  Multiplicity: [0,1]

  Report output file format.

• useHibernateSession

  Flags: RAM,runtime

  Multiplicity: [0,1]

  This item is specific to JasperRepors.

• dataSource

  Flags: RAM,runtime

  Multiplicity: [0,1]

  This item is specific to JasperRepors.

• field

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Columns user definition. Name, type, report field, column name. This item is specific to JasperRepors.

• configuration

  Flags: dyn,RAM,runtime

  Multiplicity: [0,1]

  Report configuration based on report configuration schema. TODO This element belongs to ReportType and should not be used elsewhere. This is a top-level element to make the implementation (JAXB marshal/unmarshal) easier.

• configurationSchema

  Flags: RAM,runtime

  Multiplicity: [0,1]

  This element contains the XSD-formatted definition of schema. The schema available in this definition is expected to comply to the usual midPoint schema structure (properties, property containers), although it should not contain objects (persistent objects identified by OID). Note: This schema is considered to be available only in run-time. Therefore code-generation methods such as JAXB cannot be applied here. Note: xsd:any is here, but maybe a stricter type would be preferable. However xsd:any seems to be a common practice (e.g. SPML, WSDL). TODO: rename to CachedSchemaType

• virtualizer

  Flags: RAM,runtime,oper

  Multiplicity: [0,1]

  Optional name of Jasper virtualizer class.

  This item is specific to JasperRepors.

• virtualizerKickOn

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Number of pages after Jasper virtualizer kicks on. This item is specific to JasperRepors.

• maxPages

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Number of pages after Jasper cancels report execution. This item is specific to JasperRepors.

• timeout

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Timeout in [ms] after Jasper cancels report execution. This item is specific to JasperRepors.

• jasper

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Configuration for jasper-based reports. Only applicable if reportEngine=jasper.

• dashboard

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Configuration for dashboard-based reports. Only applicable if reportEngine=dashboard.

• defaultScriptConfiguration

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Default configuration for the scripts executed inside the report.

• postReportScript

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Command-line script that will be executed after the report is complete and the output file is completely produced. Output filename will be passed to the script as the "file" argument.