Add PermissionSets for Group, MemberGroup, MembershipFeeType, MembershipFeeCycle

- Extend permission_sets.ex with resources and pages for new domains
- Adjust HasPermission check for resource/action/scope
- Update roles-and-permissions and implementation-plan docs
- Add permission_sets_test.exs coverage

docs/roles-and-permissions-architecture.md

@@ -97,6 +97,10 @@ Control CRUD operations on:
 - CustomFieldValue (custom field values)
 - CustomField (custom field definitions)
 - Role (role management)
+- Group (group definitions; read all, create/update/destroy admin only)
+- MemberGroup (member–group associations; own_data read :linked, read_only read :all, normal_user/admin create/destroy)
+- MembershipFeeType (fee type definitions; all read, admin-only create/update/destroy)
+- MembershipFeeCycle (fee cycles; all read, normal_user/admin read+create+update+destroy; manual "Regenerate Cycles" for normal_user and admin)
 
 **4. Page-Level Permissions**
 
@@ -105,6 +109,7 @@ Control access to LiveView pages:
 - Show pages (detail views)
 - Form pages (create/edit)
 - Admin pages
+- Settings pages: `/settings` and `/membership_fee_settings` are admin-only (explicit in PermissionSets)
 
 **5. Granular Scopes**
 
@@ -121,6 +126,8 @@ Three scope levels for permissions:
 - **Linked Member Email:** Only admins can edit email of member linked to user
 - **System Roles:** "Mitglied" role cannot be deleted (is_system_role flag)
 - **User-Member Linking:** Only admins can link/unlink users and members
+- **User Role Assignment:** Only admins can change a user's role (via `update_user` with `role_id`). Last-admin validation ensures at least one user keeps the Admin role.
+- **Settings Pages:** `/settings` and `/membership_fee_settings` are admin-only (explicit in PermissionSets pages).
 
 **7. UI Consistency**
 
@@ -684,6 +691,11 @@ Quick reference table showing what each permission set allows:
 | **CustomFieldValue** (all) | - | R | R, C, U, D | R, C, U, D |
 | **CustomField** (all) | R | R | R | R, C, U, D |
 | **Role** (all) | - | - | - | R, C, U, D |
+| **Group** (all) | R | R | R | R, C, U, D |
+| **MemberGroup** (linked) | R | - | - | - |
+| **MemberGroup** (all) | - | R | R, C, D | R, C, D |
+| **MembershipFeeType** (all) | R | R | R | R, C, U, D |
+| **MembershipFeeCycle** (all) | R | R | R, C, U, D | R, C, U, D |
 
 **Legend:** R=Read, C=Create, U=Update, D=Destroy
 
@@ -1195,6 +1207,36 @@ end
 
 *Cannot destroy if `is_system_role=true`
 
+### User Role Assignment (Admin-Only)
+
+**Location:** `lib/accounts/user.ex` (update_user action), `lib/mv_web/live/user_live/form.ex`
+
+Only admins can change a user's role. The `update_user` action accepts `role_id`; the User form shows a role dropdown when `can?(actor, :update, Mv.Authorization.Role)`. **Last-admin validation:** If the only non-system admin tries to change their role, the change is rejected with "At least one user must keep the Admin role." (System user is excluded from the admin count.) See [User-Member Linking](#user-member-linking) for the same admin-only pattern.
+
+### Group Resource Policies
+
+**Location:** `lib/membership/group.ex`
+
+Policies use `HasPermission` for read/create/update/destroy. All permission sets can read; only admin can create, update, destroy. No bypass (scope :all only in PermissionSets).
+
+### MemberGroup Resource Policies
+
+**Location:** `lib/membership/member_group.ex`
+
+Bypass for read with `expr(member_id == ^actor(:member_id))` (own_data list); HasPermission for read (read_only/normal_user/admin :all) and create/destroy (normal_user + admin only). HasPermission applies `:linked` scope for MemberGroup (see HasPermission apply_scope).
+
+### MembershipFeeType Resource Policies
+
+**Location:** `lib/membership_fees/membership_fee_type.ex`
+
+Policies use `HasPermission` for read/create/update/destroy. All permission sets can read; only admin can create, update, destroy.
+
+### MembershipFeeCycle Resource Policies
+
+**Location:** `lib/membership_fees/membership_fee_cycle.ex`
+
+Policies use `HasPermission` for read/create/update/destroy. All can read; read_only cannot update/create/destroy; normal_user and admin can read, create, update, and destroy (including mark_as_paid and manual "Regenerate Cycles" in the member detail view; UI button is shown when `can_create_cycle`).
+
 ---
 
 ## Page Permission System

docs/roles-and-permissions-implementation-plan.md

@@ -78,10 +78,11 @@ Stored in database `roles` table, each referencing a `permission_set_name`:
 - ✅ Hardcoded PermissionSets module with 4 permission sets
 - ✅ Role database table and CRUD interface
 - ✅ Custom Ash Policy Check (`HasPermission`) that reads from PermissionSets
-- ✅ Policies on all resources (Member, User, CustomFieldValue, CustomField, Role)
-- ✅ Page-level permissions via Phoenix Plug
+- ✅ Policies on all resources (Member, User, CustomFieldValue, CustomField, Role, Group, MemberGroup, MembershipFeeType, MembershipFeeCycle)
+- ✅ Page-level permissions via Phoenix Plug (including admin-only `/settings` and `/membership_fee_settings`)
 - ✅ UI authorization helpers for conditional rendering
 - ✅ Special case: Member email validation for linked users
+- ✅ User role assignment: admin-only `role_id` in update_user; Last-Admin validation; role dropdown in User form when `can?(actor, :update, Role)`
 - ✅ Seed data for 5 roles
 
 **Benefits of Hardcoded Approach:**