local-it/mitgliederverwaltung
2
3
Fork 0
Code Issues 53 Pull requests 1 Projects 2 Releases 3 Packages 1 Activity Actions

feat: improve field order for approvals and add seeds
Some checks failed
continuous-integration/drone/push Build is failing
Details

Browse source
This commit is contained in:
Simon 2026-03-12 16:15:57 +01:00
parent a5ce7cb921
commit a7481f6ab1
Signed by: simon
GPG key ID: 40E7A58C4AA1EDB2
8 changed files with 245 additions and 109 deletions
Download patch file Download diff file Expand all files Collapse all files

3
docs/onboarding-join-concept.md
View file

@ -93,6 +93,7 @@
- **Placement:** Own section **"Onboarding / Join"** in global settings, **above** "Custom fields", **below** "Vereinsdaten" (club data).
- **Join form enabled:** Checkbox (e.g. `join_form_enabled`). When set, the public `/join` page is active and the following config applies.
- **Copyable join link:** When the join form is enabled, a copyable full URL to the `/join` page is shown below the checkbox (above the field list), with a short hint so admins can share it with applicants.
- **Field selection:** From **all existing** member fields (from `Mv.Constants.member_fields()`) and **custom fields**, the admin selects which fields appear on the join form. Stored as a list/set of field identifiers (no separate table); display in settings as a simple list, e.g. **badges with X to remove** (similar to the groups overview). Adding fields: e.g. dropdown or modal to pick from remaining fields. Detailed UX for this subsection is to be specified in a **separate subtask**.
- **Technically required fields:** The only field that must always be required for the join flow is **email**. All other fields can be optional or marked as required per admin choice; implementation should support a "required" flag per selected join-form field.
- **Other:** Which entry paths are enabled, approval workflow (who can approve) – to be detailed in Step 2 and later specs.
@ -115,7 +116,7 @@ Implementation spec for Subtask 5.
#### Route and pages
- **List:** **`/join_requests`** – list of join requests. Filter by status (default or primary view: status `submitted`); optional view for "all" or "approved/rejected" for audit.
- **Detail:** **`/join_requests/:id`** – single join request with all data (typed fields + `form_data`), actions Approve / Reject.
- **Detail:** **`/join_requests/:id`** – single join request. **Two blocks:** (1) **Applicant data** – all form fields (typed + `form_data`) merged and shown in join-form order; (2) **Status and review** – submitted_at, status, and when decided: approved_at/rejected_at, reviewed by. Actions Approve / Reject when status is `submitted`.
#### Backend (JoinRequest)