Projects

A Project is the durable home for a body of work inside an Organization. It includes Work Items, Boards, Sprints, labels, discussion, activity, and optional Applications.

Project keys

Every Project has a unique key, such as WEB. Hamstik uses that key to prefix Work Item keys (WEB-1, WEB-2, and so on). Hamstik can suggest a key from the Project name, but it does not overwrite a key you have already typed.

Project views

• Overview gives the Project’s current shape, recent activity, delivery summary, and discussion.
• Work Items is the complete filterable list for the Project, with multi-select bulk changes and a one-action Unscheduled filter for Work Items that are not assigned to a Sprint.
• Boards show selected Work Items across status columns.
• Sprints provide time-boxed planning and delivery.

The Unscheduled filter and a Board are views over the Project’s Work Items. Moving a Work Item between views does not create a second copy.

Labels and discussion

Project labels help teams group and filter Work Items. Comments and replies can be attached to Projects as well as Work Items, so context stays close to the work.

Organization Attributes

Organization administrators define Attributes once and choose which Projects use each definition in Project settings. This opt-in shares the same Attribute identity and choices across Projects; it does not create a Project-specific copy or allow the Project to change its type, choices, or meaning. A Project that has not opted in cannot assign that Attribute to its Work Items.

Attributes are optional metadata for Work Items. They support single-select, multi-select, and true/false values. Existing Work Items remain unset when a Project enables an Attribute, and new Work Items also start unset. In the Project settings list, users with Project-management authority can enable or disable active Organization definitions. Other Project members can view the configuration.

Disabling an Attribute for a Project, or disabling its Organization definition, keeps values already assigned to Work Items. Those values remain visible with their inactive or retired state and can be explicitly cleared by an authorized editor. Re-enabling a definition makes its active choices available again; it does not make retired choices assignable.

Attributes are separate from Project labels and native Work Item properties such as status, type, priority, and assignee. Labels remain available for grouping and filtering, while Attributes add optional, Organization-governed classification without changing Work Item workflow rules.

Pins and thumbnails

Use Pin from a Project overview to keep that Project at the top of your Organization’s All projects list. Pins belong to your account, so each teammate can keep a different set of Projects. Multiple pinned Projects are ordered alphabetically by name.

Project administrators can upload a PNG, JPEG, or WebP thumbnail from Project settings. The thumbnail appears on the Organization dashboard, the All projects cards, and the Project overview. Thumbnail images are private to Organization members. Hamstik keeps the uploaded original and serves an optimized 96-pixel WebP derivative to the interface, so pages do not download the full-size file.

Self-hosted deployments store thumbnails in the local project image directory by default. Operators can set S3_PROJECT_IMAGE_BUCKET and optionally S3_PROJECT_IMAGE_PREFIX to use S3 instead. When the project image bucket is blank, LOCAL_PROJECT_IMAGE_STORAGE_DIR is used. The directory must be writable and durable. PROJECT_IMAGE_MAX_UPLOAD_BYTES controls the upload cap and defaults to 5 MiB.

Project access and roles

Within an Organization, each Project controls who can reach it and what they can do there. Access is decided in two layers:

1. Organization role — owners and administrators always hold Project Admin on every Project of their Organization.

2. Project access — for everyone else, a Project combines an explicit per-person role (Project settings → Access) with the Project’s default access for organization members:

   • Contributor — members can view the Project and work in it (the default; matches how Projects behaved before explicit roles existed).
   • Read-only — members can view everything but cannot change anything.
   • No access — members cannot see the Project at all unless someone explicitly adds them.

An explicit membership always wins over the default policy. The predefined roles are:

Role	Can do
Project Admin	Everything in the Project: settings, membership, default access policy, boards, sprints, labels, and releases
Contributor	Read everything, and create and edit Work Items, comments, and attachments
Read-only	Read everything, change nothing

Project roles never grant anything beyond their Project: Organization administration, billing, other Projects, and public sharing remain Organization-level authorities. A Project Admin cannot publish their own Project for anonymous sharing; that stays with Organization owners and administrators.

Projects you cannot access behave exactly like Projects that do not exist: they are hidden from lists, search, dashboards, reports, and the Public API.

Project lifecycle

Projects can be archived and later restored by Organization administrators and owners. Project Admins alone cannot archive a Project; the Public API requires the project:write scope and Organization administrator/owner authority, and the browser shows the action only to those roles. Archiving is a reversible lifecycle action, not deletion and not a purge timer:

• The Project immediately leaves default All projects lists, dashboards, search, reports tied to active scope, and public (guest) discovery.
• Normal child writes, including edits, comments, attachments, and new Work Items and Sprints, are blocked with PROJECT_ARCHIVED until it is restored.
• Every Work Item, comment, attachment, link, Sprint, and history entry is kept, and the Project stays readable through direct links so it can be reviewed.
• Each Work Item keeps its own archive state. Archiving a Project does not archive its Work Items, and restoring the Project does not unarchive the individually archived ones.

Use the Active / Archived switch on the Projects page to discover archived Projects, and the Lifecycle card in Project settings to archive or restore. See Work Items for the item-level rules and the difference between archive, soft deletion, and irreversible disposal.

Public sharing (read-only links)

Projects can be published for anonymous, read-only viewing. Guest access requires all three of the following, checked on every request:

1. the Organization allows public Projects (Organization settings → General → Allow public Projects);
2. the Project is public (Project settings → Public sharing); and
3. the Work Item is not marked Private.

When a Project is public, anyone with the URL can read its overview and list of guest-visible Work Items, plus each visible Work Item’s description, non-private comments, and attachments — without signing in. Signed-in people outside the Organization get the same read-only view. The regular Hamstik URLs (/t/<organization>/projects/<key> and the Work Item detail pages) serve this view; Project settings and each Work Item page offer a Copy link action. There are no separate share links to rotate. Making the Project private again, disabling the Organization switch, marking a Work Item private, or marking a comment private revokes the corresponding guest reads immediately.

Enabling a Project’s public toggle shows a confirmation with the exact counts of Work Items, comments, and attachments that would become readable, so administrators can mark sensitive items or comments private first. Every change to these controls is audited.

Comments on guest-visible Work Items default to public. Marking an individual comment Private hides it from guests together with its entire reply subtree, even if a reply is not itself marked private. Removed comments stay visible as placeholders on public threads; deleted or archived Work Items are never guest-visible.

Guests can never comment, watch, vote, upload, edit, transition, or change settings, and guest pages are excluded from search indexing by default.

See Work Items, Boards, and Sprints for the day-to-day workflow. A Project can also own canonical Release Versions. Project Admins, Organization administrators, and Organization owners can manage them through the Public API.