Features · Tickets
Tickets with real structure
Epics, stories, tasks and bugs — with sub-tickets, rollup, history and keys that never collide.
Tickets are the unit of work: epics, stories, tasks and bugs, each with a stable key like PROJ-123. Break anything into sub-tickets and progress rolls up to the parent — done counts and story points both. Labels, watchers, story-point estimates and a full change history are built in, and sensitive tickets can be restricted to the people who actually need to see them.
What you get
- A typed hierarchy of work — epics, stories, tasks and bugs, backed by a per-project type catalogue; a parent link is only accepted when the parent's type sits higher in the hierarchy.
- Progress that rolls up — sub-tickets report done counts and story points to their parent, and an epics view shows completion for every epic in the project.
- Comments with guard-rails — @mentions notify project members, only the author can edit their own comment, and deleting someone else's requires a separate permission from deleting your own.
- Complete change history — every edit is recorded with the actor, the old value and the new — status moves, reassignments, priority, estimates, due dates — and the same rows feed a project activity feed.
- Race-safe ticket keys — sequential PROJ-123 numbers are allocated under a pessimistic database lock, so simultaneous creates never produce a duplicate key.
- Restricted-ticket visibility — mark a ticket restricted and its content is readable only by the reporter, the assignee and admins — everyone else gets a 404, and the ticket drops out of lists and search.
Keys that never collide
Every ticket gets a key like PROJ-123, numbered sequentially per project. The number is allocated while holding a pessimistic lock on the project row, so two people creating tickets in the same instant cannot receive the same key. Uniqueness is enforced in the application layer, which keeps keys reliable even when the database is distributed across nodes.
Restricted without leaking
A restricted ticket's content — title, description, comments, history, worklogs — is visible only to its reporter, its assignee, project admins and global admins. Everyone else receives a 404 rather than a 403, so the ticket's existence is never confirmed by an error code, and restricted tickets are filtered from lists, search results and content-bearing report rows.
A history you can audit
Each field change writes its own history row: who made it, which field, the old value and the new one. Status transitions, reassignments, priority and estimate changes, due dates and comment excerpts all land in one per-ticket timeline, and the same records power a project-wide activity feed.
See Iskue on your own screen
A demo takes half an hour. A pilot runs on your servers, with your data, from day one.