Table & Resource Views
Relevant source files
The following files were used as context for generating this wiki page:
The Table & Resource Views system serves as the primary interface for managing and interacting with data entities (referred to as "tables") within the MuteTaxes CRM. This system integrates directly with the OpenFGA-based authorization layer to ensure that UI elements—such as sidebar navigation and action buttons—dynamically adjust based on the current user's relationship-based permissions.
The core purpose of this module is to provide a visualization of how roles and permissions translate into actual user experience, allowing super admins to register new resources and normal users to interact with them according to assigned CRUD (Create, Read, Update, Delete) badges.
Sources: PLAN.md:4-10, frontend/src/pages/TablePage.tsx:103-106
Architecture and Resource Management
The system manages "Table" entities which act as a resource registry in the PostgreSQL database. Each table is defined by a unique slug and a display name. These tables are registered as objects within OpenFGA to facilitate granular access control.
Table Registry and Creation
The registry is managed via the TablesPage component and the /tables API routes. Only users with Super Admin privileges can create new tables. When a table is created, the system automatically grants the creator badge to the superadmin role for that specific resource in OpenFGA.
Sources: backend/src/modules/tables/tables.routes.ts:16-25, frontend/src/pages/TablesPage.tsx:32-44
The diagram shows the flow of registering a new resource and the automatic assignment of initial administrative permissions.
Authorization-Driven UI Logic
The system uses two primary methods to derive the UI state from the authorization model:
1. Resource Filtering (Sidebar)
The application calls the /me/allowed-tables endpoint to determine which resources the user is permitted to see. The backend iterates through all tables in the database and performs an OpenFGA check for the can_read relation.
Sources: backend/src/modules/me/me.routes.ts:11-23, frontend/src/context/AppContext.tsx:29-41
2. Action Authorization (Table View)
When a user navigates to a specific table (e.g., /table/clients), the TablePage component fetches the specific CRUD permissions for that resource. This allows the UI to enable or disable buttons like "Create", "Update", and "Delete" based on live checks.
Sources: frontend/src/pages/TablePage.tsx:28-40, backend/src/modules/me/me.routes.ts:25-56
Permission Mapping Table
The following table describes how UI actions map to OpenFGA relations:
| UI Action | OpenFGA Relation | Backend Check Function | File Reference |
|---|---|---|---|
| View in Sidebar | can_read | checkPermission(id, slug, "read") | backend/src/modules/me/me.routes.ts:16 |
| Create Button | can_create | checkPermission(id, slug, "create") | backend/src/modules/me/me.routes.ts:40 |
| Update Button | can_update | checkPermission(id, slug, "update") | backend/src/modules/me/me.routes.ts:42 |
| Delete Button | can_delete | checkPermission(id, slug, "delete") | backend/src/modules/me/me.routes.ts:43 |
Data Flow: Permissions to Component State
The following sequence diagram illustrates how permissions are resolved when a user opens a resource page.
Resolution of resource-specific permissions involving backend route handling and parallel OpenFGA checks.
Demo Implementation (Clients Table)
While the system is designed to be generic for any registered table, the clients table contains a "wired" demo implementation to show functional CRUD actions.
- List Records: Fetches mock data via
/demo/clients. - Handle Actions: The
handleActionfunction inTablePage.tsxtriggers specific endpoints (Create/Update/Delete) and displays success or failure messages based on the actual backend response (which returns a 403 if FGA checks fail).
Sources: frontend/src/pages/TablePage.tsx:49-75, frontend/src/api/endpoints.ts:133-149
Data Models
Table Entity (Prisma)
The table resource is defined in the database schema as follows:
| Field | Type | Constraints | Description |
|---|---|---|---|
id | TEXT | PRIMARY KEY | Unique UUID. |
slug | TEXT | UNIQUE | URL-friendly identifier (e.g., "invoices"). |
displayName | TEXT | - | Human-readable name (e.g., "Invoices"). |
createdAt | TIMESTAMP | DEFAULT now() | Record creation timestamp. |
Sources: backend/prisma/migrations/20260122120201_init/migration.sql:35-42
API Response Structure
The TablePermissionsResponse interface defines the payload used to sync UI state with authorization:
export type TablePermissionsResponse = {
table: string;
canCreate: boolean;
canRead: boolean;
canUpdate: boolean;
canDelete: boolean;
};
Sources: frontend/src/api/endpoints.ts:51-57
Conclusion
The Table & Resource Views module provides a dynamic, permissions-aware interface that serves as the visual confirmation of the relationship-based access control (ReBAC) model. By decoupling resource registration from hardcoded logic and relying on live OpenFGA checks, the system ensures that access changes in the Permission Matrix are reflected immediately across the frontend sidebar and resource interaction pages.