Warn requesters when signers have no visible signature field #8323

Context

Part of #8321.

A PDF can be digitally signed without showing a signature on the page.

A visible signature field is optional.

LibreSign already supports this behavior, but the current request flow does not explain it. A requester may think that a visible signature field is required.

LibreSign should explain this before sending the request.

Current flow

LibreSign already shows a confirmation dialog after the requester clicks Request signatures.

The current dialog shows:

Confirm

Send signature request?

Actions:

• Cancel
• Send

This issue must extend this existing dialog.

Do not add another modal or another confirmation step.

Expected behavior

Before showing the confirmation, LibreSign must identify which signing participants have no visible signature field.

If every signing participant has at least one visible signature field, keep the current confirmation unchanged.

If one or more signing participants have no visible signature field, show extra information inside the same Confirm dialog.

Normal confirmation

When all signing participants have visible signature fields, keep:

Confirm

Send signature request?

Actions:

• Cancel
• Send

Do not show any extra visible-signature information.

Confirmation with missing visible signatures

When one or more signing participants have no visible signature field, keep the same dialog title and main question:

Confirm

Send signature request?

Then show:

Some signers have no visible signature field.

A PDF can be digitally signed without showing a signature on the page. Their digital signatures will still be added to the PDF and can be validated.

List only the affected signers.

For example:

No visible signature:

• Bob
• Carol

Keep the same actions:

• Cancel
• Send

The request must never be blocked only because a visible signature field is missing.

How to detect affected signers

RequestSignatureTab.vue already imports:

getVisibleElementsFromDocument

from:

src/services/visibleElementsService.ts

Reuse this existing service.

Do not create a new visible-element parser.

The signer data already contains signRequestId.

A signer has a visible signature field when there is at least one visible element where:

• element.signRequestId matches the signer signRequestId;
• element.type === 'signature'.

Do not use signer name or email for this match.

Do not count other visible field types as a visible signature.

For example, a signer with a text or date field but no signature field must still be treated as having no visible signature field.

Reusable helper

Prefer adding a small reusable helper to:

src/services/visibleElementsService.ts

Suggested responsibility:

getSignersWithoutVisibleSignatureElements(document, signers)

The helper should:

1. get visible elements with getVisibleElementsFromDocument(document);
2. keep only elements with type === 'signature';
3. match them to signers by signRequestId;
4. return only signers without a matching visible signature element.

Use the same helper for both request flows.

Do not duplicate this filtering logic inside different methods of RequestSignatureTab.vue.

Signing participants only

Only participants with the signer role must be checked.

Observers do not sign the document, so they do not need a visible signature field.

Do not include observers when:

• checking for missing visible signature fields;
• deciding whether the warning should be shown;
• listing affected participants in the confirmation dialog.

RequestSignatureTab.vue already separates:

• signingParticipants;
• observerParticipants.

Reuse signingParticipants for this check.

Full request

For Request signatures, run the check for all signing participants that will receive a signature request.

Example:

• Alice has one visible signature field;
• Bob has no visible signature field;
• Carol has two visible signature fields;
• Dave is an observer.

Only Bob must appear in the warning.

Dave must not be checked because observers do not sign the document.

Individual request

LibreSign also has an individual Request signature action.

This flow already uses its own confirmation dialog.

Reuse the same affected-signer helper with only the selected signer.

If the selected signer has a visible signature field, keep the current confirmation unchanged.

If not, show the same explanation in the existing dialog.

Do not add another modal.

Dialog implementation

The current dialogs use:

confirmSendSignatureRequestMessage

with the message property of NcDialog.

This is enough for the current simple text, but the new content needs:

• the normal confirmation text;
• the explanation;
• a signer list;
• a checkbox;
• helper text.

Use the normal content area of the existing NcDialog instead of trying to put all content inside the message property.

Keep:

• dialog title Confirm;
• Cancel action;
• Send action;
• current loading behavior.

Do not create a new dialog component.

User preference

The backend preference from #8322 is already implemented.

RequestSignatureTab.vue already uses:

useUserConfigStore()

The existing store provides the current user configuration and an update(key, value) method.

Reuse it.

Do not create another API client, store or composable.

The preference key is:

warn_without_visible_signature_fields

If the value is false, keep the normal confirmation dialog and do not show:

• the extra explanation;
• the affected signer list;
• the checkbox.

Do not warn again

When the warning is visible, show an unchecked checkbox:

Do not warn me again when signers have no visible signature field

Below it, show:

You can enable this warning again in LibreSign preferences.

The checkbox must be unchecked every time the dialog opens.

