Allow copying the signature link directly instead of only sending it by email (ver. 14.1.0)

[iodata-base]

Is your feature request related to a problem? Please describe.

When requesting a signature, LibreSign only offers to send the signature link by email. In several situations this is not practical:

• the signer is physically present, or I am already talking to them by phone, chat or instant messaging, and I would like to hand them the link right away;
• I want to forward the link myself, through the channel my client actually uses.

Describe the solution you'd like

In addition to the existing "send by email" action, add an option to generate and copy the signature link directly, for example a "Copy signature link" button next to each signer in the request screen and in the document's detail view. The link would be the same one that is currently embedded in the email, so the existing authentication rules (email token, etc.) would still apply.

Describe alternatives you've considered

• Sending the email to myself and then copying the link out of it — this works but is a clumsy workaround and depends on mail delivery working.
• Rebuilding the URL by hand from the document UUID — not realistic for everyday use.

Additional context

Most commercial e-signature services offer both options (send by email / copy link), and users have come to expect it. This would also make LibreSign usable on instances where email is not set up at all.

[vitormattos]

Thanks for the suggestion. The use case is valid, but we should not expose the current signing link directly without an additional identity verification step.

The signing link contains the UUID that gives access to the signing flow. If possession of this link is enough to sign, copying it would allow another person to sign on behalf of the intended signer.

LibreSign 15, planned for Nextcloud 35, already started moving toward a more flexible identification model with multiple identification methods and required/optional factors. We think this is the right foundation for supporting this feature safely.

Today, account and email identification are directly available in LibreSign. Additional methods such as SMS, WhatsApp, Signal, Telegram and XMPP can become available when the Two-Factor Gateway app is installed and a corresponding gateway is configured.

A possible flow would be:

• the requester configures one or more identification factors for the signer;
• if at least one verification factor is required, LibreSign can allow the requester to copy the signing link and send it through any channel;
• when the signer opens the link, LibreSign asks for the identifier associated with the configured factor, such as the registered email address or phone number;
• if the identifier is valid, LibreSign sends a verification token through that channel;
• the signer must provide the received token before continuing;
• when multiple factors are required by the policy, all required factors must be verified.

For example, the requester could copy the link and send it through any messaging application, while LibreSign independently requires verification using the signer's registered email and SMS number.

This keeps link delivery separate from signer identification.

The signing link should not be exposed when the configured flow does not provide an independent verification step. For example, a simple clickToSign request should continue to rely on LibreSign controlling how the privileged signing link is delivered.

This is therefore more than adding a "Copy link" button. It requires some refinement of the identification flow introduced for LibreSign 15, including consistent backend validation and tests.

Contributions are welcome. If someone needs this feature for a specific deployment or would like to fund its development, they can also contact the LibreSign team so we can evaluate the work and priority.