LibreSign/libresign

The screenshot used to show the LibreSign request signature interface is currently updated manually. We should automate its generation, so developers can recreate it with a single command when the interface changes. The generated screenshot must replace: img/screenshot/request-signature.png A similar approach is already used by profile_fields, where a script from package.json runs a Playwright script responsible for preparing the page and generating screenshots. What should be done Add a script to package.json to generate the request signature screenshot. For example: "screenshots:refresh": "node playwright/generate-screenshots.mjs" The exact script and file names can be adjusted to fit the LibreSign structure. The Playwright script should: log in using the existing Playwright helpers; open the LibreSign Request Signatures page; wait until the upload interface is fully loaded; expand the Settings section in the left sidebar; keep the upload interface visible, before any document is up

LibreSign currently uses JSignPdf 2.3.0: https://github.com/LibreSign/libresign/blob/main/lib/Service/Install/InstallService.php#L53 JSignPdf already has stable 3.x releases with important changes to its CLI, packaging and signing behavior. Before updating LibreSign, the PHP wrapper must support JSignPdf 3.x: JSignPdf/jsignpdf-php#52 This issue should be worked on after that issue is completed and a new version of jsignpdf-php is available. What needs to be done Update LibreSign to the new jsignpdf-php version with JSignPdf 3.x support. Update the JSignPdf version, download source, checksum and installation logic in InstallService. Check the JSignPdf 3.x package structure and choose the correct package for LibreSign. JSignPdf 3.1 removed the old fat JAR and provides a minimal package for headless/CLI use, so changing only the version and checksum may not be enough. Review JSignPdfHandler and confirm that the current JSignPdf options still work correctly, including visible signatures,

LibreSign now uses Infection to help check the quality of the PHP tests. Code coverage tells us which code was executed by tests. However, it does not tell us if the tests can detect wrong behavior. Mutation testing helps us check this. Infection makes small changes to the source code. These changes are called mutants. After each change, Infection runs the tests again: If a test fails, the mutant is killed. This is good because the test detected the change. If all tests still pass, the mutant escaped. This can mean that an important behavior is not well tested. A mutant can also cause a timeout or an error. These cases need to be checked before deciding what should be changed. The first full LibreSign run generated more than 15,000 mutants and took a long time to run. It also found many escaped mutants, errors and timeouts. Initial run: https://github.com/LibreSign/libresign/actions/runs/32801594308/job/97663483870 Because of this, the full Infection suite is not ready to be required

The Dependabot PR #7876 updates @nextcloud/eslint-config from v8 to v9. This update also brings ESLint 10 and many new lint rules. After applying the new configuration, LibreSign reports many lint problems in the existing code. The goal of this issue is to review these problems, fix the code when the rule makes sense for LibreSign, and enable as many rules as possible instead of simply disabling them. This work should be done on top of #7876. The current list of pending rules is maintained in the libresign/disabled-during-migration section of eslint.config.mjs. Please use this file as the source of truth. What to do Work on one ESLint rule at a time. For each rule: Remove it from libresign/disabled-during-migration. Run npm run lint. Review all reported cases and understand what the rule is trying to improve. Fix all cases in a way that makes sense for LibreSign. Run related tests when the change can affect behavior. Create one commit for that rule. For example: fix(lint): enable no-

We already have PHPUnit tests and code coverage for the PHP code, but coverage alone does not tell us how well the tests detect changes in the code. Add Infection to LibreSign to introduce mutation testing for the PHP test suite. The xobject-template package can be used as a reference, but the implementation should follow the current LibreSign structure and dependencies. Acceptance criteria Infection is installed using the existing bamarni/composer-bin-plugin pattern, with its dependencies isolated under vendor-bin/infection. An infection.json5 configuration file is added to the repository root, configured to run mutation testing against the PHP source code in lib/. Infection uses the existing PHPUnit setup. A mutation:test script is added to the root composer.json, so mutation tests can be executed with: composer mutation:test A GitHub Actions workflow runs mutation tests for relevant PHP changes and prevents the check from passing when the configured mutation score is