Characterize preservation of completed signer records
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start with tests/integration/features/sign/cancel.feature, signed.feature, and sequential_signing.feature; reuse the existing clickToSign fixtures and API assertions. Run the relevant Behat scenarios and inspect how they reload signer records and verify signing evidence. Done means focused regression coverage confirms completed records and evidence remain intact while legitimate unsigned-signer removal still works.
Written by the indexing model from the issue text.
Description
Goal
Add focused regression coverage confirming that completed signing records and their evidence are preserved throughout signer-management operations.
This is an investigation of an integrity invariant, not a claim that a defect has been confirmed. The backend remains responsible for enforcing valid state transitions regardless of frontend controls.
Starting points
tests/integration/features/sign/cancel.featuretests/integration/features/sign/signed.featuretests/integration/features/sign/sequential_signing.feature
Reuse existing clickToSign test fixtures and API assertions instead of introducing a new test framework.
Test approach
- Prepare a small document with real signers and complete at least one signature using the existing signing flow.
- Exercise the relevant signer-management behavior within the current lifecycle and permission rules, including a completed signing record and a partially signed document where applicable.
- Reload the document and signer records using the existing API or validation test facilities.
- Verify that completed signers, signing status, timestamps, and available signature evidence are preserved; remaining participants must not be unexpectedly changed.
- Use the existing successful removal of an unsigned signer as a control. Do not duplicate established happy-path scenarios without a demonstrated need.
Test observable business rules rather than mocking internal implementation details. Prefer Behat; use narrowly scoped PHPUnit integration only if a required persistence invariant cannot be checked through the API. Do not assume that editing a partially signed document is an allowed operation or introduce new permissions.
Expected outcome
- A signer who has already signed retains their completed signing record and evidence.
- Unsupported signer-management operations do not alter signed records or the document state.
- Existing legitimate management of unsigned requests continues to work.
Result and maintainer handoff
- Tests pass: submit focused regression coverage for normal review and merge.
- Test setup fails: correct the fixture or environment before classifying a product defect.
- A test confirms a product defect: preserve the failing test in a referenceable commit/branch, record the tested base revision and sanitized evidence, and request maintainer triage. Do not merge a failing test, disable it, or weaken assertions to make CI pass.
- Follow-up: the maintainer decides whether a small fix can accompany the preserved test or whether a separate correction issue is needed. The original regression test must be incorporated into the eventual correction.
If a finding may expose a security weakness, do not publish the sensitive reproduction, failing test branch, logs, or exploit details in a public issue or PR. Follow SECURITY.md for private triage before disclosure. This investigation does not automatically require a security advisory.
Scope and completion
No broad refactoring, new testing infrastructure, benchmarks, or mandatory product fix.
The investigation can conclude when the regression coverage passes and is merged or a reproducible defect is preserved for maintainer review with an agreed, traceable correction follow-up.
- Dominant language
- PHP
- Stars
- 828
- Forks
- 159
- Avg merge
- 7h 53m
- Merged PRs (30d)
- 523
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from LibreSign/libresign
-
Difficulty 1/5 Under an hour Newbie friendliness 83/100
LibreSign/libresign#9007 · 1 reaction ·
Maintainers usually reply within 1 day
-
backend enhancement php
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Validation page says "This document is valid" for a document with no signaturePossibly taken @maia-andre claimed this 8 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
LibreSign/libresign#8284 · 5 comments ·
Maintainers usually reply within 1 day
-
backend php
Difficulty 3/5 1-2 days Newbie friendliness 78/100
Maintainers usually reply within 1 day
All issues in LibreSign/libresign
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
WordPress/hosting-handbook#506 ·
Maintainers usually reply within 2 days
-
Installing a plugin with composer_packages installs dev dependencies and breaks the autoloader (Error 500)Possibly taken @Boy132 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
nginx: static-file locations drop the security headers, and the dotfile deny is matched after themOpenbug Low Security
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
backdrop-contrib/commerce#60 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100