UserType (Object Definition)

Items

• name

  Flags: RAM

  Multiplicity: [0,1]

  Human-readable, mutable name of the object. It may also be an identifier (login name, group name). Should be unique in the respective context of interpretation. E.g. the name of the UserType subtype should be unique in the whole system. The name of the AccountType subtype should be unique in the scope of resource (target system) that it belongs to.

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

  Name is mutable. It can change any time. However, a special handling may be needed in some cases (e.g. "rename" provisioning flow).

  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

  Multiplicity: [0,1]

  Free-form textual description of the object.

• fetchResult

  Flags: RAM

  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.

• extension

  Flags: dyn,RAM,runtime

  Multiplicity: [0,1]

  Container that provides generic extensibility mechanism. Almost any extension property can be placed in this container. 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

  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

  Multiplicity: [0,-1]

  Defines triggers for an object. Trigger is an action that should take place at specified time or under some other condition.

• metadata

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Meta-data about object creation, modification, etc.

• tenantRef

  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.

• linkRef

  Flags: RAM

  Multiplicity: [0,-1]

  Set of shadows linked to this focal object. E.g. a set of accounts linked to a user. This is the set of shadows that belongs to the focal object in a sense that these shadows represents the focal object on the resource. E.g. The set of accounts that represent the same midPoint user (the same physical person, they are "analogous").

  Links define what the object HAS. The links reflect real state of things (cf. assignment).

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

• activation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Type that defines activation properties. Determines whether something is active (and working) or inactive (e.g. disabled). It applies to several object types. It may apply to user, account, assignement, etc. The data in this type define if the described concept is active, from when it is active and until when. The "active" means that it works. If something is not active, it should not work or not cause any effect. E.g. inactive user should not be able to log in or run any tasks, the non-active role should not be assigned and if assigned it should not be taken into account when computing the accounts.

• iteration

  Flags: RAM

  Multiplicity: [0,1]

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

• iterationToken

  Flags: RAM

  Multiplicity: [0,1]

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

• fullName

  Flags: RAM

  Multiplicity: [0,1]

  Full name of the user with all the decorations, middle name initials, honorific title and any other structure that is usual in the cultural environment that the system operates in. This element is intended to be displayed to a common user of the system.

  Examples:

  • cpt. Jack Sparrow
  • William "Bootstrap" Turner
  • James W. Random, PhD.
  • Vladimir Iljic Lenin
  • Josip Broz Tito
  • Chuck Norris

• givenName

  Flags: RAM

  Multiplicity: [0,1]

  Given name of the user. It is usually the first name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was given to the user at birth or was chosen by the user.

  Examples:

  • Jack
  • Chuck

• familyName

  Flags: RAM

  Multiplicity: [0,1]

  Family name of the user. It is usually the last name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was inherited from the family or was assigned to a user by some other means.

  Examples:

  • Sparrow
  • Norris

• additionalName

  Flags: RAM

  Multiplicity: [0,1]

  Middle name, patronymic, matronymic or any other name of a person. It is usually the middle component of the name, however that may be culture-dependent. Examples: Walker, John, Iljic

• nickName

  Flags: RAM

  Multiplicity: [0,1]

  Familiar or otherwise informal way to address a person. Examples: Bootstrap, Bobby The meaning of this property is to take part in the formatted full name of the person, e.g. William "Bootstrap" Turner. It is not intended to be used as a username or login name. This value is usually changable by the user itself and it defines how the user wants other to address him.

• honorificPrefix

  Flags: RAM

  Multiplicity: [0,1]

  Honorific titles that go before the name. Examples: cpt., Ing., Sir This property is single-valued. If more than one title is applicable, they have to be represented in a single string (concatenated) form in the correct order.

• honorificSuffix

  Flags: RAM

  Multiplicity: [0,1]

  Honorific titles that go after the name. Examples: PhD., KBE This property is single-valued. If more than one title is applicable, they have to be represented in a single string (concatenated) form in the correct order.

• title

  Flags: RAM

  Multiplicity: [0,1]

  User's title defining a work position or a primary role in the organization. Examples: CEO, Security Officer, Assistant

• preferredLanguage

  Flags: RAM

  Multiplicity: [0,1]

  Indicates user's preferred language, usually for the purpose of localizing user interfaces. The format is ISO 639-1 two letter language code and the ISO 3166-1 two letter country code separated by underscore. If not specified then system default locale is assumed. Examples: en_US, sk_SK

• locale

  Flags: RAM

  Multiplicity: [0,1]

  Defines user's preference in displaying currency, dates and other items related to location and culture. The format ISO 639-1 two letter language code and the ISO 3166-1 two letter country code separated by underscore. If not specified then system default locale is assumed. Examples: en_US, sk_SK

• timezone

  Flags: RAM

  Multiplicity: [0,1]

  User's preferred timezone. It is specified in the "tz database" (a.k.a "Olson") format. If not specified then system default timezone is assumed. Examples: Europe/Bratislava

• emailAddress

  Flags: RAM

  Multiplicity: [0,1]

  E-Mail address of the user. This is the address supposed to be used for communication with the user. E.g. IDM system may send notifications to the e-mail address. It is NOT supposed to be full-featured e-mail address data structure e.g. for the purpose of complex address-book application.

• telephoneNumber

  Flags: RAM

  Multiplicity: [0,1]

  Primary telephone number of the user.

• employeeNumber

  Flags: RAM

  Multiplicity: [0,1]

  Unique, business-oriented identifier of the employee. Typically used as correlation identifier and for auditing purposes. Should be immutable, but the specific properties and usage are deployment-specific.

• employeeType

  Flags: RAM

  Multiplicity: [0,-1]

  Employee type specification such as internal employee, external or partner. The specific values are deployment-specific.

• costCenter

  Flags: RAM

  Multiplicity: [0,1]

  The name of the cost center.

• organization

  Flags: RAM

  Multiplicity: [0,-1]

  Name or (preferrably) immutable identifier of organization that the user belongs to. The format is deployment-specific. This property together with organizationalUnit may be used to provide easy-to-use data about organizational membership of the user. This is multi-valued property to allow membership of a user to several organizations. Please note that midPoint does not maintain ordering in multi-value properties therefore this is not usable to model a complex organization hierachies. Use OrgType instead.

• organizationalUnit

  Flags: RAM

  Multiplicity: [0,-1]

  Name or (preferrably) immutable identifier of organizational unit that the user belongs to. The format is deployment-specific. This property together with organization may be used to provide easy-to-use data about organizational membership of the user. This is multi-valued property to allow membership of a user to several organizational units. Please note that midPoint does not maintain ordering in multi-value properties therefore this is not usable to model a complex organization hierachies. Use OrgType instead.

• locality

  Flags: RAM

  Multiplicity: [0,1]

  Primary locality of the user, the place where the user usually works, the country, city or building that he belongs to. The specific meaning and form of this property is deployment-specific.

• jpegPhoto

  Flags: RAM

  Multiplicity: [0,1]

  Photo of the user.

• credentials

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The set of user's credentials (such as passwords).

• result

  Flags: RAM

  Multiplicity: [0,1]