fix: make clients shared across all users while keeping work entries per-user#481
fix: make clients shared across all users while keeping work entries per-user#481devin-ai-integration[bot] wants to merge 1 commit intomainfrom
Conversation
…per-user Remove user_email filtering from client queries (GET, GET by ID, PUT, DELETE) so clients are visible to all authenticated users. Update client validation in work entries and reports routes to check client existence without user_email scoping. Work entries remain scoped to individual users via user_email filtering in all work entry queries and report work entry queries. Updated tests to match new shared client behavior.
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| db.run( | ||
| 'DELETE FROM clients WHERE user_email = ?', | ||
| [req.userEmail], | ||
| 'DELETE FROM clients', | ||
| [], |
There was a problem hiding this comment.
🔴 DELETE /api/clients allows any user to wipe ALL clients and cascade-delete ALL work entries for ALL users
The DELETE / route in backend/src/routes/clients.js:193-194 was changed from DELETE FROM clients WHERE user_email = ? to DELETE FROM clients with no WHERE clause. This means any single authenticated user can delete every client in the entire database. Due to the ON DELETE CASCADE foreign key on work_entries.client_id (backend/src/database/init.js:64), this also destroys all work entries for every user in the system. The frontend exposes this via deleteAllClients() at frontend/src/api/client.ts:84-87. Previously the blast radius was limited to the calling user's own clients; now it's the entire dataset.
Prompt for agents
The DELETE / route on clients.js now runs an unscoped DELETE FROM clients, allowing any authenticated user to wipe all clients and cascade-delete all work entries for all users. This was previously scoped to the authenticated user via WHERE user_email = ?. In a shared-clients model, this bulk-delete endpoint is extremely dangerous because it affects all users' data. Consider one of: (1) removing the bulk-delete endpoint entirely, (2) restricting it to an admin role, or (3) at minimum keeping the user_email scope so a user can only delete clients they created. The cascade behavior defined in backend/src/database/init.js:64 means deleting clients also removes all associated work_entries.
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
Removes
user_emailfiltering from all client queries so that clients are visible and accessible to all authenticated users. Work entries remain scoped to the individual user.Root cause: All client SQL queries (
SELECT,UPDATE,DELETE) includedWHERE user_email = ?, making clients invisible across different user sessions.Changes across 6 files:
clients.js— Removeduser_emailfromWHEREclauses in GET (all/by-id), PUT, DELETE (all/by-id) queriesworkEntries.js— Client validation on POST/PUT now checksWHERE id = ?instead ofWHERE id = ? AND user_email = ?; error message simplified to'Client not found'reports.js— Client lookup queries in client report, CSV export, and PDF export no longer filter byuser_email; work entry queries in reports still filter byuser_emailAll 161 tests pass (8 suites).
Review & Testing Checklist for Human
DELETE /api/clients/is now globally destructive — previously deleted only the authenticated user's clients (WHERE user_email = ?), now runsDELETE FROM clientswith no filter. Any authenticated user can delete all clients for everyone. Confirm this is acceptable or if this endpoint needs a guard/removal.'Client not found or does not belong to user'→'Client not found'in work entry routes. Check if any frontend code matches on the old error string.Notes
user_emailcolumn is retained in theclientstable schema and in theINSERTstatement — it still records who created the client, it's just no longer used for access filtering.INSERTinto clients still writesuser_email(for audit purposes); no schema migration needed.Link to Devin session: https://partner-workshops.devinenterprise.com/sessions/1cb8983a95dc4e448f150b0deada1438