工单状态

版本2.4以来的新功能
当对象使用转换从源状态变为目标状态时,您可以在转换表单中定义需要记录(强制),更改(must_change)或仅建议(must_prompt)的字段。

状态标记

必须在状态上提示和强制设置的标记must_change适用于在该状态下终止的所有转换。

如果您不希望这种行为,请将其从状态中删除,并将其设置在所需的过渡上。

例子

例如,在工单上,我们有3个不同的转换以指定的状态结束:

  1. 在分派转换期间,您要提示用户输入强制处理人员(2.4之前所有转换的默认行为)
  2. 在重新分派转换上,您想强制更改处理人员,(仅在XML中,从2.4开始)
  3. 在门户上重新打开的转换上,甚至不应显示处理人员字段(在增强门户中可能,因为仅2.4)
  4. 在指定状态下,处理人员应该在工单修改表单的状态下处于只读模式,否则处理人员的变更不会将处理人员与操作活动关联的触发器,例如将通知发送邮件更改为新的处理人员)
  5. 现在可以在转换期间需要字段,在此之前隐藏并且在之后只读,因此只允许对该字段的写操作限制为允许简档(角色)运行该转换的用户。

第5个示例向控制演示了一种新方法,可以编辑对象中的字段。
在2.4之前,您可以在控制台上编辑给定对象的所有字段,也可以不编辑任何字段。
之后,在控制台上,您可以将对象中某些字段的版本限制为仅某些简档(角色),并且如果需要,可以将同一对象中的其他字段限制为另一个对象。
从2.3.0版本开始,这样的细分在增强门户上是可能的。

配置中

示例n°2,如何在XML中进行配置

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>

iTop行为

控制台上的转换表单是根据数据模型上定义的标志自动构建的。在门户上,可以将自动表单覆盖,但必须删除的必填字段为空。

适用于转换的标志

对于对象的每个字段,iTop将转换上设置的所有标志与在最终状态上定义的标志Must_xxx和Mandatory组合在一起(并忽略任何其他最终状态标志,例如hidden,read_only,read_write)。

转换表单

按以下顺序检查标志,并在第一次比赛后停止:

  1. must_change:在编辑模式下显示,必须更改价值并且与以前的版本不同。
  2. must_prompt:在编辑模式下显示。
  3. 在最终状态或转换上是必需的,而初始价值是空的:在编辑模式下显示。
  4. 转换上的read_only:以只读模式显示该字段。FIXME也​​许是门户特定的。
  5. 如果没有以上情况:不在表单中显示该字段。

表单验证:

  1. 转换上的强制性标志,最终状态或字段定义,然后:强制字段要记录在案
  2. 否则,该字段可以留空。

强制在转换期间在案例日志中提供条目,需要使用该转换上必需的标志。
变更必须不强制在caselog上进行任何输入

在状态上修改表单

  • 必须变更强制在控制台上更改该字段(对门户无效)
  • 必须不对控制台或门户造成任何影响。

门户:覆盖表单

增强门户现在支持根据需要通过转换定义特定形式。

  <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>

对于门户中定义的任何其他表单,可以在字段上将标志设置为:

  • 即使在控制台中提示该字段,也将字段隐藏到门户用户
  • <div class="form_field" data-field-id="xxxxx" data-field-flags="hidden"/>
  • 强制门户用户在字段中输入价值,即使在控制台中该字段不是必需的
  • <div class="form_field" data-field-id="xxxxx" data-field-flags="mandatory"/>

原贴链接:https://www.itophub.io/wiki/page?id=2_7_0%3Afeature%3Alifecycle


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.

If you don't want that behavior, remove them from the state and set them on the transitions where you want them.

Examples

For example, on a Ticket we have 3 different transitions ending on assigned state:

  1. during a assign transition, you want to prompt the user for a mandatory agent (default behavior of all transitions before 2.4)

  2. on a re-assign transition, you want to force the agent to be changed, (possible in XML since 2.4 only)

  3. 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)

  4. 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)

  5. 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 profilesallowed to run that transition.

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.

Configuring

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>

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:

  1. must_change: display in edit mode, value must be changed and different from previous one.

  2. must_prompt: display in edit mode.

  3. mandatory on final state or on transition and initial value is empty: display in edit mode.

  4. read_only on the transition: display the field in read-only mode. FIXME maybe it is portal specific.

  5. if none of the above cases: do not display that field in the form.

Form Validation:

  1. mandatory flag on transition, on final state or on field definition, then : force field to be documented

  2. otherwise, field can be left empty.

Forcing an entry to be provided on a caselog during a transition, require to use the flagmandatory on that transition.
Must change does not force any entry on caselog

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.

  <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:

  • Hide a field to the portal user even if the field is prompted in the console

     <div class="form_field" data-field-id="xxxxx" data-field-flags="hidden"/>
  • Force the portal user to enter a value in a field even if the field is not mandatory in the console

     <div class="form_field" data-field-id="xxxxx" data-field-flags="mandatory"/
标签:
由 superadmin 在 2020/08/25, 16:13 创建
    

需要帮助?

如果您需要有关XWiki的帮助,可以联系:

深圳市艾拓先锋企业管理咨询有限公司