fix(Sign): submit each envelope file independently with its UUID#7446
Merged
vitormattos merged 17 commits intomainfrom Apr 7, 2026
Merged
fix(Sign): submit each envelope file independently with its UUID#7446vitormattos merged 17 commits intomainfrom
vitormattos merged 17 commits intomainfrom
Conversation
Covers issue #7344 phase 2: when an envelope has multiple child files each with a me=true signer and a distinct sign_request_uuid, the submitSignature method should call signStore.submitSignature once per file with only the elements belonging to that file and the correct UUID. Four cases are covered: - per-file calls with visible elements (canCreateSignature=false) - per-file calls with no visible elements (click-to-sign envelope) - single-file documents remain unaffected (non-envelope baseline) - per-file calls with profileNodeId when canCreateSignature=true Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
When signing an envelope document that has multiple child PDFs, the current submitSignature sends every visible element to a single sign_request_uuid (the first me=true signer's). The backend rejects it with HTTP 422 because elements belonging to file 2 are sent under file 1's sign_request context. Fix: before submitting, collect all me=true signers that have a sign_request_uuid. If the document is an envelope and more than one signer is found, iterate them and make one signStore.submitSignature call per signer, filtering elements by signRequestId so each call only carries the elements that belong to that specific file. The fallback (no matched envelope signers, or non-envelope documents) preserves the existing single-file code path unchanged. Both the Composition API let submitSignature and the backward-compat Options API shim in defineOptions.methods are updated. Closes: #7344 (phase 2) Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
vitormattos
changed the title
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
…ents Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Member
Author
|
/backport to stable33 |
Member
Author
|
/backport to stable32 |
github-project-automation
Bot
moved this from 0. Needs triage
to 4. to release
in Roadmap
This was referenced Apr 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When signing an envelope document with multiple child PDFs,
submitSignaturewas sending all visible elements (from all child files) to a singlesign_request_uuid— the first signer's UUID fromArray.find(). The backend'svalidateSignerIsOwnerOfPdfVisibleElementcorrectly rejected elements from file 2 when called under file 1's sign request → HTTP 422.Root Cause
signRequestUuidcomputed callsgetSigningRouteUuid(document, fallback)which usesArray.find()and returns only the firstme=truesigner's UUID. An envelope with 2 child PDFs has twome=truesigners, each with a distinctsign_request_uuid.Fix
Before submitting, collect all
me=truesigners that have asign_request_uuid. If the document is an envelope with matched signers, iterate and make onesignStore.submitSignaturecall per file, filteringelementsbysignRequestIdso each call only carries the elements belonging to that specific file.Non-envelope documents (or envelopes where no matched signers are found) fall through to the unchanged single-file path.
Both the Composition API
let submitSignaturefunction and the backward-compat Options API shim indefineOptions.methodsare updated.Tests
Four regression tests added:
canCreateSignature=false)profileNodeIdwhencanCreateSignature=true