Configurable signature rejection workflow

Currently, LibreSign allows a signer to digitally sign a document, but it is not possible to explicitly reject a signing request.

Many organizations require signers to be able to reject a signing request, optionally providing a justification, while allowing administrators to define how that rejection affects the signing workflow and which information becomes visible to other participants.

This issue proposes a configurable Signature Rejection Workflow that is disabled by default, preserving the current LibreSign behavior.

The initial implementation should use a global configuration. However, the architecture should be designed to allow future integration with Policies & Rules, enabling different organizations, groups or users to have different rejection behaviors.

[!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 needed

Signature rejection is important for organizations where signing is part of an approval, compliance or document workflow.

We are looking for organizations interested in funding this work and for contributors who want to help build it.

Organizations that need configurable rejection, audit, privacy or approval workflows are especially welcome to support this work.

Community contributions are also welcome through the focused child issues of this epic.

---

Goals

• Preserve current LibreSign behavior by default.
• Allow signers to explicitly reject a signing request.
• Allow administrators to define optional or mandatory rejection comments.
• Respect privacy and compliance requirements by allowing administrators to configure the visibility of rejection information.
• Keep the implementation compatible with future Policies & Rules.

---

Functional Requirements

FR1 - Enable Signature Rejection

A new global setting should enable or disable the Signature Rejection Workflow.

Default:

• Disabled

When disabled:

• LibreSign behaves exactly as today.
• Only the Sign button is displayed.
• No additional workflow is introduced.

When enabled:

Will display the follow options:

☑ Allow rejection comments

☑ Require rejection comments
☑ Allow who reject to make the comment private

☑ Cancel workflow after rejection

☑ Make public the rejection status at who rejected on validation page. If disabled, the validation page will be disabled.

☑ Show rejection comment on validation page

---

FR2 - Signing Experience

When the feature is enabled, the signing page should display two primary actions:

• Sign (success [button](https://nextcloud-vue-components.netlify.app/#/Components/NcButton))
• Reject (error [button](https://nextcloud-vue-components.netlify.app/#/Components/NcButton))

Both actions should have equal prominence.

---

FR3 - Reject Dialog

Clicking Reject must never immediately reject the signing request.

Instead, LibreSign should display a confirmation dialog.

Example:

Reject signing request

Are you sure you want to reject this signing request?

This action cannot be undone.

Reason:
____________________________
____________________________

[ ] Make my reason private. Only who requested to sign will see.

[ Cancel ]   [ Reject document ]

Buttons:

• Cancel (secondary [button](https://nextcloud-vue-components.netlify.app/#/Components/NcButton))
• Reject document (error [button](https://nextcloud-vue-components.netlify.app/#/Components/NcButton))

The rejection is only recorded after the signer explicitly confirms the action.

---

FR4.1 - Rejection Comment

Administrators should configure how rejection comments work.

Options:

• Disabled
• Optional
• Required

When enabled, the comment field should be displayed inside the rejection dialog.

If configured as required, rejection cannot proceed until the comment is provided.

---

FR4.2 - Allow signer to don't expose rejection comment

Administrators should configure if who reject the signature is able to choose if want to don't expose the rejection comment.

The signer will see a rejection field.

---

FR5 - Visibility Rules

Administrators should independently configure which rejection information becomes publicly visible.

Suggested options:

• Show rejection status.
• Show rejected signer.
• Show rejection comment.

Default behavior:

• None of this information is publicly visible.

This default favors privacy and compliance.

---

FR6 - Workflow After Rejection

Administrators should choose how the signing workflow behaves after a rejection.

Continue workflow

Remaining signers may continue signing.

This supports approval and voting scenarios where rejection is simply another possible outcome.

Cancel signing workflow

The signing workflow immediately stops.

Remaining signers can no longer sign the document.

The document itself continues to exist, but its signing workflow becomes closed.

---

FR7 - Pending Signers

If the signing workflow is cancelled:

Remaining signers should no longer be able to sign.

Instead of the signing interface, LibreSign should display the validation page with all signers and will see at the name of pending signers a friendly message such as:

John Doe: This signer is no longer allowed to sign.

A previous signer rejected the signature of this document and the rule of this document is to disable the pending signatures.

John Doe: the pending signer name.

The page should not expose rejection information unless administrator visibility settings explicitly allow it.

---

FR8 - Validation Page

The validation page should respect administrator visibility settings.

Depending on configuration, it may display:

• rejection status
• rejected signer
• rejection comment

By default, rejection information should not be publicly visible.

Users responsible for managing the signing request (the requester) should always have access to the complete rejection information.

---

FR9 - Administrative Interface

The document management interface should adapt to the workflow state.

When the workflow has been cancelled:

• reminder notifications should no longer be available (the admin don't will be able to send a reminder notification);
• actions that are no longer applicable should be disabled (as example: delete a signer);
• the interface should clearly indicate that the signing workflow has been closed.

If the workflow continues after rejection:

• rejection status should be visible;
• requesters should be able to inspect rejection details at validation page.

---

FR10 - Workflow Status

The signing workflow should have explicit states representing rejection.

Examples:

• Pending
• Signed
• Rejected
• Cancelled

These states should be consistently reflected across:

• backend
• frontend
• API
• validation page

---

FR11 - Audit Trail

Every rejection must be permanently recorded.

Suggested information:

• signer
• timestamp
• rejection comment

This information should remain available for auditing purposes.

---

FR12 - Activity Events

Rejecting a signing request should generate Activity events.

Activity:

• Signing request rejected.

Message to send:

• The signing request was canceled.

These events should follow the same Activity infrastructure already used by LibreSign.

---

FR13 - Internal Events

Rejecting a signing request should dispatch LibreSign events.

These events will allow future integrations, automation and possible webhook implementations without changing the rejection workflow.

---

FR14 - API

The API should expose rejection information.

Suggested information:

• workflow status
• rejection timestamp
• rejected signer
• rejection comment (respecting visibility rules)

The implementation details of the API are intentionally left open and may use dedicated endpoints or extend existing ones.

---

User Experience

Feature disabled

Signer sees:

• Sign

Current LibreSign behavior.

---

Feature enabled

Signer sees:

• Sign
• Reject

Clicking Reject opens the rejection dialog.

If configured, the dialog also displays the rejection comment field.

Only after explicit confirmation is the rejection permanently recorded.

---

Future Integration

The first implementation uses a global configuration.

Future versions should allow these settings to be managed through Policies & Rules, enabling different organizations, departments or groups to define their own rejection workflow independently.

The implementation should avoid architectural decisions that would make this migration difficult.

---

Out of Scope

This issue does not include:

• undoing a rejection;
• allowing a rejected signer to sign later;
• editing rejection comments;
• Policy-based configuration (future work).

This epic is not intended for direct implementation; begin with its focused child issues, which are not identified in the payload. Use the functional requirements as the acceptance scope: configurable rejection, workflow states, visibility, audit and activity handling should be covered across the backend, frontend, API and validation page.