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

[FEATURE]: System Actor Mode for Systemic Flows #348

New issue
Open
opened 2026-01-13 16:52:41 +01:00 by moritz · 0 comments
moritz commented 2026-01-13 16:52:41 +01:00
Owner
Copy link

Problem

Currently, actor is consistently passed through all operations (cycle generation, email sync, email validation). This is correct for "user actions should respect policies" but conflicts with the goal: some validations/syncs should always run.

The current implementation creates a conflict:

  • User Mode: Policies are strict, actor is used (correct for user actions)
  • System Mode: Some operations need to bypass policies or use a system actor (for mandatory side effects)

Solution: Two Execution Modes

A) User Mode (Policies Strict, Actor Used)

  • User-initiated actions
  • Policies are enforced
  • Actor permissions are checked

B) System Mode (Policies Bypassed / System Actor)

  • Email uniqueness checks
  • Email sync (Member ↔ User)
  • Cycle generation (if defined as mandatory side effect)

Implementation: Introduce System Actor

Create a dedicated system actor (e.g., service user "system@..." or admin role used only internally) that is used in:

  • Seeds
  • Background jobs
  • Validations that must always run
  • Sync operations that must always run

Instead of using the user actor, use the system actor for these operations.

Affected Areas

1. Email Sync

Current State: actor is extracted from changeset context and passed to Loader
Required Change: Execute Email-Sync Loader systemically (using system actor) so it doesn't depend on user read permissions

Affected Files:

  • lib/mv/email_sync/loader.ex - All loader functions use actor
  • lib/mv/email_sync/changes/sync_user_email_to_member.ex - Extracts actor from context
  • lib/mv/email_sync/changes/sync_member_email_to_user.ex - Uses actor from context
  • lib/membership/member.ex - Email sync changes configured in actions
  • lib/accounts/user.ex - Email sync changes configured in actions

2. Email Validation

Current State: Validations extract actor from changeset context for authorization
Required Change: Use system actor for email uniqueness checks so they always run regardless of user permissions

Affected Files:

  • lib/mv/membership/member/validations/email_not_used_by_other_user.ex - Uses actor for User queries
  • lib/mv/accounts/user/validations/email_not_used_by_other_member.ex - Uses actor for Member queries
  • lib/membership/member.ex - Validation configured in validations block (line 393)
  • lib/accounts/user.ex - Validation configured in validations block

3. Cycle Generation

Current State: actor is passed through to cycle generation
Required Change: Decide if cycle generation is mandatory. If yes, execute systemically (using system actor)

Affected Files:

  • lib/mv/membership_fees/cycle_generator.ex - All functions accept actor parameter
  • lib/membership/member.ex - handle_cycle_generation passes actor (lines 949-992)
  • lib/mv/membership_fees/cycle_generation_job.ex - Job execution (currently no actor passed)

4. Other Changes/Validations Using Actor

Affected Files:

  • lib/membership/member.ex - User linking validation uses actor (lines 400-432)
  • lib/membership_fees/changes/validate_same_interval.ex - Currently doesn't use actor (but may need system actor for type loading)

Decision Points

  1. Email Sync: Should it always run (system mode) or be blocked if user lacks permissions?

    • Recommendation: Always run (system mode) - email sync is a mandatory side effect

  2. Cycle Generation: Is it mandatory or optional?

    • Recommendation: If mandatory, execute systemically (system mode)
    • If optional, keep current user mode but handle failures gracefully

  3. Email Uniqueness Validation: Should it always run?

    • Recommendation: Always run (system mode) - data integrity requirement

Implementation Steps

  1. Create system actor (service user or admin role)
  2. Add helper function to get system actor
  3. Update Email Sync Loader to use system actor
  4. Update Email Sync Changes to use system actor
  5. Update Email Validation modules to use system actor
  6. Update Cycle Generator to use system actor (if mandatory)
  7. Update Member hooks to use system actor for cycle generation (if mandatory)
  8. Update Cycle Generation Job to use system actor
  9. Update any other changes/validations that need system mode

Alternative: Early Blocking

If email sync should be blocked when user lacks permissions:

  • Main action (e.g., user email change) must check before execution if actor can perform all side effects
  • Return "Forbidden" early and consistently
  • This requires explicit permission checks before the main action

