# LifecycleStateType (Complex Type)

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

Specification of lifecycle state. EXPERIMENTAL

Item Summary
Name | Type | Multiplicity | Description
--- | --- | --- | ---
name | property string | [1,1] | Identifier of the state.
description | property string | [0,1] | Free-form description of the state (e.
documentation | property string | [0,1] | Technical documentation for a particular object or construct.
displayName | property string | [0,1] | User-friendly name of the state, e.
forcedActivationStatus | property ActivationStatusType | [0,1] | Activation status forced by this lifecycle state.
forcedAssignment | container VirtualAssignmentSpecificationType | [0,1] | There are cases when you need to force midpoint thinks that user has assigned some role.
activeAssignments | property boolean | [0,1] | Setting that specifies whether object assignments should be considered active in this lifecycle state.
entryAction | container LifecycleStateActionType | [0,-1] | State entry action.
exitAction | container LifecycleStateActionType | [0,-1] | State exit action.
transition | container LifecycleStateTransitionType | [0,-1] | Transition to another state.

- ### Items

  - #### name

    Flags: RAM,runtime

    Multiplicity: [1,1]

    Identifier of the state. This is the value that is used in the lifecycleState property.

  - #### description

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Free-form description of the state (e.g. purpose, mechanisms, etc.) Used for documentation purposes (comment).

  - #### documentation

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Technical documentation for a particular object or construct.

    The purpose of this element is to document system configuration and behavior. The documentation will not be presented to end users. In fact, it will probably not be presented at all in midPoint user interface. This documentation element is supposed to be a part of the technical documentation of midPoint deployment. The tools than generate deployment configuration will look for these elements and combine them to compiled documentation document.

    AsciiDoc formatting is assumed for this element. Any leading or trailing whitespace is skipped. Indentation equivalent to he indentation of the first non-blank line of text is also skipped.

  - #### displayName

    Flags: RAM,runtime

    Multiplicity: [0,1]

    User-friendly name of the state, e.g. for displaying in the user interface.

  - #### forcedActivationStatus

    Flags: RAM,runtime,AVals:3

    Multiplicity: [0,1]

    Activation status forced by this lifecycle state. If lifecycle state implies activation status, then such status will be forced to all objects that are in that lifecycle state. Such objects will have the effective status set to the value of forcedActivationStatus regardless of other activation setting. I.e. administrativeStatus and validity are not considered in this case.

    If no forced status is specified for a state that is explicitly defined, the "undefined" is implied. In that case the usual activation computation takes place (e.g. administrativeStatus and validity).

    However, there is a couple of hardcoded lifecycle states. If these states are not explicitly defined in a lifecycle model, the hardcoded defaults are applied for activation in these hardcoded states ("undefined" for active and deprecated states, "archived" for archived state, "disabled" for all other states). To turn off this default behaviour those hardcoded lifecycle states need to be explicitly defined in the state model and the forcedActivationStatus property should be left undefined.

  - #### forcedAssignment

    Flags: RAM,runtime

    Multiplicity: [0,1]

    There are cases when you need to force midpoint thinks that user has assigned some role. The assignment actually doesn't exist but there is a need to pretend as it does. This can be used e.g. for post-authentication flow. The user has assigned all business, application, etc. roles but we don't want to consider these roles during his post-authentication process. Instead, we want to pretend he has "temporary" role assigned which allows him to perform post-authentication.

  - #### activeAssignments

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Setting that specifies whether object assignments should be considered active in this lifecycle state. If set to true, then assignments are considered active. That means that the assignments will be computed as usual. If set to false then all object assignments are considered inactive. Which means that they will be ignored (as if they do not exist at all).

    If this setting is not specified then the result of forced activation status determines behavior of the assignments. If forced activation is "disabled" or "archived" then the assignments are considered to be inactive. If forced activation status is "enabled" or if it is not defined at all then the assignments are considered active.

    However, there is a couple of hardcoded lifecycle states. If these states are not explicitly defined in a lifecycle model, the hardcoded defaults are applied for activation in these hardcoded states ("undefined" for active and deprecated states, "disabled" for all other states). To turn off this default behaviour those hardcoded lifecycle states need to be explicitly defined in the state model and the forcedActivationStatus property should be left undefined.

  - #### entryAction

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    State entry action. Action that is executed when the state is entered.

  - #### exitAction

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    State exit action. Action that is executed when the state is exited.

  - #### transition

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    Transition to another state.