Files
gurixandClaude 5053b80998 feat: Add organization member support with memberType field
Implements support for both individual persons and organizations as members.

Changes:
- Added MemberType enum (INDIVIDUAL, ORGANIZATION) to distinguish member types
- Added member_type column to database (defaults to INDIVIDUAL for backward compatibility)
- Added company_name field for organizations
- Made first_name nullable (required for individuals, optional for organizations)
- Implemented conditional validation:
  - INDIVIDUAL members require first_name
  - ORGANIZATION members require company_name
- Updated GraphQL schema with new memberType and companyName fields
- Updated all resolvers to handle new fields and validation
- Added comprehensive unit tests for validation logic
- Updated existing tests to work with new fields
- All 53 tests passing

Technical notes:
- Using memberType instead of 'kind' to avoid GraphQL introspection conflicts
- Using native_enum=False for SQLite compatibility
- Using batch_alter_table for SQLite ALTER COLUMN compatibility
- Backward compatible: existing members automatically become INDIVIDUAL type

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-04 12:15:55 +01:00

1.4 KiB

Design: Organization Member Support

Data Model Changes

Member Table

  • Add member_type column: Enum (INDIVIDUAL, ORGANIZATION). Default to INDIVIDUAL for existing records.
  • Add company_name column: String, nullable.
  • Alter first_name: Change from nullable=False to nullable=True.

Constraints

  • Application Level:
    • If member_type is INDIVIDUAL: first_name must be present.
    • If member_type is ORGANIZATION: company_name must be present.
  • Database Level:
    • We can't easily enforce conditional not-null constraints in standard SQL without triggers or check constraints. For simplicity and portability (SQLite/Postgres), we will enforce this at the application level (Pydantic/SQLAlchemy validators) and potentially add a CHECK constraint if supported by both dialects easily.
    • first_name will become nullable in the DB schema.

API Changes

GraphQL Schema

  • Update Member type to include memberType and companyName.
  • Update createMember and updateMember inputs.
  • Add validation logic in resolvers to enforce the conditional requirements.

Migration Strategy

  1. Add member_type column with default 'INDIVIDUAL'.
  2. Add company_name column.
  3. Alter first_name to be nullable.

Technical Note

  • Using memberType instead of kind to avoid conflicts with GraphQL introspection queries which use kind as a metadata field.