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

WorkflowHandler.deleteCandidateUser passes a plain user name so it never removes a Flowable candidate link

Aperta
  • Qualcosa non va?
#35,993 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à
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend

Direzione di ricerca

Start in governance/workflows/WorkflowHandler.java at updateFlowableVoteTracking around line 1373 and trace how candidate identifiers are built in SetCandidateUsersImpl and MessageParser.EntityLink.getLinkString. Check the existing SetApprovalAssigneesImplTest for the expected stored format, then add a unit test for the identifier passed to deleteCandidateUser or an integration test that checks identity links after a non-final vote. Done means the voted user's candidate link is removed, or the pruning call and its related unclaim branch are removed.

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

Descrizione

Problem

WorkflowHandler.updateFlowableVoteTracking (governance/workflows/WorkflowHandler.java, around line 1373) calls

taskService.deleteCandidateUser(flowableTask.getId(), currentUser);

with currentUser as the plain principal name (alice). Flowable candidate identity links for approval tasks are added by SetCandidateUsersImpl from the <node>.assignees variable, whose entries are entity links such as <#E::user::alice> (built by MessageParser.EntityLink.getLinkString). Flowable's DeleteIdentityLinkCmd matches userId exactly, so the delete never matches a row. The call is a silent no-op; the surrounding catch logs at debug only. The unclaim just above it never fires either, because nothing sets a Flowable assignee on these tasks.

Evidence: a throwaway integration test on main with approvalThreshold 2 dumped the Flowable identity links of the review task after a vote. The voter's candidate link is still present after their vote was counted:

after-r1-approve flowable | vars={approvalThreshold=2, approversList=[..._r1], votedUsers=[..._r1], ...}
                            identityLinks=[candidate/user:<#E::user::..._r2>, candidate/user:<#E::user::..._r1>]

Nothing in OpenMetadata reads Flowable candidates to decide who may vote (that check uses task.assignees in the entity store), so voting is unaffected. The effect is dead code that claims to prune the Flowable candidate list and does not, and a Flowable task whose candidate list no longer matches the entity's assignees. CreateTask.getAssignees falls back to delegateTask.getCandidates() when the assignees variable is missing, so that fallback would also see voters who already voted.

What we want

Either pass the candidate's stored identifier, new MessageParser.EntityLink("user", FullyQualifiedName.quoteName(userFqn)).getLinkString(), to deleteCandidateUser, or delete the call and the unclaim branch and leave the assignee pruning to removeTaskFromVoterFeedForTaskEntity, which is the code that has the real effect. Switching the stored candidate format to plain names is not an option: CreateTask.getAssignees parses the link form and SetApprovalAssigneesImplTest asserts it.

Done when
  • After a non-final vote on a multi-approval task, the voter's candidate identity link is gone from ACT_RU_IDENTITYLINK (or the pruning call is removed and no code claims to do it).
  • A unit test on updateFlowableVoteTracking asserts the identifier handed to deleteCandidateUser, or an integration test reads the identity links after a vote.

Found while building #35983 (ontology release review rules), which does not change this code.

Lingua principale
TypeScript
Stelle
15.4k
Fork
2.4k
Merge medio
1g 4h
PR unite (30g)
707

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 open-metadata/OpenMetadata

Tutte le issue di open-metadata/OpenMetadata

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.