docs: added roles and permission docs

docs/roles-permissions.md

@@ -0,0 +1,67 @@
+# Role and Permission Concept
+
+## Goals
+
+## High-level concept
+
+- Constraints
+    - Roles are predefined, but can be renamed, removed, added
+    - Permissions for each role can be configured
+- Use Cases
+    - restrict read or write access to specific member data, groups and pages for certain roles
+        - this includes built-in hardcoded fields such as address, payment information, payment history, etc.
+- Example Roles
+    - Vorstand
+        - Access to members, but not to users
+    - Kassenwart
+    - Buchhaltung
+    - Admin
+- Role should decide which custom fields, members and pages to show
+    - e.g. changing custom field definitions should only be done by admins
+    
+## Permission
+
+- Subject: user with exactly one role
+- Action: read, write (create, update, delete)
+- Object:
+    - users, custom fields, groups, roles, user credentials
+    - page, group, members in a group, member field, custom field value, Payments
+
+## Rules
+
+Every user can be assigned **one out of the four basic permissions**:
+
+1. **Basic (default)** - Every user can always **read and write their own** credentials, member fields, custom field values, and group associations
+2. **Read-only** - Permissions for reading, no writing rights 
+    - all members
+    - all group association
+    - specific pages
+    - all custom fields values (indirectly the custom fields' definitions)
+    - all hardcoded member fields except credentials
+    - payment history: yes/no
+3. **Normal User** - permissions for writing (implies permission to read) 
+    - specific pages, 
+    - always all members: yes/no,
+    - all custom field values (and reading their custom field definitions), 
+    - all member fields except credentials, 
+    - payment history: yes/no
+4. **Admin** - Permission for reading and writing: users, custom fields, groups, roles, user credentials
+
+    
+Each of these permissions can be split up in the future to provide more granular access controls, e.g. for only accessing specific fields of a member.
+For each operation, authorization checks in the code should already take the subject, action and object as arguments to make it easier to migrate to fine-grained permissions in the future.
+
+**Some special object notes:**    
+- user credentials (email & password)
+    - users can always write their own credentials
+    - only admins can write credentials for other users
+    - Enforce these rules also when editing the email of an associated member
+- Pages
+    - Opening a page is always considered a read action, even if the page contains forms for updating other authorization objects
+    - For each page, define which roles can access it
+- Member fields
+    - special handling of email field, if it's associated to a user
+    
+## Other
+
+- UI/UX: Independently of permissions, users might want to hide some pages, member fields or groups because they don't need them. These should be individual settings. We should create a ticket for mocking this up.