Sonarly Claude Code
689e914bcc
https://sonarly.com/issue/23635?type=bug The permission validation layer unconditionally skips all permission checks for system objects (`isSystem === true`), allowing any authenticated user regardless of role to create, update, and delete records on system objects. Additionally, the default member role grants `canAccessAllTools: true`, which implicitly enables the VIEWS permission, allowing members to create workspace-level views even when admins intend to restrict their access. Fix: Removed the unconditional permission bypass for system objects (`isSystem === true`) in two locations: 1. **`permissions.utils.ts`** (enforcement layer): Removed the early return that skipped all CRUD and field-level permission validation when the target object was a system object. Now system objects go through the same permission checks as non-system objects. 2. **`workspace-roles-permissions-cache.service.ts`** (permission computation layer): Removed the `isSystem ? true : ...` override in `getPermissionValue()` that force-granted all permissions (read, update, soft-delete, destroy) for system objects regardless of the role's actual configuration. Now system object permissions follow the role's `canReadAllObjectRecords` / `canUpdateAllObjectRecords` flags and any explicit object permission overrides, just like non-system objects. **Why this is safe for internal operations:** System-context operations (background jobs, workspace migrations, cron jobs) already bypass permission checks entirely via `resolveRolePermissionConfig()`, which returns `{ shouldBypassPermissionChecks: true }` for system auth contexts. The `isSystem` bypass was redundant for these operations and only served to create a security hole for user-initiated requests. **Impact on existing members:** The default member role has `canReadAllObjectRecords: true`, `canUpdateAllObjectRecords: true`, `canSoftDeleteAllObjectRecords: true`, and `canDestroyAllObjectRecords: true`. So existing members retain access to system objects by default. The fix allows admins to restrict system object access by configuring role permissions, which was previously impossible. Also cleaned up the unused `isSystem` destructuring and `select` field that are no longer needed.
The #1 Open-Source CRM
🌐 Website · 📚 Documentation · 
Roadmap · 
Discord · 
Figma
Installation
See: 🚀 Self-hosting 🖥️ Local Setup
Why Twenty
We built Twenty for three reasons:
CRMs are too expensive, and users are trapped. Companies use locked-in customer data to hike prices. It shouldn't be that way.
A fresh start is required to build a better experience. We can learn from past mistakes and craft a cohesive experience inspired by new UX patterns from tools like Notion, Airtable or Linear.
We believe in open-source and community. Hundreds of developers are already building Twenty together. Once we have plugin capabilities, a whole ecosystem will grow around it.
What You Can Do With Twenty
Please feel free to flag any specific needs you have by creating an issue.
Below are a few features we have implemented to date:
- Personalize layouts with filters, sort, group by, kanban and table views
- Customize your objects and fields
- Create and manage permissions with custom roles
- Automate workflow with triggers and actions
- Emails, calendar events, files, and more
Personalize layouts with filters, sort, group by, kanban and table views
Customize your objects and fields
Create and manage permissions with custom roles
Automate workflow with triggers and actions
Emails, calendar events, files, and more
Stack
- TypeScript
- Nx
- NestJS, with BullMQ, PostgreSQL, Redis
- React, with Jotai, Linaria and Lingui
Thanks
Thanks to these amazing services that we use and recommend for UI testing (Chromatic), code review (Greptile), catching bugs (Sentry) and translating (Crowdin).
Join the Community
- Star the repo
- Subscribe to releases (watch -> custom -> releases)
- Follow us on Twitter or LinkedIn
- Join our Discord
- Improve translations on Crowdin
- Contributions are, of course, most welcome!