@jmruthers/pace-core 0.5.191 → 0.5.193

package/docs/migration/database-changes-december-2025.md

@@ -260,9 +260,10 @@ The following RPC functions have been updated to use the new table names:
 - `app_cake_unit_create` - Now queries `core_events`
 - `app_base_application_create` - Now queries `core_person` and `core_events`
 - `app_pace_contact_update` - Now queries `core_contact`, `core_person`, `core_member`, `core_phone`
-- `set_super_admin_override` - Now queries `core_organisations`
 - `get_organisation_members` - Now uses `core_organisation_memberships` view
 
+**Note**: `set_super_admin_override` function has been **removed** (as of migration `20251208133718_remove_super_admin_override_mechanism.sql`). Super admin access is now determined solely by the `is_super_admin()` function in RLS policies. If you were using this function, remove those calls as they are no longer needed or available.
+
 **Note**: RPC function signatures have not changed - only internal table references. Your RPC calls should continue to work, but ensure you're using the correct table names in any direct queries.
 
 ### TypeScript Type Updates

package/docs/rbac/event-based-apps.md

@@ -29,7 +29,9 @@ A simple event management app that demonstrates:
 4. **ALWAYS set up providers correctly** in the exact order shown below
 5. **Use the exact app name** from your environment variable (must match database exactly, case-sensitive)
 6. **Ensure database setup is complete** before starting the app - App must be registered with `requires_event = true`
-7. **User must have organisation role** - Users need roles assigned in `rbac_organisation_roles` table
+7. **User must have organisation role OR event access** - Users need either:
+   - Explicit roles in `rbac_organisation_roles` table, OR
+   - Event access via `rbac_event_app_roles` (organisation access is automatically inferred)
 8. **Event must be selected** - `selectedEventId` must be set in UnifiedAuth context before permission checks
 9. **Event must belong to organisation** - The event's `organisation_id` must match the user's organisation
 
@@ -200,6 +202,8 @@ RETURNING event_id, event_name, event_code, organisation_id;
 
 #### 5.5 Assign User Roles
 
+**Option 1: Explicit Organisation Membership (Traditional)**
+
 ```sql
 -- Grant a user the org_admin role (replace with actual user and organisation IDs)
 INSERT INTO rbac_organisation_roles (user_id, organisation_id, role, status, granted_at)
@@ -216,6 +220,42 @@ ON CONFLICT (user_id, organisation_id) DO UPDATE SET
   updated_at = NOW();
 ```
 
+**Option 2: Event-Based Access (Automatic Organisation Inference)**
+
+For event-based apps, you can grant access via event roles. The system will automatically infer organisation access from event access:
+
+```sql
+-- Grant a user event access (organisation access is automatically inferred)
+-- Replace with actual user, event, app, and organisation IDs
+INSERT INTO rbac_event_app_roles (
+  user_id, 
+  event_id, 
+  app_id, 
+  organisation_id,
+  role, 
+  status, 
+  granted_at
+)
+VALUES (
+  'your-user-id'::uuid,
+  'your-event-id'::text,
+  (SELECT id FROM rbac_apps WHERE name = 'pace-trac'),
+  'your-organisation-id'::uuid,  -- Must match event's organisation_id
+  'planner',  -- or 'event_admin', 'participant', etc.
+  'active',
+  NOW()
+)
+ON CONFLICT (user_id, event_id, app_id, role) DO UPDATE SET
+  status = EXCLUDED.status,
+  updated_at = NOW();
+```
+
+**Important Notes:**
+- When a user has event access via `rbac_event_app_roles`, they automatically get implicit organisation access
+- The system grants an implicit 'member' role for permission checks
+- Explicit organisation memberships take precedence over inferred access
+- This eliminates the need to maintain duplicate organisation memberships for event-only users
+
 ### 6. Create Supabase Client
 
 Create `src/lib/supabase.ts`:
@@ -640,7 +680,9 @@ Your event-based RBAC setup is working correctly if:
 - [ ] App is registered in `rbac_apps` table with `requires_event = true` and `is_active = true`
 - [ ] Pages exist in `rbac_app_pages` for your app
 - [ ] Page permissions exist in `rbac_page_permissions` for your pages, roles, and organisation
