Work Items

Work Item is Hamstik’s umbrella term for the work your team needs to understand, plan, and deliver. The current Work Item types are Task, Bug, Story, Feature, and Epic.

Work Item fields

Work Items can include:

title and Markdown description;
type, status, priority, assignee, due date, and labels;
parent and sub-task relationships;
Project links and dependencies;
Sprint assignment and ordering;
a Private marker that keeps the item out of public sharing;
comments, replies, attachments, an activity log, and watched activity.

New Work Items have Private off by default. The creation form shows this before saving; in a publicly shared Project, leaving it off makes the new item, its non-private comments, and attachments guest-readable immediately. Turn on Private work item while creating sensitive work. You can change the marker later on the Work Item page; the page also offers Copy link for its canonical URL. Guests read complete visible comment threads, with more threads available through the comment-page links when needed.

Organization Attributes

Projects can opt in to active Attribute definitions created by their Organization administrators. Every participating Project uses the same definition and stable choice identities. When the Organization has no active Attribute definitions, the Work Item detail view does not show an Organization Attributes section; once a definition exists, the section appears and a Project that has not enabled any shows that state instead of empty fields. Attributes are optional and support three controls:

Single-select assigns one active choice.
Multi-select assigns a bounded set of unique active choices, displayed in the administrator’s configured order.
Boolean has three states: unset, true, and false. Unset means no value has been recorded; false is an explicit answer.

Enabling an Attribute does not fill it in for existing Work Items. New Work Items also begin unset. Editors can choose Clear to remove one assigned Attribute; leaving an Attribute out of an edit preserves its current value. Changing one Attribute does not replace the other assignments. Unsaved edits remain in the detail editor when you save the description or Release membership. If another user changes the Work Item, saving an older draft reports a revision conflict so you can review the latest values before retrying.

Values remain attached to their Work Items if an Attribute is disabled for a Project or its Organization definition is disabled or retired. A retired choice already in use is shown as retained, but cannot be newly assigned. For a multi-select value, an editor may keep an already-assigned retired choice while changing active choices. Authorized editors can explicitly clear retained values. Re-enabling an Attribute restores its active choices without reviving retired choices.

Attributes are distinct from Labels and native properties. Labels continue to group and filter Work Items. Status, type, priority, assignee, Sprint, and other native properties continue to control their existing behavior; Attributes do not affect transition eligibility or workflow rules.

Work Item keys are stable within a Project, such as WEB-42.

Status and priority

The standard status flow includes backlog, todo, in_progress, in_review, and done. Boards make that flow visible, while the Work Items list provides filters for status, open scope, type, priority, assignee, Sprint, and label.

Priorities are low, medium, high, and urgent.

Browsing and sorting

The Work Items list is the one Project list for browsing, filtering, and planning work. A prominent Unscheduled filter shows every Work Item that is not assigned to a Sprint, regardless of status — that includes unscheduled done items unless you also apply an open or status filter. A Work Item with backlog status that is assigned to a Sprint is scheduled, and a todo or in_progress item without a Sprint is unscheduled; scheduling and status are independent.

Creating a Work Item from the Unscheduled context starts with no Sprint unless you choose one in the dialog. Assigning one or many Work Items to a Sprint from the list removes them from the unscheduled result, and clearing a Sprint assignment makes them unscheduled again.

Choose a sort order for the list:

Sort	Behavior
Recently updated	Default. Most recently updated first, with deterministic key/ID ties.
Priority	`urgent`, `high`, `medium`, `low` (severity order, not alphabetical), then most recently updated with deterministic ties.
Most votes / Fewest votes	Retained unique votes descending / ascending, including zero votes; equal counts use Work Item ID ascending.
Oldest created	Creation time ascending, then a stable ID tie.
Due date	Earliest due date first; undated items last, then deterministic ties.
Stored order	The existing Project/status ordering used by Boards (the stored rank ascending, then creation time and ID). It is read-only: it reflects existing rank data and is not a separate backlog ranking, and browsing it never changes any board’s rank.