Use local state for the checkbox.

For example:

const disableMissingVisibleSignatureWarning = ref(false)

Do not save anything when the checkbox is selected.

Save the preference only when the requester clicks Send.

If selected, use the existing user config store to save:

await userConfigStore.update(
	'warn_without_visible_signature_fields',
	false,
)

Cancel and close behavior

If the requester:

• clicks Cancel;
• closes the dialog;
• leaves without sending;

do not save the preference.

Reset the local checkbox state when the dialog closes.

The next time the warning opens, the checkbox must be unchecked again.

Save timing

The preference should only be changed as part of the confirmed Send action.

Do not save it before the requester confirms the request.

Do not save it from the checkbox change event.

Keep the existing request submission behavior unchanged.

Preferences screen

The Preferences UI from #8324 is already implemented.

The user can enable the warning again there.

This issue must only consume and update the existing preference.

Do not add Preferences UI here.

Important rules

This feature only changes the information shown in the existing request confirmation.

It must not:

• require a visible signature field;
• create a visible signature field;
• create a signature position;
• change signer data;
• change the request payload because a field is missing;
• change signing behavior;
• add another confirmation step;
• treat observers as signers.

A request without visible signature fields must remain valid and sendable.

Frontend tests

Update:

src/tests/components/RightSidebar/RequestSignatureTab.spec.ts

Cover at least:

• all signing participants have visible signature fields;
• no signing participant has a visible signature field;
• mixed signers;
• only affected signers are returned;
• observers are ignored;
• a request with only signers covered and one observer does not show the warning because of the observer;
• a text or date field does not count as a signature field;
• individual request with a visible signature field;
• individual request without a visible signature field;
• warning hidden when the preference is disabled;
• checkbox unchecked by default;
• Cancel does not save the preference;
• closing the dialog does not save the preference;
• Send saves the preference when the checkbox is selected.

If a helper is added to visibleElementsService.ts, add focused unit tests for it in:

src/tests/services/visibleElementsService.spec.ts

Use table-driven cases if it keeps the signer and element combinations clear.

Playwright

Add or update Playwright coverage for the real requester flow.

Cover at least:

All signers have visible signatures

• open Request signatures;
• current confirmation appears;
• no extra warning is shown;
• request can be sent.

Signer without visible signature

• open Request signatures;
• warning appears;
• only the affected signer is listed;
• request can still be sent.

Mixed signers

• some signers have visible signature fields;
• some do not;
• only affected signers are listed.

Observer

• include an observer in the request;
• the observer is not checked for a visible signature;
• the observer does not appear in the warning.

Individual request

• use Request signature for one signer;
• only that signer is checked.

Do not warn again

• warning appears;
• checkbox starts unchecked;
• select it;
• click Send;
• open another affected request;
• warning is not shown.

Cancel

• select the checkbox;
• click Cancel;
• open the confirmation again;
• warning is still shown.

Close

• select the checkbox;
• close the dialog;
• open it again;
• warning is still shown.

Reuse existing requester Playwright helpers and flows where possible.

Do not build a separate complete request workflow only for this feature.

Out of scope

This issue does not implement:

• backend preference storage from Add user preference for the missing visible signature warning #8322;
• the Preferences UI from Add the visible signature warning option to user preferences #8324;
• signer-side information from Explain when a signer has no visible signature field #8325;
• validation-page information;
• new PDF validation rules;
• observer behavior.

Good first issue

The main architecture already exists.

The contributor does not need to design a new request flow.

The implementation should reuse:

• RequestSignatureTab.vue;
• the existing NcDialog;
• getVisibleElementsFromDocument();
• visibleElementsService.ts;
• signer signRequestId;
• signingParticipants;
• useUserConfigStore();
• the existing user config API;
• current component tests;
• current Playwright request flows.

The main work is:

• add one reusable helper for affected signers;
• extend the existing confirmation content;
• connect one existing user preference;
• ignore observers;
• add focused tests.

Do not create new backend endpoints, stores, dialogs or visible-element parsing.

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

• The existing Confirm dialog is reused.
• No second modal is added.
• Send signature request? remains the main confirmation.
• Only signature visible elements count.
• Matching uses signRequestId.
• Only signing participants are checked.
• Observers are ignored.
• Full and individual request flows use the same detection logic.
• Only affected signers are listed.
• Missing visible signatures never block the request.
• The saved user preference is respected.
• The checkbox is unchecked by default.
• The preference is saved only after Send.
• Cancel and dialog close do not save the preference.
• Component and service tests cover the logic.
• Playwright covers the main end-to-end flows.