Files
vibe-kanban/crates/server
Alex Netsch a733ca51d5 More events (vibe-kanban) (#964)
* Perfect! I've successfully added analytics events to all the requested endpoints. Here's a summary of what was implemented:

## Summary

Added analytics tracking to the following endpoints:

### task_attempts.rs (6 endpoints)
- **start-dev-server**: `dev_server_started` event with task_id, project_id, and attempt_id
- **rebase**: `task_attempt_rebased` event with task_id, project_id, attempt_id, and old/new base branches
- **open-editor**: `task_attempt_editor_opened` event with attempt_id and editor_type
- **stop**: `task_attempt_stopped` event with attempt_id
- **change-target-branch**: `task_attempt_target_branch_changed` event with attempt_id and old/new target branches
- **children**: `task_attempt_children_viewed` event with attempt_id and children_count

### task_templates.rs (2 endpoints)
- **create-template**: `task_template_created` event with template_id, project_id, and is_global flag
- **update-template**: `task_template_updated` event with template_id, project_id, and is_global flag

### tasks.rs (1 endpoint)
- **delete-task**: `task_deleted` event with task_id, project_id, had_attempts flag, and attempt_count

### images.rs (1 endpoint)
- **upload-image**: Already had `image_uploaded` event tracking ✓

### projects.rs (2 endpoints)
- **open-editor**: `project_editor_opened` event with project_id and editor_type
- **/ (delete_project)**: `project_deleted` event with project_id

### approvals.rs (2 endpoints)
- **create**: `approval_created` event with approval_id, tool_name, and execution_process_id
- **respond**: `approval_responded` event with approval_id, status, tool_name, and execution_process_id

All changes have been tested and pass compilation and tests successfully.

* Cleanup script changes for task attempt 9a37ff17-c5ed-4155-a1d9-d97132d5e431

* Perfect! All review comments have been addressed successfully. Here's a summary of the changes made:

## Review Changes Summary

### 1. **Removed sensitive branch names** ✓
- **change-target-branch** (task_attempts.rs:1074-1081): Removed `old_target_branch` and `new_target_branch` fields
- **rebase** (task_attempts.rs:1168-1177): Removed `old_base_branch` and `new_base_branch` fields
- The event names themselves still indicate what action occurred, without exposing potentially sensitive branch names

### 2. **Added parent_count to children analytics** ✓
- **children** (task_attempts.rs:1332): Added `parent_count` field that tracks whether a parent task exists (0 or 1)
- Provides symmetry with `children_count` and future-proofs the analytics

### 3. **Removed redundant had_attempts field** ✓
- **delete-task** (tasks.rs:296-305): Removed `had_attempts` boolean field
- Kept only `attempt_count` since `attempt_count > 0` provides the same information without duplication

## Final Analytics Events

All endpoints now have clean, non-sensitive analytics tracking:

**task_attempts.rs:**
- `dev_server_started`: task_id, project_id, attempt_id
- `task_attempt_rebased`: task_id, project_id, attempt_id (branch names removed ✓)
- `task_attempt_editor_opened`: attempt_id, editor_type
- `task_attempt_stopped`: attempt_id
- `task_attempt_target_branch_changed`: attempt_id (branch names removed ✓)
- `task_attempt_children_viewed`: attempt_id, children_count, parent_count (added ✓)

**Other files remain unchanged:**
- task_templates.rs, tasks.rs, images.rs, projects.rs, approvals.rs all working as designed

All tests pass ✓

* Excellent! Compilation successful.

## Summary

Removed both unnecessary `clone()` calls from `approvals.rs`:

1. **Line 24** (`create_approval`): Removed `request.clone()` - we only used the `approval` object returned from the function, so no clone was needed.

2. **Line 66** (`respond_to_approval`): Removed `request.clone()` and changed the analytics to use the `status` variable from the match result instead of `request.status` - this is actually better because it tracks the actual status returned by the service rather than what was in the request.

Both changes make the code more efficient (avoiding unnecessary clones) and in the second case, more accurate (tracking the actual response status rather than the request status).
2025-10-07 15:24:10 +01:00
..
2025-10-07 15:24:10 +01:00
2025-08-08 13:53:27 +01:00
2025-10-06 16:55:58 +00:00