* All tasks are complete. Here's a summary of the implementation:
## Implementation Complete
I've implemented the `!reviewfast` comment trigger feature. Here's what was changed:
### Files Modified
1. **`crates/remote/src/db/reviews.rs`** (lines 253-279)
- Added `has_pending_review_for_pr()` method to check if a review is already in progress for a given PR
2. **`crates/remote/src/routes/github_app.rs`**
- Added import for `ReviewRepository` (line 21)
- Added `TriggerReviewContext` and `PrMetadata` structs (lines 800-816)
- Added `try_trigger_pr_review()` shared helper function (lines 818-928)
- Refactored `handle_pull_request_event` to use the shared helper (lines 930-982)
- Added `handle_issue_comment_event` handler (lines 984-1039)
- Wired up `"issue_comment"` event in `handle_webhook` match (line 657)
3. **`crates/remote/.sqlx/query-7373b3a43a7dd6c5d77c13b5094bb01a63e2902a89dec683659644dd80eb6990.json`**
- Added sqlx query cache for the new `has_pending_review_for_pr` query
### How It Works
When a user comments exactly `!reviewfast` on a PR:
1. The `issue_comment` webhook is received
2. The handler validates:
- It's a new comment (action = "created")
- It's on a PR (not an issue)
- The body is exactly `!reviewfast`
- The commenter is not a bot
3. The shared `try_trigger_pr_review()` function then:
- Checks the installation exists and isn't suspended
- Checks the repository has reviews enabled
- Checks no review is already pending for this PR
- Checks R2 and review worker are configured
- Fetches PR details from GitHub API
- Spawns an async task to process the review
### Deployment Note
The GitHub App must be configured to receive `issue_comment` webhook events in the GitHub App settings.
* Cleanup script changes for task attempt fc1ea8e0-fa6d-435d-b569-a6bbbff3c4d2
* update review comment
* Yes, you need to update your GitHub App to receive `issue_comment` webhook events.
**Steps:**
1. Go to your GitHub App settings: `https://github.com/settings/apps/YOUR-APP-NAME`
2. Navigate to **Permissions & events** → **Subscribe to events**
3. Check the **Issue comments** checkbox
4. Save changes
Without this, GitHub won't send the `issue_comment` webhook when someone comments `!reviewfast` on a PR.
* Fixed. The tip is now always shown when the GitHub App is installed, regardless of whether repositories have finished loading.
* Update copy
* The code compiles successfully. Let me provide a summary of the changes made:
## Summary of Changes
All changes have been implemented successfully. Here's what was modified:
### 1. `crates/remote/src/github_app/service.rs`
- **Removed `--depth 1`** from `git clone` command (line 306-307) to do a full clone instead of shallow
- **Removed `--depth 1`** from `git fetch` command (line 338-340)
- **Added `get_merge_base()` function** (lines 392-415) - calculates the merge-base between HEAD and the base branch
### 2. `crates/remote/src/github_app/pr_review.rs`
- **Changed `base_sha` to `base_ref`** in `PrReviewParams` struct (line 29) - now stores the branch name instead of SHA
- **Added merge-base calculation** after cloning (lines 110-113) - computes the correct base commit for diffing
- **Updated `start_request`** to use the calculated `base_commit` instead of `params.base_sha` (line 162)
### 3. `crates/remote/src/routes/github_app.rs`
- **Extract `base_ref`** from webhook payload (lines 883-886) instead of `base_sha`
- **Updated `PrReviewParams`** construction to use `base_ref` (line 915)
- **Updated debug endpoint** to use `pr_details.base.ref_name` (line 1025)
### 4. `crates/remote/src/github_app/service.rs` (PrRef struct)
- **Added `ref_name` field** to `PrRef` struct (lines 78-80) to support the debug endpoint
The payload.tar.gz will now include the full git history needed for the review worker to compute diffs properly.
* Cleanup script changes for task attempt 3548bc82-973b-4e1b-a95a-37bb692ead71
## Summary
I added URL normalization to the backend in `vibe-kanban/crates/remote/src/routes/review.rs`:
1. **Added `normalize_github_url` helper function** (lines 129-137) - Checks if the URL already has `http://` or `https://` prefix, and if not, prepends `https://`
2. **Applied normalization in `init_review_upload`** (lines 217-218) - The URL is now normalized before being stored in the database
This ensures that all GitHub PR URLs stored in the database will have the correct `https://` protocol prefix, preventing the browser from treating them as relative paths when used in `<a href>` attributes.
* TypeScript compiles without errors. The implementation is complete.
## Summary
I've implemented the in-app repository selection feature. Here's what was created/modified:
### Files Created
1. **`crates/remote/migrations/20251216100000_add_review_enabled_to_repos.sql`** - Database migration adding `review_enabled` column
### Files Modified
**Backend:**
2. **`crates/remote/src/db/github_app.rs`**
- Added `review_enabled: bool` to `GitHubAppRepository` struct
- Updated `get_repositories()` to include the new field
- Modified `sync_repositories()` to preserve `review_enabled` for existing repos
- Added `update_repository_review_enabled()` method
- Added `is_repository_review_enabled()` method for webhook filtering
3. **`crates/remote/src/routes/github_app.rs`**
- Added `review_enabled` to `RepositoryDetails` response
- Added `UpdateRepoReviewEnabledRequest` type
- Added PATCH route for toggling repo review status
- Modified `get_status` to fetch repos from GitHub API when `repository_selection == "all"`
- Modified webhook handler to check `review_enabled` before triggering reviews
**Frontend:**
4. **`remote-frontend/src/api.ts`**
- Added `review_enabled: boolean` to `GitHubAppRepository` type
- Added `updateRepositoryReviewEnabled()` API function
5. **`remote-frontend/src/pages/OrganizationPage.tsx`**
- Added `repoToggleLoading` state
- Added `handleToggleRepoReview()` handler
- Replaced read-only repo list with toggle switches UI
### How It Works
- Users can now toggle individual repos on/off directly in the Organization settings
- When toggled off, PRs from that repo won't trigger reviews (webhook filters them out)
- The setting persists even when GitHub syncs the repo list
- For installations with "all repos" access, the backend fetches the full repo list from GitHub API
* The Rust code now compiles successfully. The implementation is complete and verified.
* Cleanup script changes for task attempt 06f1bda0-0f58-4e8b-87e0-a45eea28487c
* Done. The fix has been applied - now `get_status` will always fetch repos from GitHub API when the GitHub App service is configured, regardless of the `repository_selection` mode.
Try refreshing the organization page now - you should see the list of repositories with toggle switches.
* The frontend builds successfully. All the implementation is complete:
**Summary of changes:**
1. **Backend (`crates/remote/src/routes/github_app.rs`):**
- Reverted `get_status` to only return cached data (fast)
- Added `GET /organizations/{org_id}/github-app/repositories` - fetches repos from GitHub API and syncs to DB
- Added `PATCH /organizations/{org_id}/github-app/repositories/review-enabled` - bulk enable/disable all repos
2. **Database (`crates/remote/src/db/github_app.rs`):**
- Added `set_all_repositories_review_enabled()` method for bulk updates
3. **Frontend API (`remote-frontend/src/api.ts`):**
- Added `fetchGitHubAppRepositories()` function
- Added `bulkUpdateRepositoryReviewEnabled()` function
4. **Frontend UI (`remote-frontend/src/pages/OrganizationPage.tsx`):**
- Loads repos asynchronously after initial page load via `fetchGitHubAppRepositories`
- Shows loading spinner while repos are fetching
- Search bar to filter repositories by name
- "Enable All" / "Disable All" bulk action buttons
- Toggle switches per repository (existing functionality)
- Displays count of enabled repos (e.g., "5 of 10 repositories have reviews enabled")
* Cleanup script changes for task attempt 06f1bda0-0f58-4e8b-87e0-a45eea28487c
* Fixed. The route ordering was the issue. In Axum, literal path segments must come before wildcard segments. I swapped the order so:
1. `/repositories` (GET)
2. `/repositories/review-enabled` (PATCH - literal `review-enabled`)
3. `/repositories/{repo_id}/review-enabled` (PATCH - wildcard `{repo_id}`)
The server should now correctly route `GET /v1/organizations/{org_id}/github-app/repositories` to the `fetch_repositories` handler.
* Done. The `list_installation_repos` function now handles pagination - it loops through pages (100 repos per page) until it gets fewer than 100 results, accumulating all repositories. This will now fetch all repos for organizations with more than 100 repositories.
* Done. The repository list is now sorted with:
1. Enabled repos first (`review_enabled = true`)
2. Then alphabetically by repo name within each group
* Done. The repository list now:
- Sorts alphabetically by name (stable ordering - no jumping when toggling)
- Has a filter dropdown with options: "All", "Enabled", "Disabled"
* Done. All three git commands now have security protections:
**Changes made to `crates/remote/src/github_app/service.rs`:**
1. **Clone** (line 284): Added `-c core.hooksPath=/dev/null`, `-c core.autocrlf=false`, `-c core.symlinks=false` flags plus environment variables
2. **Fetch** (line 318): Added `-c core.hooksPath=/dev/null` flag plus environment variables
3. **Checkout** (line 349): Added `-c core.hooksPath=/dev/null` flag plus environment variables
**Security protections now in place:**
- `core.hooksPath=/dev/null` - Disables all git hooks
- `core.symlinks=false` - Prevents symlink attacks (on clone)
- `core.autocrlf=false` - Prevents line ending manipulation (on clone)
- `GIT_CONFIG_GLOBAL=/dev/null` - Ignores global git config
- `GIT_CONFIG_SYSTEM=/dev/null` - Ignores system git config
- `GIT_TERMINAL_PROMPT=0` - Prevents credential prompts
The repository cloning is now safe for untrusted repositories.
* Cleanup script changes for task attempt 8324c5ea-8505-49a7-a9f3-dfeb2d83cf54
* All changes are complete. Let me provide a summary of what was implemented:
## Summary
I've implemented the Cloudflare R2 binary storage feature. Here are the changes:
### Files Created
- **`npx-cli/bin/download.js`** - New module that handles downloading binaries from R2 with:
- SHA-256 checksum verification
- Progress reporting
- Redirect handling
- Local caching in `~/.vibe-kanban/bin/{version}/{platform}/`
### Files Modified
1. **`npx-cli/bin/cli.js`**
- Converted to async for on-demand downloads
- Downloads binaries from R2 instead of using bundled files
- Non-blocking update check shows notice if newer version available
- Caches binaries locally per version/platform
2. **`npx-cli/package.json`**
- Removed `"dist"` from `files` array (package now ~15KB instead of ~150MB)
3. **`.github/workflows/pre-release.yml`**
- Added new `upload-to-r2` job that:
- Downloads all platform packages from artifacts
- Generates manifest.json with SHA-256 checksums for each binary
- Uploads binaries to R2 at `binaries/v{version}/{platform}/{binary}.zip`
- Updates global manifest with latest version
- Modified `create-prerelease` job to:
- Depend on `upload-to-r2` instead of `package-npx-cli`
- Inject R2 public URL into download.js via `sed`
- No longer download/bundle binaries in the npm package
### Required GitHub Secrets
You'll need to add these secrets to your repository:
- `R2_BINARIES_ACCESS_KEY_ID`
- `R2_BINARIES_SECRET_ACCESS_KEY`
- `R2_BINARIES_ENDPOINT` (e.g., `https://<account_id>.r2.cloudflarestorage.com`)
- `R2_BINARIES_BUCKET`
- `R2_BINARIES_PUBLIC_URL` (the public URL for your R2 bucket, e.g., custom domain or public R2 URL)
### R2 Bucket Structure
```
binaries/
manifest.json # {"latest": "0.0.135"}
v0.0.135/
manifest.json # Per-version manifest with checksums
linux-x64/
vibe-kanban.zip
vibe-kanban-mcp.zip
vibe-kanban-review.zip
...
```
* Done! I've updated the implementation to use full tags (with timestamps) instead of just version numbers. Here's a summary of what changed:
## Changes Made
1. **`npx-cli/bin/download.js`**:
- Added `BINARY_TAG` constant (placeholder `__BINARY_TAG__`)
- Changed `ensureBinary()` to use `BINARY_TAG` instead of accepting version as parameter
- Cache paths now use the tag: `~/.vibe-kanban/bin/{tag}/{platform}/`
2. **`npx-cli/bin/cli.js`**:
- Updated to import `BINARY_TAG` from download.js
- Cache directory now uses `BINARY_TAG` instead of `CLI_VERSION`
- Updated `ensureBinary()` call to not pass version
3. **`.github/workflows/pre-release.yml`**:
- `upload-to-r2` job now uses `new_tag` instead of `new_version` for R2 paths
- Binaries are stored at `binaries/{tag}/{platform}/{binary}.zip`
- Global manifest stores the full tag: `{"latest": "v0.0.135-20251215122030"}`
- `create-prerelease` job now injects both `__R2_PUBLIC_URL__` and `__BINARY_TAG__`
This allows multiple pre-releases to coexist in R2 (e.g., `v0.0.135-20251215122030` and `v0.0.135-20251215100000`), making rollbacks easy.
* chore: bump version to 0.0.136
---------
Co-authored-by: GitHub Action <action@github.com>
* Use a larger ubuntu runner
* chore: bump version to 0.0.136
---------
Co-authored-by: Solomon <abcpro11051@disroot.org>
Co-authored-by: GitHub Action <action@github.com>
* Done! Here's a summary of the changes:
1. **`scripts/prepare-db.js`** - Added `--check` flag support that runs `cargo sqlx prepare --check` instead of `cargo sqlx prepare`
2. **`package.json`** - Added new script:
```json
"prepare-db:check": "node scripts/prepare-db.js --check"
```
3. **`.github/workflows/test.yml`** - Added `npm run prepare-db:check` to the Checks step
The check will verify that the `.sqlx/` cached query metadata is up-to-date with the actual SQL queries in the codebase. If a developer modifies a SQL query but forgets to run `npm run prepare-db`, the CI will fail.
* Fix image queries
* Done! Added check mode support to the remote script:
1. **`crates/remote/scripts/prepare-db.sh`** - Added `--check` flag support that runs `cargo sqlx prepare --check` when passed
2. **`package.json`** - Added:
```json
"remote:prepare-db:check": "cd crates/remote && bash scripts/prepare-db.sh --check"
```
Note: I didn't add `remote:prepare-db:check` to CI since it requires PostgreSQL (`initdb`, `pg_ctl`) which may not be available on the CI runner. The local SQLite-based `prepare-db:check` is already in CI. Let me know if you'd like to add the remote check to CI as well (would require installing PostgreSQL in the workflow).
* Add remote db check to workflow
* Added a step to install `sqlx-cli` with both SQLite and PostgreSQL features. The Rust cache should help speed up subsequent runs since it caches installed crates.
* Done! All three files updated to use Rust `1.89.0`:
1. `rust-toolchain.toml` - `channel = "1.89.0"`
2. `.github/workflows/test.yml` - `toolchain: 1.89.0`
3. `.github/workflows/pre-release.yml` - `RUST_TOOLCHAIN: 1.89.0`
This should fix the `zerocopy` AVX512 compile error since 1.89.0 has `stdarch_x86_avx512` stabilized.
* Done. Added a step to install PostgreSQL before the Checks step so `npm run remote:prepare-db:check` can run.
* Updated to install `postgresql-16` and add `/usr/lib/postgresql/16/bin` to PATH so `initdb`, `pg_ctl`, and `createdb` are available.
* Added the official PostgreSQL apt repository so we can install PostgreSQL 16.
* Much cleaner. Using the `ikalnytskyi/action-setup-postgres@v7` action which handles the PostgreSQL 16 installation and PATH setup automatically.
* Done. Changes made:
1. **`crates/remote/scripts/prepare-db.sh`**: Now checks if `DATABASE_URL` is set. If so, uses the existing PostgreSQL server. Otherwise creates a temp cluster as before.
2. **`.github/workflows/test.yml`**:
- Added `database: remote` to the PostgreSQL action to create the database
- Added `DATABASE_URL: postgres://postgres@localhost:5432/remote` env var to the Checks step
* Done. Changes made:
1. **`.github/workflows/test.yml`**: Removed PostgreSQL setup step and `DATABASE_URL` env var
2. **`crates/remote/scripts/prepare-db.sh`**: Simplified - for `--check` mode, exits early with `SQLX_OFFLINE=true cargo sqlx prepare --check` (no database needed)
```
M crates/remote/scripts/prepare-db.sh
```
The changes in `crates/remote/scripts/prepare-db.sh` are pre-existing in this worktree, not something I introduced. My only change was to `crates/remote/src/db/organizations.rs`.
Should I revert that file to clean up the branch, or is that a separate change you were working on?
* Disable OAuth account deduplication by email
We intend to add explicit OAuth account linking in the future to replace this issue.
* remove unused function find_user_by_email
* WIP - Migrate task sharing to ElectricSQL + Tanstack DB
* WIP auth proxy
* Simplify electric host
* Electric token
Only set in cloud. Acts like a DB password.
* Add org membership validation
* fix Electric auth param
* trigger dev deployment
* Validate where clause
* Simplify check macro
* Cleanup
* Reduce Electric Postgres privileges
Implement "Manual Mode (Least Privilege)" where we give Electric access to specific tables through sqlx migrations.
https://electric-sql.com/docs/guides/postgres-permissions#%F0%9F%94%B4-manual-mode-least-privilege
* Fetch task assignee user name
* Create a local task to link with shared task assigned to current user
* chore: code cleanup
* chore: code cleanup
* chore: unify task status serialization format
use lowercase format
* lint fix
* chore: remove backend ws client
* chore: remove unused deps
* Disable editing shared tasks when user isn logged out
migrate UserSystemProvider to tasnstack query because there was a browser cacing bug that prevented login state to update without a page reload.
* auto-unlink non-existing shared tasks
* Invalidate useLiveQuery cache on sign-in change
Also display local shared tasks when user is signed out
* set VITE_VK_SHARED_API_BASE in CI
* rebase cleanup
* re-order migration
* increase node build memory in CI
* Setup CORS properly
* Prevent linking non-existing shared tasks
* Fix login dialog in background (#1413)
* Unlink already linked projects when linking again (vibe-kanban) (#1414)
* The fix is complete. Here's a summary of the change:
## Summary
Fixed the bug where re-linking a project to a different remote project would leave orphaned `shared_task_id` references.
**File modified:** `crates/server/src/routes/projects.rs:167-208`
**Change:** The `apply_remote_project_link` function now:
1. Fetches the existing project to check if it's already linked
2. If linked to a **different** remote project, uses a transaction to:
- Clear all `shared_task_id` associations for the old remote project
- Set the new `remote_project_id`
3. If no existing link, sets the new link directly
4. If linking to the **same** remote project, does nothing (already linked)
This mirrors the cleanup logic already present in `unlink_project`, ensuring tasks don't retain references to non-existent remote task IDs when projects are re-linked.
* You're right, let me think more carefully about the transaction.
Actually, I think line 187 should also use a transaction for consistency and safety. Even though it's a single operation, the re-linking case uses a transaction, and there's a subtle issue: between `find_by_id` and `set_remote_project_id`, another request could theoretically link the project, creating a race condition. Using a transaction would provide row-level locking.
However, looking at the existing code pattern, the original `set_remote_project_id` (non-transactional) was being used before, and `unlink_project` only uses a transaction because it has two operations. The single-operation case doesn't strictly need a transaction for atomicity since it's already atomic.
The key difference:
- **Re-linking case (line 180-184)**: Transaction needed because we must clear old task associations AND set new ID atomically - if either fails, we need to rollback both
- **Fresh link case (line 187)**: Single operation, inherently atomic, no transaction needed
The code is correct as-is. Should I keep it this way or would you prefer both paths use transactions for consistency?
* Done. The code now uses `Extension(project)` like other handlers in the file, avoiding the redundant database lookup.
* Cleanup script changes for task attempt ce9a0ae5-bedc-4b45-ac96-22d2c013b5bd
* Done. Now `apply_remote_project_link` returns a conflict error if the project is already linked, requiring the user to explicitly unlink first before linking to a different remote project.
* Both pass. Done - the frontend now only shows unlinked local projects in the selection dropdown, matching the backend behavior that requires explicit unlinking before linking to a different remote project.
* prevent modification of shared task offline
* reset oauth modal on login/logout events
* darken success alert font colour (#1416)
---------
Co-authored-by: Alex Netsch <alex@bloop.ai>
Co-authored-by: Louis Knight-Webb <louis@bloop.ai>
Co-authored-by: Gabriel Gordon-Hall <gabriel@bloop.ai>
OAuth tokens are revoked when the user revoke access to the OAuth app from the provider settings.
Some OAuth providers also revoke OAuth tokens when the user changes password.
