Tasks module

Manages task-related operations.

πŸ“‹ Tasks Module

πŸ”§ Workflow

πŸ“„ GET Request (/project/{project_id}/create-task)

  • Renders the task creation form for a specific project.

  • Ensures the project exists before proceeding:

    project = request.dbsession.query(Project).get(project_id)
    if not project: return HTTPFound(...)

πŸ“ POST Request (/project/{project_id}/create-task)

  • Creates a new task under the specified project.

  • Validates that all fields (name, description, due_date) are provided.

  • Stores the task with status assigned and 0% completion.

  • Logs task creation to ActivityLog.

if not task_name or not task_description or not due_date:
    return { ..., "error_ping": "All fields are required." }

new_task = Task(...)
request.dbsession.add(new_task)

πŸ” GET Request (/task/{id})

  • Displays the task details.

  • Retrieves the task by ID.

  • Also fetches associated microtasks that are active=True.

  • Includes current date in context for UI display.


✏️ POST Request (/task/{id}/edit)

  • Edits task fields: title, description, and due date.

  • Fields must not be empty.

  • Each updated field is individually logged to ActivityLog:


πŸ—‘οΈ POST Request (/task/{id}/delete)

  • Soft-deletes the task by setting task.active = False.

  • Logs task deletion to ActivityLog.

  • Redirects back to the parent project page.


πŸ”’ Security Measures

βœ… Session Enforcement

All routes are protected by @verify_session, ensuring only authenticated users can access or modify tasks.

βœ… Admin-Only Routes

Task creation, editing, and deletion are restricted to users with "admin" permission via:


βœ… Validations

πŸ“Œ Project Existence

Checked before creating or displaying a task:

🧱 Required Fields (Creation/Edit)

Both creation and edit routes require:

  • name

  • description

  • due_date

Empty or missing fields are rejected with an error:

πŸ•’ Date Parsing

Due dates are parsed using:

Improper date formats would raise an exception (caught and handled).

πŸ“– Change Detection (Edit)

Only modified fields are logged for auditing purposes:

πŸ—‚οΈ Soft Delete

Tasks are never permanently deleted:

Prevents accidental loss and supports recovery/audit.


🧠 Design Rationale

  • Auditability: All state changes (create/edit/delete) are logged with details of who performed the action and what changed.

  • Integrity: Strict checks on required fields and relationships (e.g., valid project).

  • Security: Only authenticated, authorized users can manipulate task data.

  • User Experience: Users see relevant error messages and are redirected appropriately on success or failure.

  • All POST requests are protected against CSRF

Last updated