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 (
or just proposed (
must_prompt) in the transition form
must prompt and
mandatory set on a state, applies to all transitions ending on that state.
For example, on a Ticket we have 3 different transitions ending on
assigntransition, you want to prompt the user for a mandatory
agent(default behavior of all transitions before 2.4)
re-assigntransition, you want to force the
agentto be changed, (possible in XML since 2.4 only)
re-opentransition performed on the portal, the
agentfield should not even be displayed (possible in Enhanced Portal since 2.4 only)
agentshould 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)
profilesallowed to run that transition.
Example n°2, how to configure it in the 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>
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.
For each field of the object, iTop combines all flags set on the transition and flags
on the final state (and ignores any other final state flags such as
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.
mandatoryon final state or on transition and initial value is empty: display in edit mode.
read_onlyon the transition: display the field in read-only mode. maybe it is portal specific.
mandatoryflag on transition, on final state or on field definition, then : force field to be documented
caselogduring a transition, require to use the flag
mandatoryon that transition.
Must changedoes not force any entry on caselog
Must Changeforce that field to be changed on the console (no effect on the portal)
Must Promptno effect neither on the console nor on the portal.
Enhanced Portal now support to define specific forms by transition if you need.
<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>
As for any other form defined in the portal, you can set flags on a field to:
<div class="form_field" data-field-id="xxxxx" data-field-flags="hidden"/>
<div class="form_field" data-field-id="xxxxx" data-field-flags="mandatory"/>
<div class="form_field" data-field-id="org_id" data-field-flags="read_only"/>