Package Custom Types

In the section Understanding Custom Types and Properties the basic concepts of managing custom types and properties are described. In this section we focus on how to apply those concepts in the context of packages.

Packages may be of different types, such as Major Feature, Integration Feature, ... When a new package is created, a new instance of a particular package type (for example, Major Feature 123 of type Major Feature) is created. When creating a new package type version (using the create command) you can define the following properties as specified in the packages.xsd schema:

Name

The name of the Package type. It may contain alphanumeric characters, blanks, ., -, _, @, $, #. The name is mandatory.
Base Type

Deployment: may only reference one application, but adds deployment specific functionality such as dynamic properties
Workflow

Workflow defining a state machine.
Properties

The properties of the Package.
DynamicProperties

The dynamic properties of a Deployment Package.

See: Working with Custom Types

State machine for Workflow

Name

The name of the state. It may contain alphanumeric characters, blanks, ., -, _, @, $, #. The name is mandatory. It is referenced out of transitions.

StartWorkflow

Inside element OnEnter. Starts a workflow with a given name (defined via attribute workflowName) when the package reaches this state. Can optionally be limited to start the workflow only if the package was previously in another state (defined via attribute previousState). All StartWorkflow elements of one state are evaluated and executed independently of each other.

Following properties are provided in addition to all custom and dynamic properties on the package:

Package name
Package ID
Package type
Package state
Previous package state
Package owner
Application name
Application ID
Application type
Predecessor name
Predecessor ID
Related package IDs (ordered by ID)
Dependent package IDs (ordered by ID)
Assigned Component IDs (ordered by ID)
Assigned Component Names (ordered by ID)
Application* and component* is set for deployment packages. Non-deployment packages always provide an empty value for those properties.
System properties are always supplied. If one is empty, an empty string or empty array is supplied.

Example:

<processFlowModification objectName="ADVANCEREDMINETICKET">
  <variables>
    <variable name="@global/user" value="MYUSER"/>
    <variable name="@global/userDepartment" value="MYDEPARTMENT"/>
    <variable name="@global/client" value="99"/>
    <variable isEncrypted="true" name="@global/token" value="encrypted Token"/>
    <variable name="/custom/My_Property" value=""/>
    <variable name="/custom/My_Property_2" value=""/>
    <variable name="/redmine/id" value="3711"/>
    <variable name="/system/name" value="Bug #3711"/>
    <variable name="/system/type" value="Bug"/>
    <variable name="/system/state" value="RELEASE TEST"/>
    <variable name="/system/previous-state" value="FUNCTION TEST"/>
    <variable name="/system/id" value="1163"/>
    <variable name="/system/owner" value="Dev"/>
    <variable name="/system/application" value="ARA"/>
    <variable name="/system/application-id" value="957"/>
    <variable name="/system/application-type" value="Generic"/>
    <variable name="/system/predecessor" value="Dev"/>
    <variable name="/system/predecessor-id" value="1150"/>
    <variable name="/system/related-packages" type="Array">
      <value>2544</value>
      <value>7391</value>
    </variable>
    <variable name="/system/dependent-packages" type="Array">
      <value>5042</value>
    </variable>
    <variable name="/system/component-ids" type="Array">
      <value>970</value>
      <value>978</value>
    </variable>
    <variable name="/system/component-names" type="Array">
      <value>WebApp</value>
      <value>Database</value>
    </variable>
  </variables>
</processFlowModification>

Mandatory: No

SetOwner

Inside element OnEnter. Sets the owner of the package (defined via attribute newOwner) when it reaches this state.

Mandatory: No
A list of transitions

Each transition is defined by the related <Transition> tag. The text content of this tag references a target state. The workflow must contain a definition of this target state, otherwise the create command fails with an error message when parsing the type definition. Transition names (names of target states) must be unique within a state.

Mandatory: No
A package milestone

A milestone is defined by the related <Milestone> tag. This tag includes the milestone name and its position in the time order of all milestones on the package (Package Milestones impose a time order on workflows). Package milestone names and positions must be unique within a workflow. Only one milestone is allowed per workflow state.

Mandatory: No
Description

The description of the state.

Mandatory: No

Behavior

Properties

Creating a new version of a package type: If you create a new package type version based on an existing type version, a clone of the old version is created. You can therefore change any properties without affecting the older version. New package instances based on the new type reflect the properties/property groups of the new type version.
Modifying an existing version of a package type: Changes to properties of the package type will immediately affect ALL current instances of that package type version. For example, if you delete a property, you will irreversible delete the data of all packages (of that type version) which was entered for that property.

Workflows

Each package type has its own workflow defining the life-cycle of packages of that type (see Working with Deployment Packages). A state machine consists of states and transitions between the states. A workflow has an initial state, defining the start-up state, when a new instance of a package is created. A state can also be indicated as closing state; this means that the package is closed and will typically not change anymore.

Filters

A state may also define a filter for custom properties/property groups of a package type. This means, that depending on the current state of a package, some custom properties/property groups may be shown to the users, others not. Also, some properties may be set to read-only or read-write in dependence of the state.

Filters are defined through the set of property groups and properties, which are assigned to a package custom type, see Property Groups and Properties.

Versioning of Workflows

Creating the first version of a package type: the type is initialized with a new workflow
Creating a new version of a package type where previous versions exist: When a new version of a package type is created, the complete workflow is copied into the new version in a lazy way. "Lazy" means, that the workflow is not cloned automatically but only if you change something (for example, add/delete transitions). All new instances of the package type reflect the new version of the workflow. It is not possible to remove states or milestones from workflows when updating them.

Additive changes: You can carry out any additive changes on the workflows (add new states/transitions/milestones)
Renames: It is possible to rename states, transitions, and milestones
Subtractive changes: Concerning any subtractive changes, you are only allowed to delete transitions in the workflows, which implicates, that the appropriate sidebar showing the available transitions of the affected package instances to the user is reduced accordingly. Deleting a state or a milestone is not allowed.