Service Records - The "Dependencies" Field

The "Dependencies" field is a way to identify what other work must be done (all, or in part) before a work request can be completed. Dependencies are usually ST serial numbers, although there are a few other forms of reference that can be used. They're typically only needed for large projects.

Preceding the dependency list display is one line for each dependency, as well as for each dependency of those, displaying the entire dependency tree. Nothing is displayed for items that don't exist.

Lines are of the form:

<serial number>   <status>   <indent>   <subject>  
<serial number>
is a link to the corresponding item;
is the item completion status, shown as empty if the item isn't completed;
is indentation depicting the distance from the starting item; and thus is indented from the previous line if it's a dependency of the previous item;
is the subject of the item.

When a subtree is found that has already been displayed, the children of the tree aren't displayed. Instead, the subject of the top of each duplicated tree has one of the following appended:

[0 children]
[1 child skipped]
[number_skipped children skipped]

Only the first iteration of a loop is displayed.

A simple example might be of the form:

NNNNN1   a starting point
NNNNN2   done     needed for NNNNN1
NNNNN3   done         needed for NNNNN2
and a slightly more complicated example would be:
NNNNN1   a starting point
NNNNN2   done     needed for NNNNN1
NNNNN3   done     needed for NNNNN1
NNNNN4   done         needed for NNNNN3

See also the "See Also" field, which is a less restrictive, more general version of this, and the "Other IDs" field, which can be used to refer to dependent work not identified within this system.

Creating Dependencies

In the item update page, which displays all of the data associated with a service record, there is a button, to the right of the Dependencies input box, labeled "Create". Selecting it reveals a text area, in which one can place the subjects, one per line, of records to create as dependencies of the item being displayed. The items are created when the page "Update" button is selected.

In addition to direct descendants, dependencies of dependencies can be created at the same time by indenting the subject lines to reflect the desired relationships. E.g. the subjects

step 1
step 1A
step 1B
step 2
would create items for "step 1" and "step 2" as dependencies of the displayed item, and would create items for "step 1A" and "step 2A" as dependencies of the "step 1" item.

The new records inherit multiple fields from the record being displayed, with the exception noted:

account number
date due
owner - defaults to whoever is creating the dependencies
type of work (queue_id)
signing authority
activity (sponsors)
subscription code
These are just defaults. They may be overridden by specifying explicit values as described below. Once the dependencies have been created it is expected that appropriate changes will be made.

Specifying More Than Subjects

To facilitate cloning a large set of dependencies, with changes, there is a syntax for specifying additional fields, i.e. more than just the subject. In general, additional field specifications may be provided after each subject, in the form:

'| ' <field_name>: <field_value> '\n'
('| ' <field_value> '\n')*
The extra <field_value>s are for fields that have multi-line values; currently that's only the "summary" field. The indentation of the additional <field_value>s is exactly 2 spaces. The '|'s can be arbitrarily indented.

For example, this:

Ho Ho Ho
| summary: This is lots of fun,
|  however there is a cost.
| responsible: Santa

  | cost_estimate: $100K $10K/year

  | cost_estimate: $1K $14K/year

  | cost_estimate: 2555 hours

  | cost_estimate: 24 hours
would specify the "responsible" and "summary" field for the first created dependency, and the cost estimate to use for each of its dependencies.

When specifying this field in a customized sort or display, use the name "dependencies".