Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Characterize signer removal consistency across envelope documents

Open
  • Is something wrong?
#9,085 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php
Domain
backend, testing

Research direction

Start with tests/integration/features/sign/cancel.feature, then read the envelope fixtures and validation steps in file/envelope.feature and file/validate.feature. Add Behat coverage for removing one of two pending signers and for removing the only pending signer from a two-document envelope, checking participant identity and resulting child states. Done means both cases verify consistent envelope and child associations with no orphaned signing requests.

Written by the indexing model from the issue text.

Description

backend php

Goal

Verify that removing a pending signer from an envelope consistently updates the envelope and all associated child documents.

Test approach

Extend tests/integration/features/sign/cancel.feature, reusing the envelope fixtures and validation steps already available in file/envelope.feature and file/validate.feature.

Multiple participants
  1. Create an envelope with two PDF documents and pending signers A and B.
  2. Retrieve the envelope and verify the participants associated with each child.
  3. Remove A using the authorized management operation.
  4. Reload the envelope and its children.
  5. Verify A is absent everywhere and B remains associated with both documents.

Assert participant identity instead of relying solely on array positions.

Last pending participant
  1. Create another two-document envelope with only signer A.
  2. Remove A.
  3. Reload the envelope and both children.
  4. Verify that no orphaned signing requests remain and that their resulting states are consistent with the existing workflow rules.

Boundaries

  • Prefer Behat exclusively.
  • Use only two documents.
  • Do not add benchmarks, stress tests or new reusable test frameworks.
  • Do not introduce transaction or cache refactors without a demonstrated failure.
  • Do not expand this issue into partially signed envelope scenarios requiring artificial failures.

Result and handoff

If the tests pass, submit regression coverage for normal review.

If they reveal inconsistent or orphaned associations, preserve the failing test commit, capture the before-and-after state and request maintainer review.

Do not merge failing tests. A product correction is a subsequent decision, and the reproduced test must be incorporated into the eventual fix.

Dominant language
PHP
Stars
830
Forks
161
Avg merge
7h 3m
Merged PRs (30d)
494

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LibreSign/libresign

All issues in LibreSign/libresign

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.