Filters, Sprint context, and sorting are stored in the URL, so a reloaded page, a copied link, and the browser’s back button all restore the same view. Changing the sort starts a fresh page. An Archived only preset switches the list to archived Work Items for discovery; default lists, Boards, search, My Work, and guest views continue to exclude them. While an Advanced (SqueakQL) query is active, the basic filters, the Unscheduled preset, the Archived only preset, and sorting are paused; your basic filter and sort state returns when you switch back, and SqueakQL queries are never rewritten.

Filtering lives in a compact toolbar above the results. Status, Type, Priority, Assignee, Sprint, Release Version, and Label each show their current value and open a dropdown; Overdue and Blocked are one-click toggles; and More filters holds criteria that do not fit the available width, including the Archived only preset and the deployed-environment scope when Release environments exist. Everything you have applied appears as a removable chip beneath the toolbar, alongside Clear all. Removing a chip or choosing Clear all refreshes the list immediately and returns to page 1. Clear all removes structured filters and quick-filter toggles but keeps your All/Open/Done/Unscheduled scope, your search text, and your sort order. Search stays separate from the toolbar, and the result count and Sort control appear in the results area above the list. On narrower screens the toolbar keeps Status (and More filters) directly reachable and moves the remaining controls behind More filters rather than overflowing the page.

Older links to a separate Project Backlog page still work: they redirect to the Work Items list with the Unscheduled filter and Stored order selected, preserving compatible search, status, type, priority, and Sprint references. Old searches matched the title and key only; redirected bookmarks keep that behavior, while the Work Items search also matches descriptions. Legacy links that carried invalid filters still show an empty result rather than the full list.

Parent items and sub-tasks

A Work Item can have a parent and any number of sub-tasks, so large work can be broken down without leaving the Work Item it belongs to. The Work Item view shows the parent above the summary and a Sub-tasks panel with each sub-task’s key, title, current status, and assignee — including the assignee’s avatar when one is set. A progress bar and a done/total count summarize how much of the parent’s work is complete. The Work Items list shows the same done/total progress on rows whose direct sub-tasks are in the same Project; the count covers existing sub-tasks regardless of the list’s filters, and rows without sub-tasks show no progress.

Sub-tasks are created in place from the Sub-tasks panel: choose Add sub-task, enter a title, and the new Work Item is created with the current Work Item as its parent. Sub-tasks are ordered and can be opened directly from the panel.

Bulk changes

The Work Items list supports multi-select: click the checkboxes of the items you want, hold Shift and click another item to select the range between them, or use Select all in current filter to select every editable Work Item on the filtered page. Deleted and archived Work Items are never selectable.

With items selected, the bulk changes panel applies one action to all of them:

Status transition to any available status.
Priority, assignee (including unassigning), and Sprint (including clearing Sprint assignment so items become unscheduled).
Labels: add or remove one or more Project labels. Removing a label an item does not have is treated as already applied.

A single bulk request covers at most 50 items — one filtered list page. Each item is applied in its own transaction and reports its own result, so one failing item never blocks the rest; the summary lists every item that failed and why.

Bulk changes are concurrency-aware. The safe default (Skip it and report a conflict) sends the revision shown in the list with every operation and skips any item that changed after the page loaded, reporting it as a conflict — refresh the list and retry those items. This applies to every kind of bulk change, including label-only changes, which are checked against the Work Item’s revision at the moment it is locked for the change. Apply anyway (last write wins) overwrites concurrent edits to the changed fields and asks for confirmation first.

After a bulk change is applied, the list refreshes to reflect the new state. Items that no longer match the current filter drop out of the list and out of the selection; items that are still shown stay selected, and the selected counts update to match. The per-item summary remains visible, and failed items stay listed so you can fix the cause and retry them.

Clone a Work Item

Open a Work Item and choose Clone next to Copy link. Hamstik shows a preview you can edit before creating the clone. Cloning is limited to the same active Project and requires read access to the source and create access to the Project. Archived, deleted, and cross-Project sources are not cloned in this release.

The clone gets a new key and revision, starts in Backlog, and is reported by whoever created it. It has no assignee, Sprint, parent, due date, or Release membership. Copied by default: the title (prefixed Copy of, and editable), the Markdown description, type, priority, labels, story points, and eligible Organization Attribute values. You can explicitly choose an assignee, Sprint, parent, or due date in the form; normal creation validation applies. Template defaults are never layered on top of a clone. Uncheck copied Attributes to leave them unset; unavailable or retired values must be removed before cloning.

