Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

admin: a supervised data-correction surface (recompute, audited override of a system-owned field, process repair) - today a platform-caused wrong status can only be fixed in the database

Aperta
  • Qualcosa non va?
#7,870 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend, devtools

Direzione di ricerca

Start by tracing the generated controller’s immutableWhen and applyWorkflowStatus behavior, then inspect Repository.recalculate(id), the roll-up listeners, and the monitoring shell’s process controls. The issue also points to BusinessIntents/base-sales-invoices#209 for the status-disagreement query and activity stream #7472 for audit history. Done means delivering the role-gated, audited correction surface and health view described in the four requirements.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

When the platform itself leaves a record wrong, an administrator has no way to put it right short of the database. Concrete case (#7869): a PAID sales invoice was flipped back to SENT by a process status setter; Paid 4 800.00, Balance 0.00, Status SENT. Every surface the tenant has refuses the correction:

  • the generated REST/UI lock the record from APPROVED onward (immutableWhen -> 409 This SalesInvoice is immutable in its current status - corrections go through the workflow), for every role, ADMINISTRATOR included - there is no override;
  • Status is process-owned (function: EntityStatus): the form renders it read-only and a user PUT keeps whatever the workflow set (applyWorkflowStatus);
  • DisplacedStatus is hidden (isHiddenProperty, #7022) and preserved over every user write;
  • the roll-up that owns PARTIAL/PAID re-asserts its status only when its sum changes; Repository.recalculate(id) exists but has no endpoint and no button;
  • the admin shell (resources-admin) is Settings only (tenant configuration, region/language, users); the monitoring shell can retry/skip a stuck process step and run jobs, but touches no entity data.

"Corrections go through the workflow" is the right default for users. It is the wrong answer when the defect is the platform's: the workflow has no step that re-derives a status, and the tenant administrator ends up asking for SQL against production.

Ask

A supervised data-correction surface for ADMINISTRATOR / OPERATOR, generic (no intent change per module), served in the platform shells (admin shell + the generated Settings), not only the IDE:

  1. Recompute a record: re-run its aggregates and every roll-up it is the parent of (recalculate + the roll-up listeners' logic in one call), restoring a roll-up-owned status and DisplacedStatus from the actual rows. Idempotent, safe, no reason needed. Endpoint on the generated controller, e.g. POST .../<Entity>Controller/{id}/recompute.
  2. Override a system-owned field (Status, DisplacedStatus, a stamped number, a roll-up column) with a mandatory reason: bypasses immutableWhen and the preserved-on-update set for that one targeted write, still runs the declared checks and the roll-up invariants (PAID only if Paid >= Payable), publishes the transition like a workflow step would, and is recorded (who, when, field, old -> new, reason) - the activity stream (#7472) is the natural ledger.
  3. Process repair next to the record, not only in monitoring: retry/skip the stuck step (exists in monitoring today), cancel the instance, restart the flow from the record's current status.
  4. One admin page listing every record whose roll-up-owned status disagrees with its rows (the SELECT from BusinessIntents/base-sales-invoices#209 as a health view), so the administrator finds the damage without a DB client.

Scope note: this is not a request to loosen immutability for users; it is a role-gated, audited repair path that replaces the DB shell.

Lingua principale
Java
Stelle
278
Fork
97
Merge medio
19h 30m
PR unite (30g)
242

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-dirigible/dirigible

Tutte le issue di eclipse-dirigible/dirigible

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.