User Tools

Site Tools

:: Version 2.5.0 ::

2_5_0:feature:lifecycle

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

2_5_0:feature:lifecycle [2018/12/19 11:40] (current)
Line 1: Line 1:
 +====== Lifecycle: Flags on transition ======
 +//New since version 2.4//
 +
 +When an object is going from a source state to a destination state using a transition, ​
 +you can define which fields need to be documented (''​mandatory''​),​ changed (''​must_change''​) ​
 +or just proposed (''​must_prompt''​) in the transition form
 +
 +=== Flags on state ===
 +Flags ''​must_change'',​ ''​must prompt''​ and ''​mandatory''​ set on a state, applies to all transitions ending on that state.
 +
 +<note tip>If you don't want that behavior, remove them from the **state** and set them on the **transitions** where you want them.</​note>​
 +
 +
 +===== Examples =====
 +For example, on a Ticket we have 3 different transitions ending on ''​assigned''​ state:
 +  - during a ''​assign''​ transition, you want to prompt the user for a mandatory ''​agent''​ (//default behavior of all transitions before 2.4//)
 +  - on a ''​re-assign''​ transition, you want to force the ''​agent''​ to be changed, (//possible in XML since 2.4 only//)
 +  - on a ''​re-open''​ transition performed on the portal, the ''​agent''​ field should not even be displayed (//possible in Enhanced Portal since 2.4 only//)
 +  - on an ''​assigned''​ state, ''​agent''​ should be in read-only mode in the Ticket modify form, otherwise a change of agent would not trigger the actions associated with the transition, such as a notification email to the new agent for example)
 +  - A field can now be required during a transition, hidden before and read-only after, thus allowing to limit write on that field only to users with ''​profiles''​ allowed to run that transition. ​
 +
 +<note tip>The 5th example demonstrate a new mean to control who can edit fields within an object. \\
 +Before 2.4, on the console either you can edit all the fields or none for a given object. \\
 +After, on the console you can limit edition of some fields within an object to some profiles only and restrict other fields of the same object to another profile if needed. \\
 +Such segmentation is possible on the Enhanced Portal since 2.3.0.
 +</​note>​
 +
 +
 +===== Configuring =====
 +
 +Example n°2, how to configure it in the XML
 +
 +<code XML>
 +  <class id="​UserRequest">​
 +    <​lifecycle>​
 +      <​states>​
 +        <state id="​assigned">​
 +          <​transitions>​
 +            <​transition id="​ev_reassign">​
 +              <​target>​assigned</​target>​
 +              <​flags>​
 +         <​attribute id="​agent_id">​
 +           <​must_change/>​
 +         </​attribute>​
 +         <​attribute id="​team_id">​
 +           <​must_prompt/>​
 +         </​attribute>​
 +              </​flags>​
 +            </​transition>​
 +</​code>​
 +
 +===== iTop behavior =====
 +
 +Transition forms on the console are automatically built based on flags defined on the Datamodel.
 +On the Portal, automatic form can be overwritten,​ with the exception of empty mandatory field which cannot be removed.
 +
 +=== Flags applicable to a transition ===
 +
 +For each field of the object, iTop combines all flags set on the transition and flags ''​Must_xxx''​ and ''​Mandatory''​ defined ​
 +on the final state (and ignores any other final state flags such as ''​hidden'',​ ''​read_only'',​ ''​read_write''​).
 +
 +=== Transition Form ===
 +
 +Checks flags in this order and stops after first match:
 +
 +  - ''​must_change'':​ display in edit mode, value must be changed and different from previous one.
 +  - ''​must_prompt'':​ display in edit mode.
 +  - ''​mandatory''​ on final state or on transition and initial value is empty: display in edit mode.
 +  - ''​read_only''​ on the transition: display the field in read-only mode. FIXME maybe it is portal specific.
 +  - if none of the above cases: do not display that field in the form.
 +
 +Form Validation:
 +  - ''​mandatory''​ flag on transition, on final state or on field definition, then : force field to be documented
 +  - otherwise, field can be left empty.
 +
 +<note tip>​Forcing an entry to be provided on a ''​caselog''​ during a transition, ​
 +require to use the flag ''​mandatory''​ on that transition. \\ 
 +//''​Must change''​ does not force any entry on caselog//</​note>​
 +
 +
 +=== Modify Form on a state ===
 +
 +  * ''​Must Change''​ force that field to be changed on the console (no effect on the portal)
 +  * ''​Must Prompt''​ no effect neither on the console nor on the portal.
 +
 +===== Portal: overwriting a form =====
 +
 +Enhanced Portal now support to define specific forms by transition if you need.
 +
 +<code XML>
 +  <form id="​ticket-reopen"​ _delta="​define">​
 +    <​class>​UserRequest</​class>​
 +    <​fields/>​
 +    <​twig>​
 +      <div>
 + <div class="​form_field"​ data-field-id="​public_log"​ data-field-flags="​mandatory"/>​
 + <div class="​form_field"​ data-field-id="​team_id"​ data-field-flags="​hidden"></​div>​
 + <div class="​form_field"​ data-field-id="​agent_id"​ data-field-flags="​hidden"></​div>​
 +      </​div>​
 +    </​twig>​
 +    <​modes>​
 +      <mode id="​apply_stimulus">​
 + <​stimuli>​
 +          <​stimulus id="​ev_reopen"/>​
 + </​stimuli>​
 +      </​mode>​
 +    </​modes>​
 +  </​form>​
 +</​code>​
 +
 +As for any other form defined in the portal, you can set flags on a field to:
 +  * Hide a field to the portal user also it is prompted in the console ​
 +<code XML>
 +     <​div class="​form_field"​ data-field-id="​xxxxx"​ data-field-flags="​hidden"/>​
 +</​code>​
 +  * Force the portal user to enter a value in a field also it is not in the console
 +<code XML>
 +     <​div class="​form_field"​ data-field-id="​xxxxx"​ data-field-flags="​mandatory"/>​
 +</​code>​
  
2_5_0/feature/lifecycle.txt · Last modified: 2018/12/19 11:40 (external edit)

";