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

intent: a process status setter overwrites a roll-up-owned status - a PAID invoice goes back to SENT when its Send task completes after the payment

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
backend, databases

Research direction

Start with the generated setter template at components/template/template-application-events-java/.../events/SetField.java.template and the roll-up ownership logic in components/ide/ide-template/.../model/RollupAggregates.java. Trace how DisplacedStatus and owned statuses are handled, then inspect the declarative transitions: runner and updateProperty transition actions mentioned in the issue. Done means setters preserve roll-up-owned Status while recording the intended lifecycle status, which is restored when the roll-up relinquishes ownership.

Written by the indexing model from the issue text.

Description

What happens

A process status setter generated from SetField.java.template (<Process>MarkSent, MarkIssued, MailSent, Confirmed, ... - every ${JavaTask} that sets the lifecycle Status) writes its target status with a targeted single-column updateProperty(id, "Status", n), unconditionally. When the entity's status is at that moment owned by a roll-up (statusWhenFull / statusWhenPartial, the PARTIAL/PAID of a settled document), the setter overwrites it, and nothing ever restores it: the roll-up listener (RollupAggregates) re-asserts PARTIAL/PAID only when the summed amount changes.

Reproduced on a production tenant (BusinessIntents Suite, platform 14.76.0, base-sales-invoices):

2026-09-11 11:49Z  CustomerPayment 3 (4 800.00) allocated to SalesInvoice 16 (Payable 4 800.00)
                   -> roll-up invoicePaid: Paid 4800, Balance 0, Status 7 (PAID)
2026-10-05 12:34:36Z  the "Send" user task of SalesInvoiceApproval instance 2501 is completed (action markAsSent)
                   process variables snapshotted at that moment: Status=PAID, Paid=4800, Balance=0
2026-10-05 12:34Z  SalesInvoiceApprovalMailSent (SetField): updateProperty(16, "Status", 4)   -> SENT
2026-10-05 12:35Z  the async mailInvoice job fails (SMTP) and dead-letters; the process is stuck before Confirm
2026-10-16           the invoice still reads Status SENT, Paid 4 800.00, Balance 0.00, DisplacedStatus null

The generated listener's own relinquish logic (#7022) would have done the right thing had the roles been reversed: when the sum goes back to zero it restores DisplacedStatus. The process side has no such awareness.

What should happen

A lifecycle setter must not take a status the roll-up holds. When the current Status is one of the entity's roll-up-owned statuses (statusWhenFull / statusWhenPartial of any roll-up on it):

  • write the setter's value into DisplacedStatus instead of Status (the status the document would hold if it were not settled), publish the transition as today;
  • leave Status to the roll-up, which restores DisplacedStatus when the sum returns to zero (#7022) - so "payment deleted" then yields SENT/CONFIRMED, not ISSUED.

The same guard belongs in the declarative transitions: runner and in updateProperty-based transition actions, since any of them can run after the money arrived. For bank-transfer customers "Send/Confirm completed after the payment is in" is the normal order, not an edge case.

Where

  • components/template/template-application-events-java/.../events/SetField.java.template (the generated <Process><Step> setters)
  • components/ide/ide-template/.../model/RollupAggregates.java (the roll-up side: owns DisplacedStatus, knows the owned statuses)

Found while investigating BusinessIntents/base-sales-invoices (prod invoice 16); the AP twin is BusinessIntents/base-purchase-invoices.

Dominant language
Java
Stars
278
Forks
97
Avg merge
19h 30m
Merged PRs (30d)
242

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.