ahmido
a97beefda3
Kurzbeschreibung Versteckt die Rerun-Row-Action für archivierte (soft-deleted) RestoreRuns und verhindert damit fehlerhafte Neu-Starts aus dem Archiv; ergänzt einen Regressionstest. Änderungen Code: RestoreRunResource.php — Sichtbarkeit der rerun-Action geprüft auf ! $record->trashed() und defensive Abbruchprüfung im Action-Handler. Tests: RestoreRunRerunTest.php — neuer Test rerun action is hidden for archived restore runs. Warum Archivierte RestoreRuns durften nicht neu gestartet werden; UI zeigte trotzdem die Option. Das führte zu verwirrendem Verhalten und möglichen Fehlern beim Enqueueing. Verifikation / QA Unit/Feature: ./vendor/bin/sail artisan test tests/Feature/RestoreRunRerunTest.php Stil/format: ./vendor/bin/pint --dirty Manuell (UI): Als Tenant-Admin Filament → Restore Runs öffnen. Filter Archived aktivieren (oder Trashed filter auswählen). Sicherstellen, dass für archivierte Einträge die Rerun-Action nicht sichtbar ist. Auf einem aktiven (nicht-archivierten) Run prüfen, dass Rerun sichtbar bleibt und wie erwartet eine neue RestoreRun erzeugt. Wichtige Hinweise Kein DB-Migration required. Diese PR enthält nur den UI-/Filament-Fix; die zuvor gemachten operative Fixes für Queue/adapter-Reconciliation bleiben ebenfalls auf dem Branch (z. B. frühere commits während der Debugging-Session). T055 (Schema squash) wurde bewusst zurückgestellt und ist nicht Teil dieses PRs. Merge-Checklist Tests lokal laufen (RestoreRunRerunTest grünt) Pint läuft ohne ungepatchte Fehler Branch gepusht: 056-remove-legacy-bulkops (PR-URL: https://git.cloudarix.de/ahmido/TenantAtlas/compare/dev...056-remove-legacy-bulkops) Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #65
36 lines
1.4 KiB
Markdown
36 lines
1.4 KiB
Markdown
# Specification Quality Checklist: Remove Legacy BulkOperationRun & Canonicalize Operations (v1.0)
|
|
|
|
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
|
**Created**: 2026-01-18
|
|
**Feature**: [specs/056-remove-legacy-bulkops/spec.md](../spec.md)
|
|
|
|
## Content Quality
|
|
|
|
- [x] No implementation details (languages, frameworks, APIs)
|
|
- [x] Focused on user value and business needs
|
|
- [x] Written for non-technical stakeholders
|
|
- [x] All mandatory sections completed
|
|
|
|
## Requirement Completeness
|
|
|
|
- [x] No [NEEDS CLARIFICATION] markers remain
|
|
- [x] Requirements are testable and unambiguous
|
|
- [x] Success criteria are measurable
|
|
- [x] Success criteria are technology-agnostic (no implementation details)
|
|
- [x] All acceptance scenarios are defined
|
|
- [x] Edge cases are identified
|
|
- [x] Scope is clearly bounded
|
|
- [x] Dependencies and assumptions identified
|
|
|
|
## Feature Readiness
|
|
|
|
- [x] All functional requirements have clear acceptance criteria
|
|
- [x] User scenarios cover primary flows
|
|
- [x] Feature meets measurable outcomes defined in Success Criteria
|
|
- [x] No implementation details leak into specification
|
|
|
|
## Notes
|
|
|
|
- Validation pass: Spec describes the single-run model, action taxonomy, and MSP safety expectations in testable terms.
|
|
- Implementation specifics (service names, job design, exact key registries) are intentionally omitted; they belong in the plan/tasks phase.
|