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.

Tags and task dependencies give your team two powerful ways to add structure to work. Tags let you apply reusable, color-coded labels across any task regardless of project, making it easy to filter and group related work at a glance. Task dependencies let you model real-world sequencing constraints — ensuring a task cannot be considered ready until everything it relies on has been completed first.

​
Tags

​
What tags are

A tag is a short, globally-scoped label with an optional hex color. Tags are not tied to any single project; once created they can be attached to any task in the system. The default color for a new tag is #3B82F6 (blue) when no color is supplied.

​
Tag data model

ColumnTypeNotes
idbigintAuto-incrementing primary key
namestring (unique)Max 50 characters; must be unique across all tags
colorstringHex color string, e.g. #3B82F6; defaults to #3B82F6
created_attimestamp—
updated_attimestamp—
The pivot table task_tag links tasks to tags via task_id and tag_id with a unique constraint on the pair to prevent duplicate attachments.

​
Managing tags

Only users with the admin or editor role may create or update tags. Only admin users may delete a tag.

Blade (form-based)

  • Create: POST /tags
  • Update: PATCH /tags/{tag}
  • Delete: DELETE /tags/{tag}

JSON API

  • List all: GET /api/tags
  • Create: POST /api/tags
  • Update: PATCH /api/tags/{tag}
  • Delete: DELETE /api/tags/{tag}
Validation rules for create / update: 
{
  "name": "required|string|max:50",
  "color": "nullable|string|regex:/^#[0-9A-F]{6}$/i"
}
The CreateTagAction will throw a ValidationException if a tag with the same name already exists. Likewise, UpdateTagAction prevents renaming a tag to a name that belongs to another tag.

​
Attaching tags to tasks

Any authenticated user who can edit a task (i.e. an admin, or an editor who created the task) may attach and detach tags. Viewers cannot modify tag assignments. AddTagToTaskAction is idempotent — attaching a tag that is already present on a task is a no-op.

Blade routes

  • Attach: POST /tasks/{task}/tags
  • Detach: DELETE /tasks/{task}/tags/{tag}

API routes

  • List task tags: GET /api/tasks/{task}/tags
  • Attach: POST /api/tasks/{task}/tags/{tag}
  • Detach: DELETE /api/tasks/{task}/tags/{tag}
When using the Blade attach route, send tag_id as a form field. When using the API attach route the tag is identified directly in the URL — no request body is needed. 
# Attach tag 3 to task 15
POST /api/tasks/15/tags/3

# Detach tag 3 from task 15
DELETE /api/tasks/15/tags/3

# List all tags on task 15
GET /api/tasks/15/tags

​
Task Dependencies

​
What dependencies are

A task dependency is a directed relationship between two tasks. It records that one task (the prerequisite) must be completed before the other task (the dependent) should proceed. The relationship also carries a type that describes the nature of the link.

​
Dependency data model

ColumnTypeNotes
idbigintAuto-incrementing primary key
task_idforeignId → tasksThe task that owns this dependency record (the prerequisite task)
dependent_task_idforeignId → tasksThe task that depends on task_id
typeenumOne of depends_on, blocks, relates_to; defaults to depends_on
created_attimestamp—
updated_attimestamp—
A unique constraint on (task_id, dependent_task_id, type) prevents duplicate dependency records.

​
Task model relationships

Access dependencies directly from any Task instance: 
// Tasks that THIS task depends on (prerequisites)
$task->dependencies();   // HasMany of TaskDependency keyed by task_id

// Tasks that depend on THIS task (downstream tasks)
$task->subtasks();       // HasMany of TaskDependency keyed by dependent_task_id
The getDependencies API endpoint returns both collections together: 
{
  "dependencies": [ ... ],
  "subtasks": [ ... ]
}

​
Managing dependencies

Only users who can edit the task (admin, or the editor who created it) may add or remove dependencies. Viewer-role users receive a 403 response.

Blade routes

  • Add: POST /tasks/{task}/dependencies
  • Remove: DELETE /tasks/{task}/dependencies/{dependency}

API routes

  • List: GET /api/tasks/{task}/dependencies
  • Add: POST /api/tasks/{task}/dependencies
  • Remove: DELETE /api/tasks/{task}/dependencies/{dependency}
Request body for adding a dependency: 
{
  "dependent_task_id": 42,
  "type": "depends_on"
}
type is optional and defaults to depends_on. Accepted values are depends_on, blocks, and relates_to. Example API calls: 
# Add a dependency: task 10 depends on task 5
POST /api/tasks/10/dependencies
Content-Type: application/json

{ "dependent_task_id": 5, "type": "depends_on" }

# Remove dependency record 7 from task 10
DELETE /api/tasks/10/dependencies/7

# List all dependencies and subtasks for task 10
GET /api/tasks/10/dependencies
Circular dependency protection is enforced automatically by CreateTaskDependencyAction. Before persisting a new dependency, the action checks for a direct reverse link (e.g. task B already depends on task A) and for one level of indirect cycles through the dependent task’s existing dependencies. If a cycle is detected, a RuntimeException is thrown and a 422 response is returned to the caller. A task also cannot depend on itself.

​
Dependency validation rules

CreateTaskDependencyAction enforces three guards before creating a record:
  1. Self-dependency: a task cannot depend on itself.
  2. Duplicate dependency: the same (task_id, dependent_task_id, type) combination cannot be created twice.
  3. Circular dependency: the action checks for a reverse dependency and for indirect cycles through existing dependencies.
If any guard fails, a RuntimeException is thrown with a descriptive message. TaskDependencyController catches this exception and returns a 422 Unprocessable Entity JSON response (or redirects with errors for Blade requests).

Build docs developers (and LLMs) love

Get started for freeTalk to us