[r/boards] initialize role management

[salmad3]

Context

This issue is meant to check and finalize the initial role management.

The MVP plans to introduce distinct roles (Owner, Admin, Moderator, Member, Public) and a set of permissions (e.g., create:board, flag:thread, invite:member, etc.). This ensures that day-to-day operations (like creating threads, moderating content, or configuring boards) can be delegated appropriately.

Acceptance Criteria

• Role Definitions

  • Implements (or finalizes) five key roles for the MVP:
    1. Owner – Has unrestricted privileges within the boards realm (akin to “super” or “root” access).
    2. Admin – Can perform high-level administrative tasks, including creating boards, managing moderators, and modifying certain realm settings.
    3. Moderator – Primarily handles content-level moderation (flagging, hiding posts, etc.) without broader administrative authority.
    4. Member – A standard user who can create and participate in threads/comments but doesn’t have moderation privileges.
    5. Public – Non-logged-in (or basic) users restricted mostly to read-only access (or potentially no access on private boards).

• Permission Mapping

  • Provides a permission map such as:
    • "create:board", "rename:board", "delete:board"
    • "flag:thread", "flag:comment", "hide:post"
    • "invite:member", "remove:member", etc.
  • Ensures each role is mapped to a relevant subset of permissions. For example:
    • Owner: all permissions
    • Admin: board-level creation, removing members, etc.
    • Moderator: flag/hide posts, manage local members (optionally)
    • Member: create threads/comments (no moderation actions)
    • Public: read-only or restricted

• Checking Permissions

  • Implements or refine functions like HasPermission(user Address, permission string, args []interface{}) bool.
  • Possibly wraps it with a utility like WithPermission(...) if we want to incorporate callback logic or proposal-based approaches later.
  Example

  func (br *BoardsRealm) HasPermission(user Address, permission string, args []interface{}) bool {
      role := br.GetRole(user)
      perms := br.rolePermissions[role] // a map of roles to permission sets
      _, hasPerm := perms[permission]
      return hasPerm
  }

• Assigning / Changing Roles

  • Provides a function (or set of functions) allowing the Owner or Admin to assign a role to a user:
    • e.g. SetUserRole(user Address, role string) requires "role:assign" permission.
  • Includes checks so only higher-level roles can make role changes for others (e.g., an Admin cannot demote the Owner).

• Local vs. Global Permissions

  • Recognizes that boards might have local moderators vs. the super DAO for the entire realm.
  • Ensures the system can differentiate “global realm roles” (Owner, Admin) from “board-specific roles” (local Moderator).

• Tests

  • Confirm that each role can or cannot perform key actions:
    • Creating a board vs. failing if user is Member.
    • Flagging a thread vs. failing if user is Public (or if no permission).
    • Changing roles (Owner can do it, Admin can do it if allowed, others cannot).
  • Cover edge cases (e.g., unknown role, invalid permission key, etc.).

Notes

• Initially, role definitions can be hard-coded in the MVP. Future versions might allow on-chain proposals for custom roles/permissions.
• Consider storing roles in a standardized structure (e.g., a map from Address -> Role).
• Over time, new permissions may be introduced in v2, v3, etc., but the core MVP roles should remain stable.
• Keep in mind potential expansions like:
  • Temporary Roles (e.g., “guest mod” for a short event).
  • Board-level roles vs. Realm-level roles.
  • Proposal-based modifications to permission sets (tying into a future governance module).

[jeronimoalbi]

@salmad3 to solve Integration with AdminDAO I think we have to define which are the special permissions that a super DAO has over the board DAOs. For example, removing (hidding) boards in case their content is inappropriate. Once we do we could solve it in a new issue.

[jeronimoalbi]

Proposal-based modifications to permission sets (tying into a future governance module)

@salmad3 we could have an issue so in the future we support changing role permissions dynamically. But it might not even be required, roles and permissions mapping is up to the Permissions interface implementer, so as long as we can dynamically assign one we are able to change permission mappings by deploying a new realm that implements Permissions to then assign it to boards though a proposal voted by the super DAO.

[salmad3]

@jeronimoalbi sounds good, let's tackle integration with AdminDAO as a follow up.