2.0 KiB
Chat roles and membership
Chat access is based on Chat.created_by, ChatMembership and django-rules.
The owner is not a membership role; membership roles are admin, moderator,
member and guest.
Role defaults
| Role | Send | Add/remove members | Pin messages |
|---|---|---|---|
admin |
yes | yes | yes |
moderator |
yes | no | yes |
member |
yes | no | no |
guest |
no | no | no |
set_permissions_for_role() applies these defaults. It runs automatically only
when a membership is created. Code changing role directly must call the method
before saving; the API action already does this.
The owner has full management rights and cannot leave the chat. Global chats are
available to all users. Private chats and legacy participant relations have
compatibility handling in communications.rules; comments chats resolve access
through their context participant resolver.
HTTP actions
Prefix: /api/v1/communications/chats/{chat_id}/.
POST add-member/— owner/admin or an allowed membership;POST remove-member/— owner/admin or an allowed membership;POST change-role/— owner or superuser only;POST leave/— active member except the owner.
Member and role payloads use user_id; role changes additionally require one of
the four role values. Exact responses are published in /api/docs/.
Rules
Public rules include communications.view_chat, send_message, change_chat,
delete_chat, view_message, change_message, delete_message, add_members,
remove_members, pin_message, change_member_role, leave_chat,
view_chat_history and search_messages.
Use user.has_perm(rule_name, object) or the API permission layer. Do not repeat
role checks in frontend components as an authorization boundary; frontend flags
are only for presenting available actions.
Verification
cd backend
pytest tests/api/v1/communications -q
See also the HTTP API and WebSocket guide.