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

Clarify PDF signatures without visible signature fields

Aperta
#8,321 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à
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript, php, playwright

Direzione di ricerca

Questo è un epic di monitoraggio, non una issue di implementazione autonoma. Inizia esaminando le child issue mirate relative agli avvisi per i richiedenti, al backend e alla UI delle preferenze utente e alle informazioni sul firmatario; usa NcDialog esistente e il modello di campi condiviso in #8264, come indicato. Implementa solo una child issue mirata ed esegui i test Playwright o gli unit test del backend specificati; il completamento richiede che tutte le child issue e i workflow elencati siano coperti.

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

Descrizione

Clarify PDF signatures without visible signature fields

A visible signature is optional in a PDF digital signature.

A PDF can be digitally signed without showing a signature mark on the page. The digital signature is still stored in the PDF and can be validated.

This is standard PDF behavior, not a special LibreSign feature.

However, LibreSign does not explain this clearly enough. This has caused repeated confusion for both requesters and signers.

This epic replaces the related discussions from #7710 and #8320.

[!NOTE]

This epic defines the goal, architecture and scope.
Pull requests should implement focused child issues, not the epic itself.

[!IMPORTANT]

Funding and community support

This work affects the request flow, signer flow, user preferences, backend persistence and automated tests.

Organizations that depend on this workflow and want to help prioritize its implementation are welcome to support the development.

Community contributions are also welcome. Please work on the focused implementation issues instead of trying to complete the full epic in one pull request.

Goal

LibreSign must keep visible signature fields optional while making the behavior clear in the interface.

The UI should clearly separate:

  • the digital signature stored in the PDF;
  • the optional visible representation shown on a page.

A document without visible signature fields must remain valid and signable.

Requester flow

When preparing a signature request, the interface must not suggest that a visible signature field is required.

The requester may:

  1. add one or more signers;
  2. optionally open Setup signature positions;
  3. optionally add visible signature fields;
  4. continue with Request signatures.

Before sending, LibreSign must check the visible fields assigned to each signer.

If all signers have visible fields, keep the normal confirmation flow.

If one or more signers have no visible signature field, reuse the existing request confirmation NcDialog and show the warning there.

Do not add another confirmation dialog.

Suggested content:

Some signers have no visible signature field

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

These signers will still add a digital signature that can be validated, but no visible signature mark will be shown for them.

When possible, list only the affected signers.

For example:

No visible signature:

  • Bob
  • Carol

Actions:

  • Cancel
  • Send

The same rule must apply to the single-signer Request signature action. In that flow, only the selected signer must be checked.

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

Warning preference

The warning dialog may include this optional 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 by default.

The preference must only control whether this warning is shown. It must not change:

  • visible fields;
  • signature positions;
  • the request itself;
  • signing behavior.

Save the preference only when the requester confirms the request with Send.

If the requester closes the dialog or clicks Cancel, do not save it.

User preference storage

The preference must be stored on the server for the current authenticated user.

The default behavior is to show the warning.

This is a user interface preference, not a system policy.

The backend must support:

  • reading the current value;
  • updating it;
  • restoring the default value.

The preference must not be stored only in the browser because the same user may use LibreSign from different browsers or devices.

LibreSign preferences

The user must be able to enable the warning again from LibreSign preferences.

Suggested setting:

Warn me when requesting signatures without visible fields

Show a warning when one or more signers will sign without a visible signature on the PDF.

Default: enabled.

If the user previously selected Do not warn me again when signers have no visible signature field, this setting is disabled.

Enabling it restores the warning for future requests.

Signer flow

When a signer opens a request and no visible signature field is assigned to them, show a short informational message.

Suggested content:

No visible signature is required

Your digital signature will still be added to the PDF and can be validated after signing.

This message must:

  • be informational only;
  • not require confirmation;
  • not block signing;
  • not suggest that the signature is weaker, incomplete or invalid.

The normal Sign document action must remain available.

Mixed requests

Visible fields must be evaluated per signer, not only per document.

For example:

  • Alice has one visible field;
  • Bob has no visible field;
  • Carol has two visible fields.

Only Bob should be reported in the requester warning, and each signer should receive the correct signing experience based on their own fields.

Do not rely only on a document-level hasVisibleFields state.

Implementation

This is a tracking epic.

Do not implement the complete work in one pull request.

Create focused issues for:

1. Requester warning

Frontend work for:

  • the existing request confirmation NcDialog;
  • per-signer field checks;
  • full-request flow;
  • single-signer request flow;
  • mixed requests;
  • warning checkbox;
  • Playwright coverage.
2. User preference backend

Backend work for:

  • storing the preference per user;
  • reading and updating it;
  • restoring the default;
  • unit tests.
3. LibreSign preferences UI

Frontend work for:

  • showing the preference;
  • allowing the user to enable the warning again;
  • automated tests.
4. Signer information

Frontend work for:

  • showing the informational message when no visible field is assigned;
  • keeping the normal signing flow unchanged;
  • automated tests.

Testing

The complete work must cover:

  • all signers have visible fields;
  • no signer has a visible field;
  • mixed requests;
  • single-signer request;
  • warning shown by default;
  • warning preference saved only after Send;
  • canceling does not save the preference;
  • warning hidden on the next request for the same user;
  • warning still shown for another user;
  • warning enabled again from LibreSign preferences;
  • signer flow with and without visible fields.

Use Playwright for end-to-end workflow behavior.

Add backend unit tests for user preference persistence and isolation between users.

Out of scope

This epic does not:

  • require visible signature fields;
  • change PDF digital signature behavior;
  • automatically create visible fields or positions;
  • change signature validation rules;
  • add a new system policy;
  • change the validation page unless a separate validation-specific problem is identified.

Related work

The implementation should remain compatible with the shared field model tracked in #8264.

Done when

This epic is complete when all focused implementation issues are finished and the complete behavior is covered by automated tests.

Lingua principale
PHP
Stelle
818
Fork
146
Merge medio
8h 6m
PR unite (30g)
500

Preparare l'ambiente

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 LibreSign/libresign

Tutte le issue di LibreSign/libresign

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.