Acceptance Criteria

System Actor

  • System actor is created and accessible via helper function
  • System actor has necessary permissions to read/write User and Member resources
  • System actor is used in seeds and background jobs

Email Sync (System Mode)

  • Email sync runs successfully even when user actor lacks read permissions
  • Email sync works when no user actor is present (e.g., in background jobs)
  • Email sync still works correctly when user actor is present (backward compatibility)
  • All email sync tests pass with system actor

Email Validation (System Mode)

  • Email uniqueness validation runs successfully even when user actor lacks read permissions
  • Email uniqueness validation works when no user actor is present
  • Email uniqueness validation still works correctly when user actor is present
  • All email validation tests pass with system actor

Cycle Generation (System Mode - if mandatory)

  • Cycle generation runs successfully even when user actor lacks read permissions
  • Cycle generation works when no user actor is present (e.g., in background jobs)
  • Cycle generation still works correctly when user actor is present
  • All cycle generation tests pass with system actor

User Actions (User Mode)

  • User-initiated actions still respect policies correctly
  • User actions fail with Forbidden when user lacks permissions
  • No regression in existing authorization behavior
  • All existing authorization tests pass

Integration

  • All affected areas use system actor for systemic operations
  • No breaking changes for user-facing functionality
  • Documentation updated to explain system vs user mode
## Problem Currently, `actor` is consistently passed through all operations (cycle generation, email sync, email validation). This is correct for "user actions should respect policies" but **conflicts** with the goal: *some validations/syncs should always run*. The current implementation creates a conflict: - **User Mode**: Policies are strict, actor is used (correct for user actions) - **System Mode**: Some operations need to bypass policies or use a system actor (for mandatory side effects) ## Solution: Two Execution Modes ### A) User Mode (Policies Strict, Actor Used) - User-initiated actions - Policies are enforced - Actor permissions are checked ### B) System Mode (Policies Bypassed / System Actor) - Email uniqueness checks - Email sync (Member ↔ User) - Cycle generation (if defined as mandatory side effect) ### Implementation: Introduce System Actor Create a dedicated system actor (e.g., service user "system@..." or admin role used only internally) that is used in: - Seeds - Background jobs - Validations that must always run - Sync operations that must always run Instead of using the user actor, use the system actor for these operations. ## Affected Areas ### 1. Email Sync **Current State**: `actor` is extracted from changeset context and passed to Loader **Required Change**: Execute Email-Sync Loader systemically (using system actor) so it doesn't depend on user read permissions **Affected Files**: - `lib/mv/email_sync/loader.ex` - All loader functions use actor - `lib/mv/email_sync/changes/sync_user_email_to_member.ex` - Extracts actor from context - `lib/mv/email_sync/changes/sync_member_email_to_user.ex` - Uses actor from context - `lib/membership/member.ex` - Email sync changes configured in actions - `lib/accounts/user.ex` - Email sync changes configured in actions ### 2. Email Validation **Current State**: Validations extract actor from changeset context for authorization **Required Change**: Use system actor for email uniqueness checks so they always run regardless of user permissions **Affected Files**: - `lib/mv/membership/member/validations/email_not_used_by_other_user.ex` - Uses actor for User queries - `lib/mv/accounts/user/validations/email_not_used_by_other_member.ex` - Uses actor for Member queries - `lib/membership/member.ex` - Validation configured in validations block (line 393) - `lib/accounts/user.ex` - Validation configured in validations block ### 3. Cycle Generation **Current State**: `actor` is passed through to cycle generation **Required Change**: Decide if cycle generation is mandatory. If yes, execute systemically (using system actor) **Affected Files**: - `lib/mv/membership_fees/cycle_generator.ex` - All functions accept actor parameter - `lib/membership/member.ex` - `handle_cycle_generation` passes actor (lines 949-992) - `lib/mv/membership_fees/cycle_generation_job.ex` - Job execution (currently no actor passed) ### 4. Other Changes/Validations Using Actor **Affected Files**: - `lib/membership/member.ex` - User linking validation uses actor (lines 400-432) - `lib/membership_fees/changes/validate_same_interval.ex` - Currently doesn't use actor (but may need system actor for type loading) ## Decision Points 1. **Email Sync**: Should it always run (system mode) or be blocked if user lacks permissions? - **Recommendation**: Always run (system mode) - email sync is a mandatory side effect 2. **Cycle Generation**: Is it mandatory or optional? - **Recommendation**: If mandatory, execute systemically (system mode) - If optional, keep current user mode but handle failures gracefully 3. **Email Uniqueness Validation**: Should it always run? - **Recommendation**: Always run (system mode) - data integrity requirement ## Implementation Steps 1. Create system actor (service user or admin role) 2. Add helper function to get system actor 3. Update Email Sync Loader to use system actor 4. Update Email Sync Changes to use system actor 5. Update Email Validation modules to use system actor 6. Update Cycle Generator to use system actor (if mandatory) 7. Update Member hooks to use system actor for cycle generation (if mandatory) 8. Update Cycle Generation Job to use system actor 9. Update any other changes/validations that need system mode ## Alternative: Early Blocking If email sync should be blocked when user lacks permissions: - Main action (e.g., user email change) must check **before** execution if actor can perform all side effects - Return "Forbidden" early and consistently - This requires explicit permission checks before the main action ## Acceptance Criteria ### System Actor - [ ] System actor is created and accessible via helper function - [ ] System actor has necessary permissions to read/write User and Member resources - [ ] System actor is used in seeds and background jobs ### Email Sync (System Mode) - [ ] Email sync runs successfully even when user actor lacks read permissions - [ ] Email sync works when no user actor is present (e.g., in background jobs) - [ ] Email sync still works correctly when user actor is present (backward compatibility) - [ ] All email sync tests pass with system actor ### Email Validation (System Mode) - [ ] Email uniqueness validation runs successfully even when user actor lacks read permissions - [ ] Email uniqueness validation works when no user actor is present - [ ] Email uniqueness validation still works correctly when user actor is present - [ ] All email validation tests pass with system actor ### Cycle Generation (System Mode - if mandatory) - [ ] Cycle generation runs successfully even when user actor lacks read permissions - [ ] Cycle generation works when no user actor is present (e.g., in background jobs) - [ ] Cycle generation still works correctly when user actor is present - [ ] All cycle generation tests pass with system actor ### User Actions (User Mode) - [ ] User-initiated actions still respect policies correctly - [ ] User actions fail with Forbidden when user lacks permissions - [ ] No regression in existing authorization behavior - [ ] All existing authorization tests pass ### Integration - [ ] All affected areas use system actor for systemic operations - [ ] No breaking changes for user-facing functionality - [ ] Documentation updated to explain system vs user mode
moritz added the
L
 label 2026-01-13 16:52:49 +01:00
