ahmido
3030dd9af2
Summary Kurz: Implementiert Feature 054 — canonical OperationRun-flow, Monitoring UI, dispatch-safety, notifications, dedupe, plus small UX safety clarifications (RBAC group search delegated; Restore group mapping DB-only). What Changed Core service: OperationRun lifecycle, dedupe and dispatch helpers — OperationRunService.php. Model + migration: OperationRun model and migration — OperationRun.php, 2026_01_16_180642_create_operation_runs_table.php. Notifications: queued + terminal DB notifications (initiator-only) — OperationRunQueued.php, OperationRunCompleted.php. Monitoring UI: Filament list/detail + Livewire pieces (DB-only render) — OperationRunResource.php and related pages/views. Start surfaces / Jobs: instrumented start surfaces, job middleware, and job updates to use canonical runs — multiple app/Jobs/* and app/Filament/* updates (see tests for full coverage). RBAC + Restore UX clarifications: RBAC group search is delegated-Graph-based and disabled without delegated token; Restore group mapping remains DB-only (directory cache) and helper text always visible — TenantResource.php, RestoreRunResource.php. Specs / Constitution: updated spec & quickstart and added one-line constitution guideline about Graph usage: spec.md quickstart.md constitution.md Tests & Verification Unit / Feature tests added/updated for run lifecycle, notifications, idempotency, and UI guards: see tests/Feature/* (notably OperationRunServiceTest, MonitoringOperationsTest, OperationRunNotificationTest, and various Filament feature tests). Full test run locally: ./vendor/bin/sail artisan test → 587 passed, 5 skipped. Migrations Adds create_operation_runs_table migration; run php artisan migrate in staging after review. Notes / Rationale Monitoring pages are explicitly DB-only at render time (no Graph calls). Start surfaces enqueue work only and return a “View run” link. Delegated Graph access is used only for explicit user actions (RBAC group search); restore mapping intentionally uses cached DB data only to avoid render-time Graph calls. Dispatch wrapper marks runs failed immediately if background dispatch throws synchronously to avoid misleading “queued” states. Upgrade / Deploy Considerations Run migrations: ./vendor/bin/sail artisan migrate. Background workers should be running to process queued jobs (recommended to monitor queue health during rollout). No secret or token persistence changes. PR checklist Tests updated/added for changed behavior Specs updated: 054-unify-runs-suitewide docs + quickstart Constitution note added (.specify) Pint formatting applied Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #63
4.3 KiB
Feature Specification: [FEATURE NAME]
Feature Branch: [###-feature-name]
Created: [DATE]
Status: Draft
Input: User description: "$ARGUMENTS"
User Scenarios & Testing (mandatory)
User Story 1 - [Brief Title] (Priority: P1)
[Describe this user journey in plain language]
Why this priority: [Explain the value and why it has this priority level]
Independent Test: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
Acceptance Scenarios:
- Given [initial state], When [action], Then [expected outcome]
- Given [initial state], When [action], Then [expected outcome]
User Story 2 - [Brief Title] (Priority: P2)
[Describe this user journey in plain language]
Why this priority: [Explain the value and why it has this priority level]
Independent Test: [Describe how this can be tested independently]
Acceptance Scenarios:
- Given [initial state], When [action], Then [expected outcome]
User Story 3 - [Brief Title] (Priority: P3)
[Describe this user journey in plain language]
Why this priority: [Explain the value and why it has this priority level]
Independent Test: [Describe how this can be tested independently]
Acceptance Scenarios:
- Given [initial state], When [action], Then [expected outcome]
[Add more user stories as needed, each with an assigned priority]
Edge Cases
- What happens when [boundary condition]?
- How does system handle [error scenario]?
Requirements (mandatory)
Constitution alignment (required): If this feature introduces any Microsoft Graph calls, any write/change behavior,
or any long-running/queued/scheduled work, the spec MUST describe contract registry updates, safety gates
(preview/confirmation/audit), tenant isolation, run observability (OperationRun type/identity/visibility), and tests.
If security-relevant DB-only actions intentionally skip OperationRun, the spec MUST describe AuditLog entries.
Functional Requirements
- FR-001: System MUST [specific capability, e.g., "allow users to create accounts"]
- FR-002: System MUST [specific capability, e.g., "validate email addresses"]
- FR-003: Users MUST be able to [key interaction, e.g., "reset their password"]
- FR-004: System MUST [data requirement, e.g., "persist user preferences"]
- FR-005: System MUST [behavior, e.g., "log all security events"]
Example of marking unclear requirements:
- FR-006: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
- FR-007: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
Key Entities (include if feature involves data)
- [Entity 1]: [What it represents, key attributes without implementation]
- [Entity 2]: [What it represents, relationships to other entities]
Success Criteria (mandatory)
Measurable Outcomes
- SC-001: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
- SC-002: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
- SC-003: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
- SC-004: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]