Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#7,869 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
backend, databases

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
278
Forks
97
Merge medio
19 h 30 min
PR fusionados (30 d)
242

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-dirigible/dirigible

Todos los issues de eclipse-dirigible/dirigible

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.