Skip to content

Show visible signature information in signer validation details #8326

Description

@vitormattos

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:

Visible signature: Yes

or:

Visible signature: No

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.vue

Add the new field there with the other signer details.

Use the existing NcListItem pattern.

Do not create a new validation section only for this value.

How to detect the value

The API already provides visibleElements in signer data.

Do not add a new backend endpoint or a new database field.

Use the existing signer data:

signer.visibleElements

The value can be decided as:

Array.isArray(signer.visibleElements) && signer.visibleElements.length > 0

If there is at least one visible element:

Visible signature: Yes

If there are no visible elements:

Visible signature: No

Do not try to detect this by reading the PDF in the frontend.

Do not create new logic to match signers and elements when visibleElements is 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 Yes or No value in the consolidated Signers 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:

  • date signed;
  • validation status;
  • hash algorithm;
  • remote address;
  • user agent.

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:

  • signer with one visible element shows Visible signature: Yes;
  • signer with several visible elements shows Yes;
  • signer with an empty visibleElements array shows No;
  • signer without visible elements does not show any warning or validation error;
  • existing validation information still renders normally.

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:

  • add visibleElements to the local signer type if needed;
  • show one new field in SignerDetails.vue;
  • add focused frontend tests.

No backend change, new API or PDF parsing is needed.

Please reuse the existing validation components and keep the change focused.

Additional context

  • If you have questions, feel free to ask in this issue.
  • Give a ⭐️ star to this repository if you find LibreSign useful and would like to support the project.
  • You can also join our community: https://t.me/LibreSign

Done when

  • Visible signature: Yes/No is shown in signer validation details.
  • The value comes from the existing visibleElements signer data.
  • No backend change is added.
  • Missing visible elements are not shown as a validation problem.
  • Envelope validation keeps the value at document signer level.
  • Frontend tests cover visible and non-visible signatures.

Activity

  1. vdriga85 commented on Sep 9, 2026

    @vdriga85
    Contributor

    I'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

  2. vdriga85 commented on Sep 10, 2026

    @vdriga85
    Contributor

    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?

  3. vitormattos commented on Sep 10, 2026

    @vitormattos
    MemberAuthor

    Hi @vdriga85, thanks for finding this.

    I checked the backend and confirmed your point.

    FileListService already adds visible elements to each signer using signRequestId, but the validation flow does not do this. In FileService and EnvelopeAssembler, the elements are returned at document level, while signer.visibleElements stays empty.

    I think it is better to fix this first in a separate backend PR.

    The PR should:

    • make FileService fill signer.visibleElements using the same relation already used in FileListService;
    • 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.visibleElements correctly.

    This PR should only fix the backend/API response. The UI change from #8326 can come after it.

    This way, SignerDetails.vue can use signer.visibleElements directly, without adding extra matching logic in the frontend.

  4. vdriga85 commented on Sep 10, 2026

    @vdriga85
    Contributor

    Hi @vitormattos, sounds good. I’ll handle the backend fix first as a separate PR, then continue with #8326.

  5. moved this from 0. Backlog to 4. to release in LibreSign Roadmapon Sep 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Fields

    Priority

    Low

    Start date

    None yet

    Target date

    None yet

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions