LifecycleStateType (Complex Type)

Items

• $itemDefinition.Name.LocalPart

  Flags: RAM,runtime

  Multiplicity: [1,1]

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

• $itemDefinition.Name.LocalPart

  Flags: RAM,runtime

  Multiplicity: [0,1]

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

• $itemDefinition.Name.LocalPart

  Flags: RAM,runtime

  Multiplicity: [0,1]

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

• $itemDefinition.Name.LocalPart

  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 shoule be left undefined.

• $itemDefinition.Name.LocalPart

  Flags: RAM,runtime

  Multiplicity: [0,1]

  There are cases when you need to force midpoint thinks that user has assigned some role. The assignemnt actually doesn't exist but there is a need to preted 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 proces. Instead, we want to pretend he has "temporary" role assigned which allows him to perform post-authentication.

• $itemDefinition.Name.LocalPart

  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 shoule be left undefined.

• $itemDefinition.Name.LocalPart

  Flags: RAM,runtime

  Multiplicity: [0,-1]

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

• $itemDefinition.Name.LocalPart

  Flags: RAM,runtime

  Multiplicity: [0,-1]

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

• $itemDefinition.Name.LocalPart

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Transition to another state.