🚀 Feature: Community Management Permission System (Events + Core Actions) – Commdesk

[abhishek-nexgen-dev]

Implement a centralized permission system for Community Management in Commdesk.

This includes managing:

• Events
• Members
• Roles
• Content (posts/messages)

All permissions must follow a standard format:

resource:action

Example:

event:create
event:update
event:delete

---

🎯 Objective

Enable fine-grained control over what users can do inside a community.

Example:

• Admin → full control
• Moderator → manage events & members
• User → view & participate only

---

🧩 Permission Design

🔹 Event Permissions

event:create
event:read
event:update
event:delete
event:publish
event:join
event:leave

---

🔹 Member Management

member:add
member:remove
member:ban
member:unban
member:view

---

🔹 Role Management

role:create
role:update
role:delete
role:assign

---

🔹 Community Management

community:update
community:delete
community:view
community:invite

---

🔹 Content (Optional but Recommended)

post:create
post:update
post:delete
comment:create
comment:delete

---

🏗️ Scope of Work

1. Extend Permission Schema

• Add new permissions for:

  • event
  • member
  • role
  • community

---

2. Role Design (Community-Level)

• Create roles:

  • community_admin
  • community_moderator
  • community_member

• Assign permissions:

Admin

• Full access (all permissions)

Moderator

• event:create/update/delete
• member:remove/ban
• post moderation

Member

• event:read
• event:join/leave
• post:create

---

3. Community-Based Authorization (IMPORTANT)

• Add communityId context in permission checks
• Ensure user has role within that community

👉 Example:

User → Moderator in Community A
User → Member in Community B

---

4. Middleware Update

• Extend checkPermission(action, resource) to support:

checkPermission("create", "event", communityId)

• Validate:

  • user role in that community
  • permissions linked to that role

---

5. API Protection

Protect endpoints:

POST   /community/:id/event        → event:create
PATCH  /event/:id                 → event:update
DELETE /event/:id                 → event:delete
POST   /event/:id/join            → event:join

---

6. Ownership / ABAC Layer

• Allow event creator to update/delete their own event
• Override role restriction if user is owner

---

7. Seed Data

• Seed all permissions
• Seed default roles with mapped permissions

---

🧪 Testing

• Admin can perform all actions
• Moderator cannot delete community
• Member cannot create event (unless allowed)
• Owner can edit their own event
• Cross-community permission isolation works

---

✅ Acceptance Criteria

• Permissions follow resource:action format
• Community-scoped roles are working
• All event APIs are protected
• No hardcoded role checks
• Ownership logic implemented
• Clean 403 responses for unauthorized access

---

📦 Suggested Folder Structure

/modules/community
/modules/permission
/modules/event

---

⚠️ Key Considerations

• Multi-community role mapping (critical)
• Avoid global roles for community actions
• Optimize DB queries (populate efficiently)

---

🔥 Future Enhancements

• UI for managing community roles
• Invite-based permission assignment
• Audit logs (event actions tracking)
• Real-time permission sync (WebSocket)