Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#7,870 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
backend, devtools

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Java
Stars
278
Forks
97
Avg merge
18h 53m
Merged PRs (30d)
228

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-dirigible/dirigible

All issues in eclipse-dirigible/dirigible

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.