Never copied: comments, attachments and inline attachment references (the preview says how many were stripped), audit and activity history, votes, reactions, worklogs, time estimates, child items, Release membership, and archived state. The source Work Item is never modified. The clone keeps the source’s Private marker, so cloning a private item never makes its content guest-visible.

Two optional link controls shape rolling relationships:

Link to original (on by default) preserves a relates link from the clone back to its source.
Copy related links (off by default) copies only relates links whose other end is still available in the same Project. Blocks and blocked by links are never copied, and the preview lists them as skipped. If a selected link becomes invalid before you confirm, the whole clone fails and nothing is created.

The preview records the source revision. If the source changes after you open the preview, confirming asks you to reload the current defaults instead of cloning stale content. Your edits remain visible until you explicitly reload. Retrying the same Public API request with the same Idempotency-Key returns the one clone that was created.

Unscheduled work, Boards, and Sprints

Unscheduled Work Items are the ones without a Sprint assignment; the Unscheduled filter in the Work Items list shows them in one action. A Board is a filter view over the same Project-wide Work Item set. A Sprint adds a time-boxed planning view; its order is separate from the status order used by Boards. The backlog status remains a normal workflow status and is unrelated to Sprint scheduling.

Live updates

Boards, the Work Items list (including Unscheduled), and Work Item detail reconcile changes made by other members without a manual reload. When another member creates, edits, reorders, moves, archives, or deletes a Work Item — or its comments and votes change — your open views re-resolve through the same authorized query that loaded them, so filters, sort order, pagination, and what you are allowed to see are always honored.

Changes are coalesced briefly, so a burst of edits results in one refresh. Your own unsaved edits are never overwritten: while a form is dirty or a board drag is in progress, reconciliation waits and an accessible “changed by another user” notice appears without stealing focus or keyboard position. On save, the existing revision conflict handling applies; after a drop (or a cancel), the view resolves the authoritative order. Saving a Work Item that was deleted or that you can no longer access fails safely and cannot be resaved.

Connection behavior:

The connection uses an authenticated Server-Sent Events stream; event payloads carry routing hints only, never titles or content, and every refresh re-reads your authorized data.
A dropped connection reconnects automatically with a delay that starts at 1 second, doubles, and never exceeds 30 seconds. While reconnecting, changes made within the retention window are replayed and reconciled; a cursor older than the retention window (kept at least 15 minutes) triggers a full reconciliation instead of a partial guess.
If the stream stays unavailable for 60 seconds, the page falls back to an authorized refresh every 30 seconds while the tab is visible; hidden tabs pause that polling, and returning to the tab (or choosing Retry now) reconciles fully.
Your access is re-checked continuously. When membership, role, or Project visibility changes, delivery re-scopes; when access is revoked, the stream ends, protected data leaves the page within 30 seconds on a healthy connection, and the deleted or inaccessible Work Item cannot be resaved.

Discussion and activity

Comments support replies and Markdown. Type @ in the comment composer to mention a teammate using their organization-scoped username, for example @ada-lovelace. The autocomplete is limited to active members who can read the current Project and Work Item; inactive members, people in another Organization, and members without a username do not appear. Administrators are included when they are active and authorized for the target. The server resolves mentions when the comment is saved, so an API or CLI request has the same behavior as the web composer.

Mentions are recognized in ordinary Markdown text. Inline and fenced code, URLs, email addresses, escaped or malformed tokens, and unknown usernames are ignored. Supported mention syntax is only @username: @all, @here, teams, groups, arbitrary email addresses, Work Item description mentions, and external-App mentions are not supported.

Editing a comment notifies only people newly added by that edit. Unchanged mentions are not notified again, removing one does not retract a delivered notification, and adding it again later is a new mention after a real remove/re-add transition. A reply notifies the actual parent-comment author; nested replies use their stored parent. Mention, reply, and watching reasons are combined into one notification, and authors do not receive their own event. A username change does not retarget an existing mention. If a member leaves, or access to the source is revoked, the mention remains a safe historical reference but does not grant access. Removing a source comment removes its body from rendering and notification content while preserving the thread placeholder and a safe unavailable destination.

