linusandClaude Sonnet 5
dbaafabcf4
New onboarding/ module. A prospective Verantwortliche/r signs in with their
Konfi-Castle-ID (Authentik), looks up a KC by invite code, picks an existing
Gemeinde, and registers:
- GET /api/onboarding/kc/:inviteCode -> KC name + its Gemeinden (public;
the invite code is the shared secret)
- POST /api/onboarding/verantwortliche -> verifies the raw Authentik bearer
token's claims (no local Membership required yet via new
TokenVerificationService.verifyAuthentikClaims), JIT-provisions the local
User, and creates a Membership with status PENDING. Idempotent per
(user, kc, gemeinde).
- GET /api/onboarding/requests?kcId= (LT) list pending
- POST /api/onboarding/requests/:id/approve|reject (LT) approve flips to
ACTIVE, reject deletes.
Schema: Membership gains status (enum MembershipStatus { ACTIVE, PENDING },
default ACTIVE). AuthentikStrategy / TokenVerificationService / TeamAuthService
now load only ACTIVE memberships, so a pending request grants nothing until
approved. Membership create/update/delete flow through the sync log.
Tests: onboarding.service.spec.ts (14 cases); npm test green at 46.
Docs (plan + backend README) updated.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
12 lines
358 B
TypeScript
12 lines
358 B
TypeScript
import { Module } from '@nestjs/common';
|
|
import { AuthModule } from '../auth/auth.module';
|
|
import { OnboardingService } from './onboarding.service';
|
|
import { OnboardingController } from './onboarding.controller';
|
|
|
|
@Module({
|
|
imports: [AuthModule],
|
|
providers: [OnboardingService],
|
|
controllers: [OnboardingController],
|
|
})
|
|
export class OnboardingModule {}
|