moritz added this to the Sprint 11: 08.01-29.01 project 2026-01-13 16:52:57 +01:00
moritz self-assigned this 2026-01-13 16:53:08 +01:00
moritz added this to the Accounts & Logins milestone 2026-01-13 16:53:11 +01:00
Sign in to join this conversation.
main
Branches Tags
Clear current reference
main
docs/update
speed-up-drone
feature/220_ui_issues_2
persist-sort-order
feature/151_roles_permissions_docs
manual_renovate_update
feature/#158-polish-README
feature/128_playwright_a11y_test
feature/119_member_user_relation_refactor
feature/119_user_as_member
feature/backpex-migration
feature/backpex_translation
feature/39_account_ressource
feature/74_memberfields
validation
feature/36_add_primerlive
Clear current reference
No results found.
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
high priority

   
invalid

Something is wrong

  
L

5 h

  
low priority

   
M

3 h

  
medium priority

   
needs refinement

   
optional

   
question

More information is needed

  
S

1 h

  
UX research

   
wontfix

This won't be fixed

No labels
bug
duplicate
enhancement
help wanted
high priority
invalid
L
low priority
M
medium priority
needs refinement
optional
question
S
UX research
wontfix
Milestone
Clear milestone
No items
No milestone
Accounts & Logins
Projects
Clear projects
No items
No project
Sprint 11: 08.01-29.01
Assignees
Clear assignees
No assignees
moritz
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: local-it/mitgliederverwaltung#348
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?