Deleted comments leave a placeholder so a conversation remains readable. The activity log records important changes such as status, assignment, priority, and Sprint transitions.

Private comments

On a guest-visible Work Item (public sharing), every comment has a Private toggle, defaulted off. A private comment is hidden from guests together with its entire reply subtree — even when a reply is not itself private — while authorized members always see it with a visible private indicator. The comment author and administrators can set or clear the flag during creation or afterwards; the change is audited. The flag never widens access: marking a comment private on a Work Item inside a private Project changes nothing for members and publishes nothing.

CSV imports establish an immutable reporting baseline for each imported Work Item, including its imported creation time, current status, Sprint, estimate, assignee, type, priority, due date, parent, and labels. CSV is a current-state format: it does not invent intermediate transitions that the source did not provide. An item imported initially as Done is therefore resolved at its creation baseline, while cycle time remains unavailable without a recorded cycle-start transition.

Time tracking

Time tracking records optional elapsed effort without changing story-point planning. Estimates are whole minutes: original estimate and remaining estimate. A blank estimate means unknown; an explicit 0 means there is none. Story points keep their separate planning meaning.

Open a Work Item to see the Time tracking panel. It shows the original and remaining estimates, the derived time spent, and a separately labelled descendant rollup. The rollup counts each child’s own worklogs once and never adds an intermediate rollup together with the entries beneath it, so a parent never double-counts its children.

Use Log time to record minutes (1–1,440 per entry), an optional work date, and an optional Markdown comment. The work date is a calendar date you choose, not a timestamp, so it is never shifted by a timezone. Leaving it blank uses today’s date in your configured timezone (UTC if you have not chosen one). Future dates are rejected; backdating is allowed, and overlapping entries are allowed. There is no timer and no billing model.

Logging time never changes the remaining estimate by itself. When you want to update remaining effort at the same time, tick Update remaining estimate with this entry and supply the new value; both are saved together. Editing or deleting an entry does not reverse or invent a remaining-effort change.

You can edit or delete your own worklogs while you still have write access to the Project. Project administrators and Organization owners/administrators can correct someone else’s entry, but they must give a reason, which is shown on the entry. Read-only members can see totals and logs but cannot write. A Work Item marked Done reports zero outstanding work, and if a non-zero remaining estimate is still stored the panel says so rather than hiding it.

Archived items keep their readable logs; adding or editing logs and estimates requires an active, writable Work Item and Project. Removing a Work Item permanently also removes its worklogs. Each entry records the author and the Project, Sprint, and assignee at the time it was written; later moves or reassignments do not rewrite that history, and a removed author’s name is still shown. If a log was recorded in a Project you can no longer access, it is omitted from the list and from every total; the panel never exposes a hidden bucket or a global total you could subtract from.

Effort is included in native .hamstik exports and imports alongside a stable log identity, dates, authors, minutes, and both estimate fields. Re-importing the same source log identity is idempotent, and conflicting content for an already-imported entry is reported instead of silently overwritten. An importer cannot choose another import source’s namespace or probe its identifiers, and an author who cannot be resolved to an authorized member is not impersonated.

Archive and restore

Archiving is a reversible lifecycle action, separate from deletion and from any governance disposal. Use Archive on a Work Item page (or the Public API .../work-items/{workItemKey}/archive) when you want an item out of everyday views while keeping its key, comments, attachments, links, sub-tasks, and history intact. An archived Work Item:

stays readable through its direct link for currently authorized members;
is hidden from default Work Items lists, Boards, search, My Work, and guest (public) views;
rejects normal edits and status transitions until it is restored; and
preserves each child Work Item’s existing archive state — archiving a parent never archives its sub-tasks.

The Work Items list has an explicit Archived only preset for discovery. Archived rows are never selectable for bulk changes.

To archive or restore a Work Item you need effective Project management access (Project Admin, Organization administrator, or owner). A Personal Access Token needs the work_item:delete scope for the Public API. That is the archive ceiling and it matches the documented Public API contract; it does not change the owner-only DELETE (soft deletion) permission.

A Work Item cannot be restored while its Project is archived. Restore the Project first from Project settings → Lifecycle; Hamstik returns 409 PROJECT_ARCHIVED with that guidance instead of silently widening the action. Restoring the Project does not restore individually archived Work Items — restore each one explicitly. Repeated archive or restore requests are idempotent, and a stale page is rejected with a revision conflict so you can refresh before retrying.