-- [ ] User has an active role in `rbac_organisation_roles` for the organisation
+- [ ] User has either:
+  - An active role in `rbac_organisation_roles` for the organisation, OR
+  - Event access via `rbac_event_app_roles` (organisation access is automatically inferred)
 - [ ] At least one event exists in the `event` table for your organisation
 - [ ] `VITE_APP_NAME` environment variable matches database `rbac_apps.name` exactly
 - [ ] `EventProvider` wraps your app content
@@ -762,15 +804,40 @@ WHERE event_id = 'your-event-id'::uuid;
    ```
    - Must have pages for `dashboard`, `participants`, etc.
 
-5. **Verify user has organisation role**:
+5. **Verify user has organisation role OR event access**:
    ```sql
-   SELECT ror.*, u.email
+   -- Check explicit organisation roles
+   SELECT ror.*, u.email, 'explicit' as access_type
    FROM rbac_organisation_roles ror
    JOIN auth.users u ON ror.user_id = u.id
    WHERE ror.user_id = 'your-user-id'::uuid 
-     AND ror.status = 'active';
+     AND ror.status = 'active'
+   
+   UNION ALL
+   
+   -- Check event-based access (which infers organisation access)
+   SELECT 
+     rear.id,
+     rear.user_id,
+     e.organisation_id as organisation_id,
+     'member' as role,  -- Implicit role granted from event access
+     rear.status,
+     rear.granted_at,
+     rear.granted_by,
+     rear.revoked_at,
+     rear.revoked_by,
+     u.email,
+     'inferred' as access_type
+   FROM rbac_event_app_roles rear
+   JOIN event e ON e.event_id = rear.event_id
+   JOIN auth.users u ON rear.user_id = u.id
+   WHERE rear.user_id = 'your-user-id'::uuid 
+     AND rear.status = 'active'
+     AND e.organisation_id = 'your-organisation-id'::uuid;
    ```
-   - User must have at least one active role
+   - User must have either:
+     - At least one active explicit organisation role, OR
+     - Event access via `rbac_event_app_roles` (organisation access is automatically inferred)
    - Must be for the organisation that owns the event
 
 6. **Verify event belongs to user's organisation**:
@@ -847,8 +914,59 @@ WHERE event_id = 'your-event-id'::uuid;
 | **Context Required** | `organisationId` | `eventId` (org auto-resolved) |
 | **PagePermissionGuard** | Needs `organisationId` | Needs `eventId` (org auto-resolved) |
 | **Scope Resolution** | Direct from context | Organisation resolved from event |
+| **User Access** | Requires explicit `rbac_organisation_roles` | Can use `rbac_event_app_roles` (org access inferred) |
 | **Use Case** | User management, org settings | Event registration, event management |
 
+## 🎯 Organisation Access Inference from Events
+
+**New Feature:** The RBAC system can now automatically infer organisation access from event access, eliminating the need for explicit organisation memberships when users have event access.
+
+### How It Works
+
+1. **User has event access** via `rbac_event_app_roles` table
+2. **System derives organisation** from the event's `organisation_id`
+3. **System grants implicit 'member' role** for permission checks
+4. **Permission checks proceed** as if user had explicit organisation membership
+
+### Benefits
+
+- **Eliminates data duplication** - No need to maintain both event and organisation memberships
+- **Simplifies onboarding** - Grant event access, organisation access is automatic
+- **Maintains security** - Still validates that user has valid event access
+- **Backward compatible** - Explicit organisation memberships still work and take precedence
+
+### Example
+
+```sql
+-- User has event access but no explicit organisation membership
+INSERT INTO rbac_event_app_roles (
+  user_id, 
+  event_id, 
+  app_id, 
+  organisation_id,
+  role, 
+  status
+)
+VALUES (
+  'user-123'::uuid,
+  'event-456'::text,
+  (SELECT id FROM rbac_apps WHERE name = 'pace-trac'),
+  'org-789'::uuid,
+  'planner',
+  'active'
+);
+
+-- System automatically allows organisation access for permission checks
+-- User can now access pages that require organisation context
+-- Implicit role: 'member' (for permission matching)
+```
+
+### When Explicit Membership is Still Required
+
+- Users who need organisation-level access without event context
+- Users who need specific organisation roles (org_admin, leader) that aren't granted via events
+- Organisation management features that don't require event context
+
 ## 🚀 Next Steps
 
 - **[RBAC Overview](./README.md)** - Complete RBAC system documentation

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jmruthers/pace-core",
-  "version": "0.5.191",
+  "version": "0.5.193",
   "description": "Clean, modern React component library with Tailwind v4 styling and native utilities",
   "private": false,
   "publishConfig": {