Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/0m1n3m/contacts-db/llms.txt

Use this file to discover all available pages before exploring further.

Tasks are the core unit of work in Contacts DB. Each task belongs to an optional project, carries a priority, moves through a defined set of statuses, and can be assigned to one or more team members. Tasks also support threaded comments with @mentions, versioned file attachments, and dependency relationships — giving your team everything they need to track work from creation to completion.

Task statuses

Tasks follow a linear workflow defined by the TaskStatus enum. Each status represents a distinct stage:
StatusValueDescription
CreatedcreatedNewly created and awaiting acceptance by an assignee
AcceptedacceptedAn assignee has accepted responsibility for the task
In Progressin_progressActive development or work is underway
In Reviewin_reviewWork is complete and under review
DonedoneTask is fully completed

Task priorities

The TaskPriority enum defines four priority levels. The default when no priority is specified is normal.
PriorityValue
Criticalcritical
Highhigh
Normalnormal
Lowlow

Creating a task

Only users with the admin or editor role can create tasks. Viewers are blocked with a 403 response.
1

Open the creation form

Navigate to GET /tasks/create. The form loads all active projects in alphabetical order so you can optionally link the task to a project.
2

Fill in the task details

Required:
  • title — a short, descriptive name for the task
Optional:
  • description — rich long-form text
  • project_id — integer ID of an active project; null for standalone tasks
  • priority — one of critical, high, normal, low; defaults to normal
  • due_at — ISO 8601 datetime for the deadline
  • assignee_ids[] — array of user IDs to assign at creation time
3

Submit the form

Submit with POST /tasks. The CreateTaskAction will:
  1. Calculate an initial sort_order for the task’s Kanban column (the next multiple of 10 after the current highest sort order in that column)
  2. Create the task record with status = created
  3. Assign all provided assignee_ids and send them assignment notifications
  4. Write a system comment ("Task created.") to the task’s activity feed
  5. Record a task.created entry in the audit log
On success, you are redirected to GET /tasks/{id}.

Task visibility

Not every user sees every task. The scopeVisibleTo query scope on the Task model enforces per-role filtering:
RoleSees
adminAll tasks in the system, with no restrictions
editorTasks they created, tasks they are assigned to, and tasks where they were @mentioned in a comment
viewerOnly tasks they are assigned to
This scope is applied automatically on the task list (GET /tasks) and on the Kanban board.

Assignments

A task can be assigned to multiple users simultaneously. Assignment data is stored in the task_assignments pivot table, which includes accepted_at, assigned_by, and standard timestamps.
Pass an assignee_ids[] array when creating (POST /tasks) or editing (PATCH /tasks/{id}) a task. Each listed user receives an assignment notification. Any user currently assigned but not present in the new assignee_ids array will be removed from the task.
An assignee can accept the task by sending:
POST /tasks/assignments/{assignment}/accept
Accepting marks the accepted_at timestamp on the assignment record and moves the task status to accepted. A system comment is added to the activity feed.
An assignee can reject the task by sending:
POST /tasks/assignments/{assignment}/reject
Rejection removes the assignment record and notifies the task creator.
An admin can forcibly remove any assignment:
DELETE /tasks/assignments/{assignment}

Comments

The task detail page includes a threaded activity feed of comments and system events. User-authored comments support @mention syntax to notify teammates.
# Add a comment
POST /tasks/{task}/comments

# Delete a comment
DELETE /tasks/{task}/comments/{comment}
@mentions: include @username in the comment body to trigger a mention notification for that user. Mentioned users gain editor-level visibility to the task (they will see it in their task list even if they are not the creator or an assignee).

File attachments

Any user can upload files to a task. Each attachment is stored with versioning support — uploading a new file to an existing attachment slot creates a new version rather than overwriting the previous one.
# Upload a new attachment
POST /tasks/{task}/attachments

# Download an attachment
GET /tasks/{task}/attachments/{attachment}/download

# Delete an attachment
DELETE /tasks/{task}/attachments/{attachment}
Attachment versioning means every upload is preserved. When you retrieve an attachment, you receive the latest version by default, but the full version history is available via the versions relationship on the TaskAttachment model. Deleting an attachment removes all its versions permanently.

Editing and deleting tasks

ActionRoutePermission
Open edit formGET /tasks/{task}/editadmin, or editor who created the task
Save changesPATCH /tasks/{task}admin, or editor who created the task
Delete taskDELETE /tasks/{task}admin, or editor who created the task
Editable fields: title, description, priority, due_at, project_id, and assignee_ids[]. When any field changes, the UpdateTaskAction stamps last_activity_at with the current time, appends a "Task updated." system comment, and writes a task.updated audit log entry capturing the before and after values.
Viewers cannot edit or delete tasks regardless of any other condition. Editors are restricted to tasks they personally created — they cannot edit tasks created by others.

Task dependencies

Tasks can depend on one another. The tasks.dependencies relationship (HasMany TaskDependency via task_id) tracks what the current task depends on, while tasks.subtasks (HasMany TaskDependency via dependent_task_id) tracks tasks that depend on it.
# Add a dependency
POST /tasks/{task}/dependencies

# Remove a dependency
DELETE /tasks/{task}/dependencies/{dependency}
For a visual overview of how tasks move between statuses, see the Kanban Board documentation.

Build docs developers (and LLMs) love