Repository navigation
Show visible signature information in signer validation details #8326
Description
Activity
- addedgood first issueGood for newcomersGood for newcomersfrontendFrontend workFrontend workjavascriptWork involving JavaScript codeWork involving JavaScript code
on Sep 9, 2026 vdriga85 commented
on Sep 9, 2026 ContributorMore actionsI'd like to work on this issue. I'll add the visible-signature field to the existing signer details and focused frontend tests, keeping the backend and validation logic unchanged. I'll be using AI assistance and will review and test the changes before submitting a PR
I’ve implemented the frontend part and the focused tests locally, but I ran into an issue while testing the real “Yes” case.
I created and signed a document with a visible signature field. The validation API returns the visible element at the document level, with signRequestId 1 and type signature.
However, the corresponding signer with the same signRequestId still has an empty visibleElements array.
Because #8326 uses signer.visibleElements to decide between Yes and No, the UI ends up showing “Visible signature: No” even though the signer actually has a visible signature.
I also checked the validation path. It looks like FileService::loadVisibleElements() populates the document-level visibleElements, while the signer-level array remains empty.
Since the issue specifically asks to keep this frontend-only and not add new matching logic, I stopped there instead of changing the backend.
What would you prefer me to do next? Should this be handled as a separate backend fix, should #8326 include that part too, or is there an existing path I’ve missed that should already populate signer.visibleElements?
Hi @vdriga85, thanks for finding this.
I checked the backend and confirmed your point.
FileListServicealready adds visible elements to each signer usingsignRequestId, but the validation flow does not do this. InFileServiceandEnvelopeAssembler, the elements are returned at document level, whilesigner.visibleElementsstays empty.I think it is better to fix this first in a separate backend PR.
The PR should:
- make
FileServicefillsigner.visibleElementsusing the same relation already used inFileListService; - do the same for signers inside envelope documents in
EnvelopeAssembler; - keep the current document-level
visibleElements; - reuse the existing
getVisibleElementsFromSigners()data, without adding a new query; - update unit tests and Behat tests for these API responses;
- update the OpenAPI schema or examples if they do not describe
signer.visibleElementscorrectly.
This PR should only fix the backend/API response. The UI change from #8326 can come after it.
This way,
SignerDetails.vuecan usesigner.visibleElementsdirectly, without adding extra matching logic in the frontend.- make
Hi @vitormattos, sounds good. I’ll handle the backend fix first as a separate PR, then continue with #8326.
Reacted by Vitor Mattos- moved this from 0. Backlog to 4. to release in LibreSign Roadmap
on Sep 11, 2026
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Start date
Target date
Projects
- StatusShow more project fieldsNo status
Context
Part of #8321.
A PDF digital signature can exist without a visible signature mark on the page.
LibreSign should make this clear also on the validation page.
This information should be shown as part of the signer details. It is metadata about how the signature is represented in the PDF, not a validation warning.
Expected behavior
In the signer details on the validation page, show whether that signer has a visible signature element.
Suggested field:
or:
Use the existing signer details layout.
Do not use a warning, error or success message for this information.
A signature without a visible element is still a valid digital signature.
Where to implement
The document validation flow already renders signer information through:
src/components/validation/SignerDetails.vueAdd the new field there with the other signer details.
Use the existing
NcListItempattern.Do not create a new validation section only for this value.
How to detect the value
The API already provides
visibleElementsin signer data.Do not add a new backend endpoint or a new database field.
Use the existing signer data:
The value can be decided as:
If there is at least one visible element:
If there are no visible elements:
Do not try to detect this by reading the PDF in the frontend.
Do not create new logic to match signers and elements when
visibleElementsis already available on the signer.Envelope validation
For envelopes, keep this information at document signer level.
A signer may have a visible signature in one document and no visible signature in another document.
Because of this, do not show one global
YesorNovalue in the consolidatedSigners summary.The value should describe the signer for the specific document being inspected.
Display rules
Show this information for signed signers.
It should appear with the existing signer metadata, such as:
The exact position should follow the current layout, but it should not be inside
Validation status, because having no visible signature is not a validation problem.Tests
Add or update the tests for
SignerDetails.vue.Cover at least:
Visible signature: Yes;Yes;visibleElementsarray showsNo;If there is already validation-page integration coverage for signer details, extend it with one focused case.
Do not create a complete new validation workflow only for this field.
Out of scope
This issue does not:
Good first issue
The API already provides the information needed for this change.
The main work is:
visibleElementsto the local signer type if needed;SignerDetails.vue;No backend change, new API or PDF parsing is needed.
Please reuse the existing validation components and keep the change focused.
Additional context
Done when
Visible signature: Yes/Nois shown in signer validation details.visibleElementssigner data.