D2 does not use Documentum standard Lifecycles (dm_policy objects), it comes with a new paradigm so we should be careful to details because it doesn't work as we are used to.
As the D2 interface and functionality is not very customizable, much of our custom logic (actions) can be attached to Lifecycle states. That's why it's important to know and exploit the potential of D2 Lifecycles.
A D2 Lifecycle is defined as any other configuration module, in D2-Config application, configurations being saved in a d2_lifecycle_config object.
After creating a new LC configuration, create the states, specify the first (start) state, select if actions should be executed on start and optionally an alternate attribute holding the current state (by default it's a_status). For each state you have the following configurations:
1. Entry condition: a condition that can be applied on a list of items:
a) VD Children: checks target state of Virtual Document children (if current item is a VD)
b) Checked by Method: you can specify a (custom) method that (can get some arguments) will perform required checks
c) On group: Checks if current user is in the group specified either in free text (as a constant), either saved in a property, or part of a Dictionary.
d) On linked document: checks if the linked document is in the specified state.
e) On property: checks performed on the value of an attribute
f) On rendition: checks existance of a rendition
g) On uniqueness: runs an existing uniqueness check
h) Permission: checks if current user has the specified minimal permission on the object.
For each option you can specify a message that will be displayed as a warning in case of condition is not met (and the object will not enter this state).
2. Actions: are executed when the object enters the current state. Possible action types:
a) on VD children: applies the selected state on VD children
b) Apply autolink, autonaming, parameters, security : applies the corresponding configuration(s) module(s) that is enabled for the active context.
c) Apply method: runs the specified method (standard or custom) with optional arguments
d) Change linked document state: changes the state of the linked documents (you must specify relation type and direction)
e) Change other versions state: changes the state of the other versions of the current object
f) Copy repeating property: copy the values from one repeating property to another (with modes: remove all existing, append, insert before)
g) Make version: creates a new version (version type is selected) of the object
h) Manage distribution: launch or stop the specified distribution configuration
i) Send in Workflow: starts a Workflow with current object as attachment (select workflow configuration, name, notes)
j) Send email: send emails according to the selected mailing list
k) Other types: Mark, Unmark Set property, Set repeating property, Snapshot, Work offline, Remove other versions, Rendition request
NOTE: It's important to add an action 'Set property' for attribute a_status with value equal to current LC state, because D2 does not update it automatically when object enters a new state, but only on the first state (don't ask me why :\)
As you see the range of pre-configured actions is pretty big, but if none of it fits your requirements, you can always create a custom method and call it by using the action type 'Apply method'.
3. Next state: specify which is the next(or previous) state and the following settings:
a) Type of transition: promote, demote, suspend, resume, restart
b) Dialog box: a property sheet configuration, which will appear after you start transition, allowing you to view/update required attributes
c) Action to perform (Checkin, Export file, Insert PDF): action that will be performed when transition occurs
d) Trigger event for transition: the event that will automatically trigger transition to this state
e) Menu label: Label that will be displayed on the transition menu item - this is mandatory, otherwise the menu item will not be displayed
f) Confirmation message: A confirmation message that will appear in a popup forcing the user to confirm the transition
g) Other settings: Electronic signature/Intention required, Intentions dictionary
NOTE: If you won't specify a menu label for state transition, the corresponding (context) menu item will not be displayed and you won't be able to transition to next state.
4. Transition condition: conditions that can be performed on different items (like the entry conditions). If the condition is not met, the specified message is displayed and transition does not occur.
Things to remember:
1. The extended permission 'Change State' on an object does not impact D2 Lifecycle transitions (unlike standard LC where this permission is required), so you must add this constraint manually in LC configuration if required.
2. For each LC state add an action 'Set property' for updating attribute a_status with new status (it's not done automatically)
3. For each next state specify the Menu label (otherwise the menu item for this transition will not appear in the LC menu)
As the D2 interface and functionality is not very customizable, much of our custom logic (actions) can be attached to Lifecycle states. That's why it's important to know and exploit the potential of D2 Lifecycles.
A D2 Lifecycle is defined as any other configuration module, in D2-Config application, configurations being saved in a d2_lifecycle_config object.
After creating a new LC configuration, create the states, specify the first (start) state, select if actions should be executed on start and optionally an alternate attribute holding the current state (by default it's a_status). For each state you have the following configurations:
1. Entry condition: a condition that can be applied on a list of items:
a) VD Children: checks target state of Virtual Document children (if current item is a VD)
b) Checked by Method: you can specify a (custom) method that (can get some arguments) will perform required checks
c) On group: Checks if current user is in the group specified either in free text (as a constant), either saved in a property, or part of a Dictionary.
d) On linked document: checks if the linked document is in the specified state.
e) On property: checks performed on the value of an attribute
f) On rendition: checks existance of a rendition
g) On uniqueness: runs an existing uniqueness check
h) Permission: checks if current user has the specified minimal permission on the object.
For each option you can specify a message that will be displayed as a warning in case of condition is not met (and the object will not enter this state).
2. Actions: are executed when the object enters the current state. Possible action types:
a) on VD children: applies the selected state on VD children
b) Apply autolink, autonaming, parameters, security : applies the corresponding configuration(s) module(s) that is enabled for the active context.
c) Apply method: runs the specified method (standard or custom) with optional arguments
d) Change linked document state: changes the state of the linked documents (you must specify relation type and direction)
e) Change other versions state: changes the state of the other versions of the current object
f) Copy repeating property: copy the values from one repeating property to another (with modes: remove all existing, append, insert before)
g) Make version: creates a new version (version type is selected) of the object
h) Manage distribution: launch or stop the specified distribution configuration
i) Send in Workflow: starts a Workflow with current object as attachment (select workflow configuration, name, notes)
j) Send email: send emails according to the selected mailing list
k) Other types: Mark, Unmark Set property, Set repeating property, Snapshot, Work offline, Remove other versions, Rendition request
NOTE: It's important to add an action 'Set property' for attribute a_status with value equal to current LC state, because D2 does not update it automatically when object enters a new state, but only on the first state (don't ask me why :\)
As you see the range of pre-configured actions is pretty big, but if none of it fits your requirements, you can always create a custom method and call it by using the action type 'Apply method'.
3. Next state: specify which is the next(or previous) state and the following settings:
a) Type of transition: promote, demote, suspend, resume, restart
b) Dialog box: a property sheet configuration, which will appear after you start transition, allowing you to view/update required attributes
c) Action to perform (Checkin, Export file, Insert PDF): action that will be performed when transition occurs
d) Trigger event for transition: the event that will automatically trigger transition to this state
e) Menu label: Label that will be displayed on the transition menu item - this is mandatory, otherwise the menu item will not be displayed
f) Confirmation message: A confirmation message that will appear in a popup forcing the user to confirm the transition
g) Other settings: Electronic signature/Intention required, Intentions dictionary
NOTE: If you won't specify a menu label for state transition, the corresponding (context) menu item will not be displayed and you won't be able to transition to next state.
4. Transition condition: conditions that can be performed on different items (like the entry conditions). If the condition is not met, the specified message is displayed and transition does not occur.
Things to remember:
1. The extended permission 'Change State' on an object does not impact D2 Lifecycle transitions (unlike standard LC where this permission is required), so you must add this constraint manually in LC configuration if required.
2. For each LC state add an action 'Set property' for updating attribute a_status with new status (it's not done automatically)
3. For each next state specify the Menu label (otherwise the menu item for this transition will not appear in the LC menu)