Archive, soft deletion, and irreversible disposal

These are three different things:

Action	Reversible?	What happens to the data	Who
Archive	Yes	Hidden from default views; all comments, attachments, links, children, and history kept; normal writes blocked	Effective Project management access (Public API scope `work_item:delete`)
Delete (soft deletion)	Not from the UI	The item is hidden and no longer addressable; the key is never reused. Browser deletion unparents surviving children; API deletion can explicitly cascade	Organization owner only (Public API scope `work_item:delete`)
Disposal / purge	No	Irreversible removal under the Organization’s governance retention and hold policy	Governance administrators; see the audit and retention documentation

Archive is never a purge timer and never permanently removes source data. Existing retention and legal-hold evidence protections continue to apply to archived content, and governance disposal is defined separately.

Watching and notifications

An active Project member can select Watch on a Work Item to receive notifications for new comments and status changes. Selecting Watching removes the manual watch. Reporting an item or creating a comment does not start a watch automatically.

Assigning a Work Item creates an assignee-origin watch unless that assignee has muted watched activity for the item. Unassignment or reassignment removes only the assignment-origin reason; an independent manual watch is preserved. An assignee can mute watched activity without suppressing direct assignment, mention, or reply notifications. The actor is not notified of their own event, and overlapping reasons are combined into one notification.

Only new comments and status changes are watched events. Inactive or removed members, archived or deleted Work Items, and members from another Organization cannot mutate, resolve, or retrieve watcher state.

Voting

Any active Organization member with read access to a Work Item can vote for it, including read-only Project members. A vote is an equal-weight signal of interest: it never changes priority, rank, status, Sprint, severity, or assignment, and it never starts a notification or workflow. There are no downvotes, weighted, anonymous, or on-behalf-of votes, and no voter roster is exposed in this release.

Each person has at most one active vote per Work Item; voting again is idempotent and the count is the number of retained unique votes. Any status, including Done, accepts votes while the item and Project are active. Archived items and Projects keep their existing votes and counts for authorized readers but reject new vote changes, and restoring an item preserves its votes. Losing Organization membership or Project access revokes the authority to vote but retains prior votes in the count; deleting an account removes that person’s active votes. Permanent Work Item deletion removes its vote relationships.

On the Work Item page the Vote button shows the current count and whether you have voted; the selected state is also conveyed by its label and pressed state, and success or failure is announced without moving focus. The consolidated Work Items list offers Show Votes beside Sort. Enable it to show counts and your own voted state, including on Unscheduled and saved-query results. This display choice keeps the current filters and page. Choose Most votes or Fewest votes to sort; equal counts use Work Item ID order. Live vote changes can move items between pages, so exports that require a stable population should use the existing snapshot mechanism. SqueakQL and the Public API expose vote_count with numeric comparisons and sorting. See SqueakQL fields and API resources for the query and API contract.

Reactions

Use Add a reaction on a Work Item or comment to choose Thumbs up, Heart, Laugh, Celebrate, Confused, or Eyes. Each chip shows a text count; a checkmark and pressed state identify your own selections. You can apply several different reactions, once each, and select a chip again to remove your reaction. These signals do not contribute to votes, ranking, priority, notifications, or workflow changes. Hamstik does not expose a list of people who reacted.

Active Organization members with read access can react, including read-only Project members. Archived items and Projects retain readable counts but disable changes. Removed comments hide their reactions. Losing membership or access prevents further operations while retaining past reactions; account deletion removes that person’s relationships. Guests cannot read personalized reaction state or react.

Counts update after the server confirms your action. If a connection fails, the last confirmed state remains visible; check the current state before retrying. Nothing is queued offline. The picker supports keyboard navigation, and the control announces changes without moving focus away from your task.

See Reactions API reference for stable reaction keys and idempotent API operations.

Attachments

Attachment hosting depends on the Organization plan. Existing attachments remain readable, downloadable, and exportable after a downgrade; the plan gate applies to hosting new bytes.

See the API resources guide for the public Work Item projection and Personal Access Tokens for automation access.