Skip to content
HamstikHamstik Docs

Work Item templates

Work Item templates

Work Item templates are reusable starting points that Project administrators maintain in Project settings → Templates. A template belongs to exactly one Project and one Work Item type, and a template defines the values that a new Work Item starts with. Templates are a convenience, not a live link: creating a Work Item copies the resolved values, so editing or archiving a template never changes Work Items that were already created.

Templates are separate from the CLI’s local file templates. A CLI local file template lives on the machine running the command; a Project template is shared with everyone who can create Work Items in that Project and is also available through Public API v1.

Who can use templates

  • Any Project reader can list and read active templates.
  • Project administrators (and Organization owners/administrators) can create, edit, archive, restore, and set the default template.
  • Any contributor who can create Work Items can select a template.

Read-only members cannot create Work Items, so they cannot apply a template.

What a template can prefill

A template may set only the following creation defaults:

  • Title
  • Description (Markdown)
  • Priority
  • Assignee (an eligible Project member)
  • Labels (existing labels in the Project)
  • Organization Attributes (valid, Project-enabled values)

A template deliberately cannot set status, sprint, parent, rank, history, comments, attachments, votes, time logs, release associations, or identity fields. A new Work Item keeps its normal initial status and any explicit context you supply at creation.

Precedence

When a Work Item is created, values are resolved in this order, highest first:

  1. A value you explicitly supply (including an explicit empty value where the field allows it).
  2. The template you select.
  3. The configured default template, when you do not select one.
  4. Hamstik’s normal application defaults.

Selecting a template completely replaces the default template’s contribution; two templates are never merged invisibly. If you clear a field that a template populated, the Work Item keeps it empty rather than silently restoring the template value.

Default templates

Each Project and Work Item type can have at most one active default template. When you start a new Work Item of that type, Hamstik preselects the default and populates the form with its values before you save. Setting a new default replaces the previous one atomically, even when two administrators act at the same time.

Archiving a template clears its default state in the same operation. Archived templates remain visible to Project managers as evidence but cannot be selected or applied.

Creating a Work Item from a template

  1. Open a Project and select Create Work Item.
  2. Choose a Template. The default template for the selected type is preselected.
  3. Review the populated values. You can change or clear any of them.
  4. If you switch templates after editing, Hamstik asks before it replaces the fields the new template populates.
  5. Select Create Work Item.

Hamstik validates every value again on the server at creation. If a template’s assignee, label, or Attribute value has become invalid (for example, the person left the Project, the label was deleted, or the Attribute option was retired), creation fails with a clear field error rather than silently dropping the value or creating invalid work.

Limits

  • Template name: 1–100 characters, trimmed, case-insensitively unique per Project and Work Item type.
  • Template description: up to 1,000 characters.
  • Default labels: up to 50.
  • Default Organization Attribute assignments: up to 25.

Normal browser creation and single or bulk Public API creation apply Project defaults. Cloning, Bugs generated from Quality results, Slack’s compact creation form, and imports preserve their existing explicit creation data and do not implicitly apply stored templates.

The browser holds the template revision shown in the preview. If an administrator changes that template before you create, creation fails so you can review the new values. Choosing another template or No template asks before replacing edited fields. A failed load keeps creation disabled until defaults can be reviewed; unavailable Attribute defaults must be repaired or the template deselected.