mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
metadata_writer
666
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 brios
|
1d6a1c2904 | Merge branch 'main' into metadata_writer | ||
|
ConnorYohandJames Brunton
|
732ef18ae5 |
feat(account-link): redirect-based connect handshake for self-hosted linking (#7494)
Links a self-hosted instance to a SaaS team over an ordinary redirect, and leaves the admin's browser holding a Stirling session at the same time. ## The problem A self-hosted server needs a device credential bound to a SaaS team, and the admin's Supabase JWT must never reach the instance backend. Three things ruled out the obvious approaches: - **A customer hostname can never be in Supabase's redirect allow-list**, so the sign-in cannot happen on the instance's own origin. That is why SSO and sign-up did not work for linking at all. - **A device credential identifies a server, not a person.** Every attended portal read (Usage, Billing, Documents, Infrastructure) goes through `getPortalSaasToken()` and needs a *user* session, so a credential-only link left all of them asking for a second sign-in. - **The previous design relayed a JWT** from the browser into the instance, which is the thing we wanted to avoid. That path is deleted here. ## The solution Redirect and nonce, modelled on desktop's `authService.loginWithSelfHostedOAuth`: mint a nonce, hand the browser off, accept only a callback carrying that nonce back. Desktop has the OS route the reply; self-hosted has no OS hop, so our own approval page performs it. That is the point — the human half happens on an origin we control. ``` instance SaaS admin's browser | POST connect/request | | | (name, callback, nonce, | | | claim-secret hash) | | |-------------------------->| | | <- requestId + authorizeUrl | | | GET /link?request=... | | |<-------------------------------| | | sign in (SSO works here), | | | see ACCOUNT + ORIGIN, approve | | |------------------------------->| | | 302 callback#nonce+session | | POST connect/claim | | | (requestId, claim secret)| | |-------------------------->| | | <- device credential | | ``` Four properties carry the safety, and each is stated in the code because each is easy to lose in a refactor: - **The redirect target is never caller-supplied.** Validated once at creation, then read back from the stored row, so nothing in the approval page's URL can steer the token elsewhere. - **Approval and minting are separate.** Approval records the team and hands out nothing usable; the credential is minted only on claim, authenticated by a secret that never entered a browser. - **A re-authentication cannot move a server between teams.** The team is pinned at creation from the credential only that instance holds, so an approver from another team gets `WRONG_TEAM` instead of a rebind. - **The approver has to confirm what they are binding.** The page shows the address and the signed-in account, with a way to switch, and a checkbox naming the address gates the approve button. The name the server reports is deliberately not shown: the requester picks it on an unauthenticated endpoint, and its honest value is the hostname already in the address. The session rides the URL fragment, so it stays out of access logs and `Referer`, and is stripped before anything awaits. The claim is row-locked, so one approval mints once. A request lives 30 minutes; a settled one is not offered again, since approving it fails server-side. Signing in mid-flow no longer loses the request. The id is kept on the SaaS origin and resumed after any sign-in, which is what makes creating an account work: the confirmation email opens a new tab, where the `next` parameter is gone. Reading it does not consume it — the request may be open in two tabs — and only a recorded decision retires it. The result lands as a modal over the portal the admin started from, and the portal re-reads its link status so the page behind agrees with the modal. Plaintext `http://` callbacks are accepted rather than refused, because many self-hosted instances legitimately run plain HTTP on a private network; the address carries a warning icon explaining the risk, derived server-side so a requester cannot suppress it. Hard-refusing `http://` to a public IP literal is a reasonable follow-up; a bare hostname can't be classified without a DNS lookup, so the warning stays the general mechanism. ## Configuration Four surfaces. Placeholders below, not values. **SaaS backend** | Setting | Needed | Why | |---|---|---| | `stirling.billing.account-link.enabled` | Yes, `true` | The connect controller and service are `@ConditionalOnProperty` with no default, so without it the endpoints do not exist. | | `system.frontendUrl` | Only when the approval page is not on the API's own origin | Where the approver is sent. Must include the app's base path if it is served under one, or the redirect misses `/link`. | **SaaS frontend** | Setting | Needed | Why | |---|---|---| | `VITE_SUPABASE_URL`, `VITE_SUPABASE_PUBLISHABLE_DEFAULT_KEY` | Yes | Its own sign-in. Must be the project the SaaS backend validates tokens against. | | `RUN_SUBPATH` | Only if served under a subpath | Moves the approval page to `<base>/<subpath>/link`, so `system.frontendUrl` has to agree. | **Self-hosted backend** | Setting | Needed | Why | |---|---|---| | `stirling.billing.account-link.enabled` | Yes, `true` | Defaults to `false`. | | `stirling.billing.account-link.saas-base-url` | Yes | Origin of the SaaS API it links to. Not the SaaS frontend. | | `system.frontendUrl` | Optional | Externally reachable base URL for the callback. Otherwise derived from the request's `Origin`, which is right for ordinary deployments and wrong behind a rewriting proxy. | **Self-hosted frontend** | Setting | Needed | Why | |---|---|---| | `VITE_SUPABASE_URL`, `VITE_SUPABASE_PUBLISHABLE_DEFAULT_KEY` | Yes | Accepts the session handed over in the callback fragment. | | `VITE_SAAS_API_URL` | For Usage and Billing | Attended reads go to the SaaS API with the admin's token. Absent, those surfaces stay on the mock. | | `VITE_INCLUDE_PORTAL` | Production builds | Dev builds include the portal automatically; without it there is no link UI and no callback route. | Two things worth stating because neither fails loudly: - **Both frontends must use the URL *and* key of the same Supabase project**, and the same one the SaaS backend validates against. A key from one project with a URL from another is accepted by the browser and rejected by Supabase, which surfaces much later as "session expired" on Usage rather than as an error at hand-over. - **The Supabase redirect allow-list must contain the SaaS app's `/auth/callback`**, since a confirmation email returns through it. Entries are matched exactly. - **`system.frontendUrl` is the existing setting for this**, not a new one, so each side reads its own value and there is nothing extra to configure. It also gates share links, so on a stack with storage and sharing already on, setting it here turns those on too. The self-hosted side deliberately does **not** configure where the approval page lives — SaaS answers that in the connect-request reply, being the only party that knows. Also here, because testing this needs two stacks side by side: `linked:staging` / `linked:dev` (which derive `system.frontendUrl` and `RUN_SUBPATH` themselves), the missing `frontend:staging:saas`, and a per-mode vite `cacheDir` — two dev servers in different modes otherwise re-optimise over one shared dep cache. ## How to test Automated and green: `task frontend:check:all` plus both backend modules. `ConnectRequestServiceTest` covers callback validation, the per-IP cap, single-use approval, claim outcomes, expiry, `WRONG_TEAM` and reauth confirming without minting; `ConnectServiceTest` covers callback-resolution precedence including a foreign-origin callback being discarded; `ConnectControllerTest` covers the authorize URL, including the forwarded-header path and only the first hop being trusted; `ConnectCallback.test.tsx` covers the fragment being stripped synchronously and malformed fragments refused; `LinkAccountModal.test.tsx` covers link and reauth hitting different endpoints. Manual walkthrough: 1. `task linked:staging` — added here; brings up a SaaS stack and a self-hosted instance pointed at it, on discovered ports, and prints the four addresses. 2. Open the link-account modal in the self-hosted portal and continue. Expect the SaaS approval page at `/link?request=<id>`. 3. Sign in as a team leader, or create an account and confirm the email. Either way you should come back to the approval page. 4. Tick the acknowledgement and approve. Expect the fragment gone from the address bar immediately, a result modal over the portal, the portal showing linked without a reload, and attended reads (Usage, Billing) working without a second sign-in. 5. Repeat, approving as a member of a different team. Expect a refusal, not a rebind. ## Outstanding - #7415 to be reworked against this design once this lands. - **No SaaS-side UI to disconnect a server.** `GET /account-link/instances` and `POST /account-link/instances/{id}/revoke` are already team-scoped and leader-gated, and the portal has a panel that uses them, but `portal-saas/components/settings/accountLinkSettings.tsx` exports `null` on the reasoning that "SaaS has no account-link concept". That held when linking was a self-hosted admin managing their own instance; here a leader approves a server they may not administer, and has no way to withdraw it. The seam to fill is that one file. Expected to land with the CTA work in #7415. --------- Co-authored-by: James Brunton <jbrunton96@gmail.com> |
||
|
Balázs Szücs
|
b4f1c67f65 | refactor(metadata): improve parameter handling in MetadataController for improved key processing | ||
|
Balázs Szücs
|
e42175dd9b | refactor(metadata): improve PDF metadata controller to support dynamic custom fields | ||
|
Anthony Stirling
|
f945cc7dc6 |
Regenerate expired test certificates and guard against future expiry (#7682)
The bundled signing test certificates expired at **07:41:10 UTC on 2026-08-26**. They were issued exactly one year earlier, so they went from fine to fatal mid-morning with no warning, and they take down `main` and every open branch, not just one PR. First casualty was the `docker-compose-tests` job on #6802, which started at 07:45: ``` java.security.cert.CertificateExpiredException: NotAfter: Wed Aug 26 07:41:10 UTC 2026 at CreateSignatureBase.checkValidity(CreateSignatureBase.java:159) at CertSignControllerTest.testSignPdfWithPkcs12(CertSignControllerTest.java:205) ``` ``` $ openssl x509 -in app/core/src/test/resources/certs/test-cert.pem -noout -dates notBefore=Aug 26 07:41:10 2025 GMT notAfter =Aug 26 07:41:10 2026 GMT ``` ## What was broken `CertSignControllerTest` (7 tests) and `PdfSigningServiceImplTest` (2) fail outright. `ValidateSignatureControllerMoreTest` and `CertificateValidationServiceMoreTest` read the same fixtures. Auditing the rest of the repo turned up three more time bombs that had not gone off yet: | Fixture | Was | Problem | |---|---|---| | `app/core/.../certs/test-cert.*` + `test-key.*` | expired 2026-08-26 | **already breaking every branch** | | `test-certs/valid-test.p12`, `valid-test.jks` (proprietary + frontend copies) | expire 2027-03-25 | same failure, seven months out | | `test-certs/not-yet-valid-test.p12` | valid **from** 2027-03-25 | becomes valid, so its test silently stops proving anything, on the same day | ## What this does **Regenerates every fixture** with the identical subject DN, alias, password, key size and signature algorithm as before, changing only the validity window. Nothing that any test asserts on has moved. - valid fixtures: `2025-01-01` to `2125-01-01` - `not-yet-valid-test.p12`: `2125-01-01` to `2126-01-01`, so it stays in the future - `expired-test.p12`: pinned to its permanently-past 2024 window **Adds `scripts/generate-test-certs.sh`** as the source of truth, so the next regeneration is one command instead of archaeology. It documents every DN, alias and password, pins the validity windows, and runs on Linux, macOS and Git Bash. **Adds two guard tests** that fail with an actionable message, naming the script, while there is still a year of runway: - `BundledTestCertificateExpiryTest` (app/core) checks all seven formats parse, are in their validity window, and have more than 365 days left - `BundledWorkflowCertificateExpiryTest` (proprietary) does the same for the valid pair, and additionally asserts the expired fixture is still expired and the not-yet-valid one is still in the future That last pair matters: those two fixtures exist to test a validity outcome, and each one silently stops testing anything once the clock passes its window. ## Verification Run locally against the regenerated bytes, on the exact content committed here: ``` ./gradlew :stirling-pdf:test --tests '*CertSignControllerTest*' --tests '*BundledTestCertificateExpiryTest*' \ --tests '*PdfSigningServiceImplTest*' --tests '*ValidateSignatureControllerMoreTest*' \ --tests '*CertificateValidationServiceMoreTest*' BUILD SUCCESSFUL ./gradlew :proprietary:test --tests '*BundledWorkflowCertificateExpiryTest*' --tests '*CertificateValidationIntegrationTest*' \ --tests '*SigningFinalizationServiceMoreTest*' --tests '*ServerCertificateServiceTest*' \ --tests '*CertificateSubmissionValidatorTest*' --tests '*WorkflowSessionServiceTest*' BUILD SUCCESSFUL ``` `spotlessCheck` passes on both modules. |
||
|
EthanHealy01
|
49c1e75ced |
Surface recorded failures in a notification bell (Review Flow PR 4) (#7478)
Review Flow PR 4. Stacked on #7477. Recorded failures appear in a notification bell, showing each reader the failures they are allowed to see and the actions they can actually take. Scope is deliberately viewing and routing only. Resolving a failure — retry, decrypt-and-retry — is #7479, which also brings the write path for it; nothing resolution-shaped ships here, not even dark. ## What's added **A notification bell** in the editor and the processor shell. Polls `GET /api/v1/notifications` every 30 seconds, shows an unread badge, and lists open failures newest first. Each row shows the failure's title, its message with **Copy error** and **Show full message** chips, an occurrence count, and its available actions. **A notification API** (`stirling.software.proprietary.notification`), derived from failures on read rather than stored in its own table: | Route | Purpose | |---|---| | `GET /api/v1/notifications` | the caller's open failures, newest first | Read-only by design: every action the bell offers is one the client runs on its own device, so there is nothing to post back. Every id is prefixed (`failure:<uuid>`), so the bell never holds a raw failure id it could hand to a failure endpoint. **Per-reader actions.** A `FailureKind` declares each action with an audience (`OWNER`, `TEAM_REVIEWER`, `ANYONE_WHO_SEES`). The server resolves that against the reader and derives `Ownership` (`MINE` / `THEIRS` / `UNOWNED`) from the row's actor, so an admin reviewing someone else's failure is not offered a document their browser does not hold. Adding a failure kind requires no frontend change. **Server-run and client-run actions are distinguished.** `FailureActionId` carries an `Execution` facet; the registry requires a bean only for server actions, and dispatching a client action on the failure surface returns 400. The notification projection goes further: it carries only client-run offers, so the bell cannot be sent a button it would refuse to draw. **Actions in the bell:** at most two. The owner of the document gets **View file** (opens it in the editor); a team reviewer gets **View in processor** (dev builds only). Dismiss stays on the failure queue in `/processor/documents` — deciding a failure's fate belongs to the review surface, not the panel that announces it. An action id the build has not wired is skipped rather than rendered dead, so the server can ship new kinds ahead of the clients that understand them. **Attended policy runs record their document.** `POST /api/v1/policies/{id}/run` accepts an optional opaque `fileId`, recorded when the run carries exactly one primary document. This is what lets a repeat fold onto one incident instead of opening a new one per upload, lets deleting the file clear its failure, and lets the owner open the document from the row. ## Behaviour changes - **The bell re-reads as soon as a failure you caused is recorded**, rather than leaving you to wait out a poll interval for news of your own upload. Applies to a failed tool run and to a policy run reaching `FAILED`. Other people's failures still arrive on the poll, which is what it is for. - **An action the reader cannot use is not rendered.** Where the server gave a reason for withholding it, that reason appears as the row's one-line note. An action that was never offered to that reader produces no note. - **Deleting a document closes every incident about it that the deleter caused**, including a failed policy run on their own upload, so a user's own errors leave the bell with the file rather than lingering with a dead button. - **The failures list in `/processor/documents` stays behind `import.meta.env.DEV`**, and View in processor is gated to match so it cannot navigate to a section that is not mounted. Both lift when failures get their own review screen. - **One poll for all bells.** The bell is mounted in three places; the list, document lookups and read marker are shared, so mounting more than one does not multiply requests. - `ACKNOWLEDGE` is no longer offered by any kind. The id, bean and status remain so existing rows stay readable. ## Known limits - The poll does not pause when the tab is hidden. - No retention or per-team cap on `file_run_events`. ## How to test Needs a proprietary or SaaS build with login enabled. `task dev:all`, then sign in. 1. **Create a failure.** Add a password-protected PDF to the editor and choose **Skip for now** when it asks to unlock. The upload starts a policy run that fails on it. 2. **Watch the bell.** The badge should appear within a second or two, not after 30 — this is the refresh-on-failure path. Open it: a row titled "Password-protected document" with the error message and the two chips. 3. **The buttons should be View file and View in processor, nothing else.** No Dismiss and no retries: dispositions live on the review surface, resolutions in #7479. 4. **View file** closes the panel and selects that document in the editor. 5. **Dismiss from the queue instead.** Open `/processor/documents` (dev build), find the row in the failures list and dismiss it there; the bell drops it on its next read. 6. **Confirm the local-document probe.** Create a second failure, then delete that file from the editor and reload. Its incident closes with it; a row whose document is still present keeps **View file**. 7. **Confirm attribution end to end.** Sign in as a plain member, run a shared policy on your own upload so it fails. The member sees their own row in the bell. Sign in as the team leader: they see it too, but with **View in processor** instead of **View file**, because the document is not in their browser. 8. **Confirm folding.** Add the same locked PDF again and skip again. The existing row's occurrence count increases rather than a second row appearing. 9. **Confirm one poll for many bells.** Open the editor and the processor in two tabs. Each tab issues its own poll, but within a tab the several mounted bells share one — the Network tab should show one `GET /api/v1/notifications` per 30s per tab, not three. ## Migration None. No new column and no new value in any CHECK-constrained enum; `CheckConstrainedEnumsTest` fails if that changes. |
||
|
stirlingbot[bot]
|
bcad2cd486 |
Update Backend 3rd Party Licenses (#7653)
Auto-generated by stirlingbot[bot] This PR updates the backend license report based on dependency changes. Signed-off-by: stirlingbot[bot] <stirlingbot[bot]@users.noreply.github.com> Co-authored-by: stirlingbot[bot] <195170888+stirlingbot[bot]@users.noreply.github.com> |
||
|
|
79686a3a09 |
form field editing (#6655)
# Description of Changes Building ontop of a users draft PR for form creation tools **Fill Form** becomes a full **Form Editor**: fill, create, modify and delete AcroForm fields visually. Builds on the community form-creation draft, plus a UX/UI rework pass. - **Backend**: `/api/v1/form` endpoints — `fields-with-coordinates`, `add/modify/delete-fields`, combined `edit-fields` (one round-trip), `fill`, `extract-csv/xlsx`; supports text (multiline, comb), checkbox, dropdown, list box, radio, button actions (reset/print/URL/submit) and signature placeholders - **Create**: type palette, click-or-drag placement with snap guides, inline property editor, batch "Add N fields" - **Modify**: move/resize on the page, arrow-nudge + Delete key, X/Y/W/H inputs, staged edits/deletes with chips, discard - **Fill**: live progress + required tracking, flatten toggle, Export menu (JSON/CSV/XLSX), Ctrl/Cmd+S - **Safety**: confirm dialog before discarding staged work; empty required fields warn with "Save anyway" instead of blocking - **UI**: consistent panel skeleton (fixed header / scrolling list / pinned actions), empty states that link into Create, full i18n with plural keys [walkthrough.html](https://github.com/user-attachments/files/30508976/walkthrough.html) --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. --------- Co-authored-by: Denys Vitali <denys@denv.it> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
James Brunton
|
158187ac46 |
Fix Documents tab in Processor (#7569)
# Description of Changes The Documents tab in the Processor is supposed to be available to all Processor users, but because the API is built on top of the Audit data, which is only for enterprise users, the API call always fails with 403. This means that it never fills the query cache, so every time you go back to the tab it has to reload all the data for a couple of seconds (and will fail again). This fixes the API so that it's available to any Processor user instead of just enterprise users. Also, the documents data was only being written to the log on an enterprise license, so I've changed it so that data is always tracked in the audit log because otherwise the Documents tab would still be useless to non-enterprise users. The Audit Log tab was also available to all Processor users, but would have the same issue where the table would never load because the API would 403 as well. I've just made the Audit Log tab disabled for non-enterprise users now. We might want to do something to signpost it a bit more that it's an enterprise-specific feature, but it's better than nothing for now. |
||
|
Anthony StirlingandJames Brunton
|
e50c3de0a9 |
Run classification locally first and only escalate an unsure verdict to the AI (#7580)
Split out of #7574 — this is the classification half, which is independent of the editor-source work and can land on its own. ## What this does - **Runs the local heuristic first and only escalates an unsure verdict to the AI.** A high-confidence local answer stands; anything less (or a file the heuristic hasn't reached yet) goes to the engine. A wrong label costs more than an engine call, so the bar is deliberately strict. - **Makes `classify` an authorable pipeline task**, so it can be used as a step like any other tool, and skips files that are already classified. - **Leaves the seeded Classification policy unowned** rather than naming a `system` placeholder that was never a real user; existing seeds are repaired on boot. ## Review feedback applied From @jbrunton96 on #7574: - **The generic runner no longer names classification.** Everything classification-specific moved into `proprietary/data/classificationPolicy.ts`, and `usePolicyAutoRun` now asks capability questions instead: `policyRewritesDocument`, `policyDeliversOutputFiles`, `policyRequiresAiEngine`, `shouldDispatchToAi`. There is no `id === "classification"` left in the runner. - **Ordering is no longer a name in the runner.** `pinClassificationLast` is gone; the runner sorts annotating policies after rewriting ones. The constraint is real: an annotating policy is non-blocking, so a rewriting one running after it forks from the pre-annotation version and drops the labels. To be straight about what this is and isn't - see "Still open" below - `policyRewritesDocument` is still keyed on the category id, not on a property each policy declares. The check moved out of the runner; it did not stop being a check on one id. - **Confidence is typed.** New `ClassificationConfidence` union in `core/types/fileContext.ts`, reused by `fileStorage`, `HeuristicConfidence`, and the trusted-verdict constant instead of being respelled at each site. - **Comments trimmed** to the repo's 2-line guideline, and a stale seeder javadoc that still claimed an internal-user owner was corrected. ## Still open, deliberately `classificationPolicy.ts` answers its capability questions with `categoryId === "classification"`. That is the same check relocated, not removed, and the module doc now says so outright. Deliberate, for two reasons: - **The concept it would be declared against is going away.** Policies are becoming pipelines with labels behind a separate enforcement layer, which removes the category the flag would live on. A capability system built on `categoryId` today gets migrated twice. - **Classification is genuinely privileged, not accidentally special.** It is the only policy with a browser-side implementation, so it can answer without the server. That is a product decision, and a local-only mode for set scenarios is planned - the flag for it should be designed with that feature, not guessed at now. The end state for the rest: an in-place output mode retires the ordering rule and `policyDeliversOutputFiles`, and a run result that can carry findings as well as files retires the remainder. Both touch the import path, which is the most delicate code in `usePolicyAutoRun` - not something to bolt on to a PR that has already been split once. Nothing is broken by leaving it. A user-built classify pipeline still gets its labels: the generic import path reads them off the returned PDF. It versions the file instead of labelling in place, and it misses the local-heuristic shortcut, so it always bills the engine. ## Testing - `classificationPolicy.test.ts` — 12 cases covering each capability and the escalation rule - Full frontend `proprietary` project: 39 files / 442 tests - `:proprietary:test` for `DefaultClassificationPolicySeederTest` + `ClassifyLabelControllerTest` - `tsc --noEmit` on core, proprietary, portal, saas, desktop, cloud --------- Co-authored-by: James Brunton <jbrunton96@gmail.com> |
||
|
dependabot[bot]
|
8e7501aec1 |
build(deps): bump org.snakeyaml:snakeyaml-engine from 3.0.1 to 3.1.1 (#7655)
Bumps org.snakeyaml:snakeyaml-engine from 3.0.1 to 3.1.1. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Ludy
|
63ff3afb41 | fix: restrict share link route tokens to UUID length (#7626) | ||
|
dependabot[bot]
|
41e4b67f1d |
build(deps): bump the simple-java-mail group across 2 directories with 2 updates (#7621)
Bumps the simple-java-mail group with 1 update in the / directory: [org.simplejavamail:simple-java-mail](https://github.com/bbottema/simple-java-mail). Bumps the simple-java-mail group with 1 update in the /app/common directory: [org.simplejavamail:simple-java-mail](https://github.com/bbottema/simple-java-mail). Updates `org.simplejavamail:simple-java-mail` from 9.3.1 to 9.3.2 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/releases">org.simplejavamail:simple-java-mail's releases</a>.</em></p> <blockquote> <h2>v9.3.2</h2> <p>Fixed <a href="https://redirect.github.com/bbottema/simple-java-mail/issues/702">#702</a>: clarified that <code>RecipientBuilder</code> accepts one address, while <code>RecipientsBuilder</code> handles comma- or semicolon-delimited address lists; see the <a href="https://www.simplejavamail.org/features.html#section-recipient-builders">recipient builder examples</a>.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/blob/master/RELEASE_HISTORY.md">org.simplejavamail:simple-java-mail's changelog</a>.</em></p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/bbottema/simple-java-mail/commit/982007485db7a5397e7c2782bfc296c530636a14"><code>9820074</code></a> released 9.3.2 [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/12013d9057026ab2a634f5cfa8adf584653e7a89"><code>12013d9</code></a> docs(release): prepare 9.3.2 release notes</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/8746cffb54b0957b667a3fca7bd2e199611dfbbd"><code>8746cff</code></a> fix(recipients): clarify single-address parameter (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/702">#702</a>)</li> <li>See full diff in <a href="https://github.com/bbottema/simple-java-mail/compare/9.3.1...9.3.2">compare view</a></li> </ul> </details> <br /> Updates `org.simplejavamail:outlook-module` from 9.3.1 to 9.3.2 Updates `org.simplejavamail:simple-java-mail` from 9.3.1 to 9.3.2 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/releases">org.simplejavamail:simple-java-mail's releases</a>.</em></p> <blockquote> <h2>v9.3.2</h2> <p>Fixed <a href="https://redirect.github.com/bbottema/simple-java-mail/issues/702">#702</a>: clarified that <code>RecipientBuilder</code> accepts one address, while <code>RecipientsBuilder</code> handles comma- or semicolon-delimited address lists; see the <a href="https://www.simplejavamail.org/features.html#section-recipient-builders">recipient builder examples</a>.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/blob/master/RELEASE_HISTORY.md">org.simplejavamail:simple-java-mail's changelog</a>.</em></p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/bbottema/simple-java-mail/commit/982007485db7a5397e7c2782bfc296c530636a14"><code>9820074</code></a> released 9.3.2 [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/12013d9057026ab2a634f5cfa8adf584653e7a89"><code>12013d9</code></a> docs(release): prepare 9.3.2 release notes</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/8746cffb54b0957b667a3fca7bd2e199611dfbbd"><code>8746cff</code></a> fix(recipients): clarify single-address parameter (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/702">#702</a>)</li> <li>See full diff in <a href="https://github.com/bbottema/simple-java-mail/compare/9.3.1...9.3.2">compare view</a></li> </ul> </details> <br /> Updates `org.simplejavamail:outlook-module` from 9.3.1 to 9.3.2 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
admiralXS
|
1cb914023c |
fix: allow anonymous access to /invite/:token accept page (#7612)
## Problem In the self-hosted build with login enabled, admin-generated invite links point to the SPA route `/invite/<token>`, but that route is not covered by the anonymous whitelist. Anonymous users get 401 / redirected to `/login` before the React app can mount - even though the APIs the page calls (`/api/v1/invite/validate`, `/api/v1/invite/accept`) are already whitelisted. Since accepting an invite is how a *new* account is created, requiring authentication first makes the feature unusable. ## Fix Add `INVITE_LINK_PATTERN` (`^/invite/[^/]+/?$`) in `RequestUriUtils.java`, matched at the end of `isPublicAuthEndpoint()` - mirroring the existing `SHARE_LINK_PATTERN` handling. The invite data APIs remain protected by their own token validation; only the SPA bootstrap page becomes anonymously reachable. ## Tests Added unit tests in `RequestUriUtilsTest.java` mirroring the share-link tests: - `/invite/<token>` (with/without trailing slash, with context path) ? public - bare `/invite` and `/invite/` ? NOT public (token segment required) - `/invite/<token>/foo` nested paths ? NOT public - `/inviteX` prefix over-match ? NOT public ## Verification Pattern behavior validated against all test cases above. Live-tested on 2.14.3 self-hosted: anonymous `GET /invite/<token>` returned 401 before the fix; the whitelisted accept flow itself (`validate` + `accept` APIs) works anonymously end-to-end. |
||
|
Anthony Stirling
|
5f9c396fdd | test: remove PdfUaBenchmarkTest (#7613) | ||
|
stirlingbot[bot]
|
e092b487ec |
Update Backend 3rd Party Licenses (#7608)
Auto-generated by stirlingbot[bot] This PR updates the backend license report based on dependency changes. Signed-off-by: stirlingbot[bot] <stirlingbot[bot]@users.noreply.github.com> Co-authored-by: stirlingbot[bot] <195170888+stirlingbot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
a7c6fa6ef6 |
build(deps): bump io.swagger.core.v3:swagger-core-jakarta from 2.2.46 to 2.2.53 (#7526)
Bumps io.swagger.core.v3:swagger-core-jakarta from 2.2.46 to 2.2.53. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
71af798da4 |
build(deps): bump the simple-java-mail group across 2 directories with 2 updates (#7585)
Bumps the simple-java-mail group with 1 update in the / directory: [org.simplejavamail:simple-java-mail](https://github.com/bbottema/simple-java-mail). Bumps the simple-java-mail group with 1 update in the /app/common directory: [org.simplejavamail:simple-java-mail](https://github.com/bbottema/simple-java-mail). Updates `org.simplejavamail:simple-java-mail` from 9.2.0 to 9.3.1 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/releases">org.simplejavamail:simple-java-mail's releases</a>.</em></p> <blockquote> <h2>v9.3.1</h2> <p>Simple Java Mail 9.3.1 is a Java 8-compatible build-tool maintenance release.</p> <h2>Changes</h2> <ul> <li>Updated Maven Antrun Plugin from 3.1.0 to 3.2.0 for the JPMS consumer-compilation check.</li> <li>Updated Maven Dependency Plugin from 3.8.1 to 3.11.0 for construction of the JPMS module path.</li> </ul> <p>These changes affect project build tooling only. This release contains no runtime-dependency changes, public API changes, or intended mail-sending behavior changes. Java 8 remains the minimum supported runtime.</p> <p>The maintenance pull requests are <a href="https://redirect.github.com/bbottema/simple-java-mail/pull/700">#700</a> and <a href="https://redirect.github.com/bbottema/simple-java-mail/pull/701">#701</a>.</p> <h2>v9.3.0</h2> <p>Simple Java Mail 9.3.0 exposes <code>batch-module</code> as a supported standalone Jakarta Mail orchestration API.</p> <ul> <li><a href="https://redirect.github.com/bbottema/simple-java-mail/issues/698">#698</a> adds <code>BatchTransportExecutor<K></code> for applications that create their own <code>Session</code> and <code>MimeMessage</code> objects without adopting <code>EmailBuilder</code> or <code>Mailer</code>. The main <code>simple-java-mail</code> facade is not required.</li> <li>Register Sessions by cluster key, then run cluster-selected or exact-Session callbacks synchronously or submit them as <code>CompletableFuture</code> work. Each callback receives the actually selected <code>Session</code> and connected <code>Transport</code>.</li> <li>The facade keeps raw leases private, releases connections after successful callbacks, invalidates them after escaping failures, resolves OAuth2 credentials from the selected Session, and provides deterministic graceful or forced shutdown. Its default executor is module-owned; an injected executor remains caller-owned.</li> <li>The existing pooled <code>Mailer</code> path and the standalone facade now share one transport engine. <code>smtp-connection-pool</code> remains the only physical pool owner; do not stack batch/direct orchestration over the Jakarta <code>smtppool</code> provider.</li> <li>The supporting chain is updated to <code>smtp-connection-pool 4.0.1</code>, <code>clustered-object-pool 4.0.3</code>, and <code>generic-object-pool 2.4.2</code>. The published JPMS names are <code>org.simplejavamail.batch</code>, <code>org.simplejavamail.smtpconnectionpool</code>, <code>org.bbottema.clusteredobjectpool</code>, and <code>org.bbottema.genericobjectpool</code>.</li> </ul> <p>See the <a href="https://www.simplejavamail.org/smtp-connection-pooling.html">SMTP connection pooling and batch orchestration guide</a> for the comparison matrix, ownership rules, and complete examples.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/blob/master/RELEASE.txt">org.simplejavamail:simple-java-mail's changelog</a>.</em></p> <blockquote> <p><a href="https://www.simplejavamail.org">https://www.simplejavamail.org</a></p> <!-- raw HTML omitted --> <p>v9.3.0 - v9.3.2</p> <ul> <li><strong>v9.3.2:</strong> <a href="https://redirect.github.com/bbottema/simple-java-mail/issues/702">#702</a>: clarified the single-address contract of RecipientBuilder by renaming its misleading implementation parameter and validation label; use RecipientsBuilder for comma- or semicolon-delimited address lists.</li> <li><strong>v9.3.1:</strong> Updated Maven Antrun Plugin from 3.1.0 to 3.2.0 (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/700">#700</a>) and Maven Dependency Plugin from 3.8.1 to 3.11.0 (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/701">#701</a>), retaining Java 8 compatibility.</li> <li><strong>v9.3.0:</strong> <a href="https://redirect.github.com/bbottema/simple-java-mail/issues/698">#698</a>: exposed batch-module as a supported standalone Jakarta Mail orchestration API with clustered and exact-Session callbacks, asynchronous submission, automatic lease release/invalidation, and deterministic graceful or forced shutdown.</li> <li><strong>v9.3.0:</strong> Updated smtp-connection-pool from 3.1.0 to 4.0.1 and migrated the existing Mailer integration to its explicit SmtpTransportLease contract. The complete generic, clustered, SMTP, and batch dependency chain now publishes stable JPMS automatic module names.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/bbottema/simple-java-mail/commit/e44c4c983e48ec9372ff745ccb9ab01d731867d0"><code>e44c4c9</code></a> released 9.3.1 [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/461e5f7c3b97d4882b21bca7ecb4843530184f32"><code>461e5f7</code></a> docs(release): prepare 9.3.1 release notes</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/68728f3457f7b0e85cf66e758f41985b86c4a125"><code>68728f3</code></a> build(deps-dev): bump org.apache.maven.plugins:maven-dependency-plugin (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/701">#701</a>)</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/d491c334bea647a99538984d917cd6ffdcb3cbce"><code>d491c33</code></a> build(deps-dev): bump org.apache.maven.plugins:maven-antrun-plugin (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/700">#700</a>)</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/b3111e232a23f9187c2b0c6b98a0bb1a895d9309"><code>b3111e2</code></a> docs(website): publish pooling guidance update [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/cb3a9a133b91372d112c1b6a07c92e721f1a6f9e"><code>cb3a9a1</code></a> docs(website): publish pooling guide follow-up [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/29f25e83c654d5dbadd4da321ce9511a4eceeeef"><code>29f25e8</code></a> released 9.3.0 [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/b9c0cb8b58f4477e92fdd7ea395583863f875310"><code>b9c0cb8</code></a> feat(batch): expose standalone transport orchestration</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/92549b27f44a0042ca908d22c25db58ccc1e1630"><code>92549b2</code></a> merge(release): reconcile master with develop [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/b499d76ec28e0566b2000ec6418473da66e1398a"><code>b499d76</code></a> docs(readme): rebuild developer landing page [skip ci]</li> <li>Additional commits viewable in <a href="https://github.com/bbottema/simple-java-mail/compare/9.2.0...9.3.1">compare view</a></li> </ul> </details> <br /> Updates `org.simplejavamail:outlook-module` from 9.2.0 to 9.3.1 Updates `org.simplejavamail:simple-java-mail` from 9.2.0 to 9.3.1 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/releases">org.simplejavamail:simple-java-mail's releases</a>.</em></p> <blockquote> <h2>v9.3.1</h2> <p>Simple Java Mail 9.3.1 is a Java 8-compatible build-tool maintenance release.</p> <h2>Changes</h2> <ul> <li>Updated Maven Antrun Plugin from 3.1.0 to 3.2.0 for the JPMS consumer-compilation check.</li> <li>Updated Maven Dependency Plugin from 3.8.1 to 3.11.0 for construction of the JPMS module path.</li> </ul> <p>These changes affect project build tooling only. This release contains no runtime-dependency changes, public API changes, or intended mail-sending behavior changes. Java 8 remains the minimum supported runtime.</p> <p>The maintenance pull requests are <a href="https://redirect.github.com/bbottema/simple-java-mail/pull/700">#700</a> and <a href="https://redirect.github.com/bbottema/simple-java-mail/pull/701">#701</a>.</p> <h2>v9.3.0</h2> <p>Simple Java Mail 9.3.0 exposes <code>batch-module</code> as a supported standalone Jakarta Mail orchestration API.</p> <ul> <li><a href="https://redirect.github.com/bbottema/simple-java-mail/issues/698">#698</a> adds <code>BatchTransportExecutor<K></code> for applications that create their own <code>Session</code> and <code>MimeMessage</code> objects without adopting <code>EmailBuilder</code> or <code>Mailer</code>. The main <code>simple-java-mail</code> facade is not required.</li> <li>Register Sessions by cluster key, then run cluster-selected or exact-Session callbacks synchronously or submit them as <code>CompletableFuture</code> work. Each callback receives the actually selected <code>Session</code> and connected <code>Transport</code>.</li> <li>The facade keeps raw leases private, releases connections after successful callbacks, invalidates them after escaping failures, resolves OAuth2 credentials from the selected Session, and provides deterministic graceful or forced shutdown. Its default executor is module-owned; an injected executor remains caller-owned.</li> <li>The existing pooled <code>Mailer</code> path and the standalone facade now share one transport engine. <code>smtp-connection-pool</code> remains the only physical pool owner; do not stack batch/direct orchestration over the Jakarta <code>smtppool</code> provider.</li> <li>The supporting chain is updated to <code>smtp-connection-pool 4.0.1</code>, <code>clustered-object-pool 4.0.3</code>, and <code>generic-object-pool 2.4.2</code>. The published JPMS names are <code>org.simplejavamail.batch</code>, <code>org.simplejavamail.smtpconnectionpool</code>, <code>org.bbottema.clusteredobjectpool</code>, and <code>org.bbottema.genericobjectpool</code>.</li> </ul> <p>See the <a href="https://www.simplejavamail.org/smtp-connection-pooling.html">SMTP connection pooling and batch orchestration guide</a> for the comparison matrix, ownership rules, and complete examples.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/bbottema/simple-java-mail/blob/master/RELEASE.txt">org.simplejavamail:simple-java-mail's changelog</a>.</em></p> <blockquote> <p><a href="https://www.simplejavamail.org">https://www.simplejavamail.org</a></p> <!-- raw HTML omitted --> <p>v9.3.0 - v9.3.2</p> <ul> <li><strong>v9.3.2:</strong> <a href="https://redirect.github.com/bbottema/simple-java-mail/issues/702">#702</a>: clarified the single-address contract of RecipientBuilder by renaming its misleading implementation parameter and validation label; use RecipientsBuilder for comma- or semicolon-delimited address lists.</li> <li><strong>v9.3.1:</strong> Updated Maven Antrun Plugin from 3.1.0 to 3.2.0 (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/700">#700</a>) and Maven Dependency Plugin from 3.8.1 to 3.11.0 (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/701">#701</a>), retaining Java 8 compatibility.</li> <li><strong>v9.3.0:</strong> <a href="https://redirect.github.com/bbottema/simple-java-mail/issues/698">#698</a>: exposed batch-module as a supported standalone Jakarta Mail orchestration API with clustered and exact-Session callbacks, asynchronous submission, automatic lease release/invalidation, and deterministic graceful or forced shutdown.</li> <li><strong>v9.3.0:</strong> Updated smtp-connection-pool from 3.1.0 to 4.0.1 and migrated the existing Mailer integration to its explicit SmtpTransportLease contract. The complete generic, clustered, SMTP, and batch dependency chain now publishes stable JPMS automatic module names.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/bbottema/simple-java-mail/commit/e44c4c983e48ec9372ff745ccb9ab01d731867d0"><code>e44c4c9</code></a> released 9.3.1 [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/461e5f7c3b97d4882b21bca7ecb4843530184f32"><code>461e5f7</code></a> docs(release): prepare 9.3.1 release notes</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/68728f3457f7b0e85cf66e758f41985b86c4a125"><code>68728f3</code></a> build(deps-dev): bump org.apache.maven.plugins:maven-dependency-plugin (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/701">#701</a>)</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/d491c334bea647a99538984d917cd6ffdcb3cbce"><code>d491c33</code></a> build(deps-dev): bump org.apache.maven.plugins:maven-antrun-plugin (<a href="https://redirect.github.com/bbottema/simple-java-mail/issues/700">#700</a>)</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/b3111e232a23f9187c2b0c6b98a0bb1a895d9309"><code>b3111e2</code></a> docs(website): publish pooling guidance update [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/cb3a9a133b91372d112c1b6a07c92e721f1a6f9e"><code>cb3a9a1</code></a> docs(website): publish pooling guide follow-up [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/29f25e83c654d5dbadd4da321ce9511a4eceeeef"><code>29f25e8</code></a> released 9.3.0 [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/b9c0cb8b58f4477e92fdd7ea395583863f875310"><code>b9c0cb8</code></a> feat(batch): expose standalone transport orchestration</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/92549b27f44a0042ca908d22c25db58ccc1e1630"><code>92549b2</code></a> merge(release): reconcile master with develop [skip ci]</li> <li><a href="https://github.com/bbottema/simple-java-mail/commit/b499d76ec28e0566b2000ec6418473da66e1398a"><code>b499d76</code></a> docs(readme): rebuild developer landing page [skip ci]</li> <li>Additional commits viewable in <a href="https://github.com/bbottema/simple-java-mail/compare/9.2.0...9.3.1">compare view</a></li> </ul> </details> <br /> Updates `org.simplejavamail:outlook-module` from 9.2.0 to 9.3.1 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Anthony Stirling
|
96a00cebd1 |
Pdf ua converter testing (#7301)
# Description of Changes Adds a PDF/UA converter, an accessibility report, and PDF/A conformance level A. **New: `POST /api/v1/convert/pdf/ua`** (Convert tool, "PDF/UA" target). Tags an untagged PDF, marks decorative content as artifacts, embeds missing fonts and applies the document-level PDF/UA requirements (title, language, tab order, form-field descriptions), then validates with veraPDF. The `pdfuaid` declaration is written only if validation passes, so a returned file never claims more than it delivers; response headers report whether it was declared, how many checks still fail and how many images still need a description. **New: `POST /api/v1/security/accessibility-report`.** Reports what fails, what the converter can fix on its own, what needs a person, and lists the figures needing a description with the keys the conversion accepts back. Read-only; does not modify the file. Capped at 100 MB / 2000 pages and weighted `LARGE_WEIGHT`, since it runs a full veraPDF pass plus the converter's layout analysis over every page. **PDF/A level A.** `pdfa-1a`, `pdfa-2a` and `pdfa-3a` output formats on the existing `/api/v1/convert/pdf/pdfa` endpoint. Level A is level B plus tagging, so the document is tagged after Ghostscript (which discards any structure tree it is given) and the level A claim is written only if veraPDF agrees. Optional `pdfUa=true` additionally declares PDF/UA alongside PDF/A, again only if it validates. Honesty rules the implementation holds to: - **Never claim a level that was not reached.** If tagging fails, the file is returned at level B and is named `_PDFA-2b.pdf`, not `_PDFA-2a.pdf`. With `strict=true` the request fails outright rather than returning a level B file against a level A request, and a level B pass no longer satisfies a strict level A request. - **Never relabel a document's language.** The requested language (default `en-GB`) is applied only when the document declares none; a French PDF stays French unless the caller sets `overrideLanguage`, and ignoring a requested language is reported as a warning. - **Never invent alternative text.** Descriptions come from the caller. The Convert panel can list the images needing one (via the report endpoint) and send them back per figure; any image left undescribed blocks the conformance claim rather than being papered over. - **Never certify hidden content.** Marking images decorative, or suppressing text that could not be tagged reliably, withdraws the claim instead of passing the checker by hiding content. PDF/UA-1 and PDF/UA-2 are both offered; UA-2 raises the file to PDF 2.0 and namespaces the structure tree, and its test asserts conformance rather than merely reporting it. Convert steps saved in Automations/Pipelines round-trip their PDF/UA settings (profile, language, override, title, font embedding, descriptions). --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
stirlingbot[bot]
|
4791d558c5 |
Update Backend 3rd Party Licenses (#7579)
Auto-generated by stirlingbot[bot] This PR updates the backend license report based on dependency changes. Signed-off-by: stirlingbot[bot] <stirlingbot[bot]@users.noreply.github.com> Co-authored-by: stirlingbot[bot] <195170888+stirlingbot[bot]@users.noreply.github.com> |
||
|
James Brunton
|
a744102cb6 |
Support Supporting Files in Pipelines (#7547)
# Description of Changes Currently in the Processor's Pipelines page, none of the tools which require supporting files are usable because it's never been hooked up to the new API to upload supporting files. This PR hooks it up to that so all tools using supporting files work in the processor. I had to tweak the type generation a little for this so we have a static map of which params are for supporting files so we know to handle them differently. The `Test with a file` button has to work a little differently than the main run since it's running an ad-hoc pipeline so the files haven't necessarily been saved to the server yet. In this case, it'll use whatever local changes the user has made for those pipeline steps, and for all other steps, it'll just use what's saved in the server. |
||
|
ConnorYoh
|
6bae9d516d |
chore(saas): one task per environment, and make the frontend follow it (#7483)
## The problem The `dev` profile hardcoded one project ref (`qacaivhsjtftfwtgjvva`) in five places: the ref, the Supabase URL, the publishable key, the datasource host and the meter endpoint. That made it both the shared environment everyone relies on *and* the only thing you could point the backend at. Testing an open SaaS PR meant hand-overriding all five via env just to reach that PR's Supabase preview branch, which is the only place the PR's migrations have actually been applied. Get it wrong and you see `relation "stirling_pdf.<new table>" does not exist` for a table the PR added, which is what happened on [#7414](https://github.com/Stirling-Tools/Stirling-PDF/pull/7414). ## One task per environment ```bash task dev:saas # backend + frontend + engine, against this PR's preview branch task staging:saas # backend + frontend + engine, against the shared v3 project task backend:dev:saas # backend only, preview branch task backend:staging:saas # backend only, v3 ``` | | how | vars | project | |---|---|---|---| | prod | `PROFILES=none` | `SAAS_DB_*` | the live one | | staging | `PROFILES=staging` | `SAAS_STAGING_*` | pinned to v3, always there | | dev | `PROFILES=dev` | `SAAS_DEV_*` | follows a SaaS PR's preview branch | `PROFILES` is still the underlying switch, so the old spelling keeps working. Production deliberately has no named task: reaching it should take a conscious `PROFILES=none`, not a tab-complete. **staging** is the old `dev` configuration, moved and kept pinned. The value of a shared environment is that it is still there tomorrow: reproduce a bug, paste a link to a colleague, share data. **dev** is parameterised by `SAAS_DEV_PROJECT_REF` and derives the Supabase URL, JWT issuer, JWKS, meter endpoint and (unless overridden) the database host from it. Switching which PR you are testing is one variable instead of five. With no ref set, `task backend:dev:saas` stops and says what to set rather than falling back. ## The frontend was the real gap `frontend/editor/.env` is committed and pins the **production** Supabase project, and nothing in the frontend knew about dev or staging. So `task dev:saas` gave you a backend on a preview branch and a login against prod, unless you happened to have hand-written `frontend/editor/.env.saas.local`. The dev tasks now read the backend's env files and derive `VITE_SUPABASE_URL` and `VITE_SUPABASE_PUBLISHABLE_DEFAULT_KEY` from the same project ref the backend resolved, so the two halves cannot point at different projects. Nothing to keep in sync by hand, no new vite mode, and `SAAS_ENV=prod` opts back out to the committed values. ## Where to put your local values Two files, both gitignored, neither ever committed: **`app/.env.saas.local`** is the only one you normally need. The tasks load it for the backend *and* the frontend. ```bash # staging: everything else is already defaulted, so this is all it takes SAAS_STAGING_DB_PASSWORD=... # dev: the preview branch of the PR you are testing, from its "Supabase Preview" check. # A branch has its OWN password and API keys; the parent project's will not authenticate. SAAS_DEV_PROJECT_REF=... SAAS_DEV_DB_PASSWORD=... SAAS_DEV_PUBLISHABLE_KEY=... # prod, if you ever need it SAAS_DB_PROJECT_REF=... SAAS_DB_URL=... SAAS_DB_PASSWORD=... SUPABASE_EDGE_FUNCTION_SECRET=... ``` **`frontend/editor/.env.saas.local`** is no longer needed for choosing a Supabase project, and is best left empty or deleted. If you have one from before this PR, note that the task-supplied values now win, which is the point: the frontend follows the backend. **A blank is not the same as absent.** A dotenv line with an empty value still *sets* the variable, and Spring's `${VAR:default}` only falls back when a variable is absent. So `.env.saas` lists what you must set as blanks, and leaves out the two `*_DB_URL` overrides, which have real defaults to fall back to. This is not theoretical, see below. Committed `app/.env.saas` holds non-secret defaults only. Real secrets are passwords, the edge-function secret and service-role keys. Project refs and publishable keys are neither: a ref is the public `<ref>.supabase.co` subdomain and a publishable key ships in the browser bundle by design, which is why `frontend/editor/.env` has always carried prod's. ## Three bugs found while building the tasks All three were in this PR's own earlier commits, and all three were caught by actually booting things rather than by reading the config. **staging could not boot at all.** A blank `SAAS_STAGING_DB_URL=` in `.env.saas` set the variable to empty, so `${SAAS_STAGING_DB_URL:jdbc:...}` resolved to `""` and startup failed with `spring.datasource.url is required when the saas profile is active`. The file already carried a comment warning about exactly this; it had only been applied to the dev block. The original verification for this PR was "placeholders resolve" and "the task parses", neither of which boots anything. **The dev to staging fallback ran `ddl-auto=update` against shared v3.** The dev profile sets `update`, which is right for a disposable preview branch, and separately fell back to staging's project ref. Together that meant Hibernate was free to reconcile tables that RLS policies depend on. `application-staging.properties` pins `none`, but that only applies when the staging profile is the active one, which it was not on the fallback path. There is no fallback now: with no ref the task stops before gradle, and the frontend fails the same way, both naming the variable. **`PROFILES=` never selected production.** Go template `default` treats `""` as absent, so it silently resolved back to `dev`. It is `PROFILES=none` now. ## Two choices worth reviewing **Staging keeps its committed project ref**, now as a `${SAAS_STAGING_PROJECT_REF:...}` default in one place, with the URL, database host and meter endpoint all derived from it. So staging still works with zero setup, and repointing it is one variable. Nothing in CI referenced the ref or the profile. Its publishable key default carries no inline `gitleaks:allow`: a trailing comment in a `.properties` file is part of the value, so the pragma ended up inside the key. It is in `.gitleaksignore` instead. **`SAAS_DEV_DB_URL` still overrides the whole URL**, so a branch needing the pooler host rather than the direct one is reachable without touching committed config. ## Verification - `task backend:staging:saas` boots against v3 and serves `200`. It could not boot before this commit. - `task backend:dev:saas` with no ref stops before gradle naming the variable, and `PROFILES=none` still reaches production. `task frontend:dev:saas` fails the same way; `SAAS_ENV=staging` still resolves with no local config. - Frontend routing picks the SaaS runner for dev/staging and the plain runner for prod; the derivation returns the right URL and key for each. - Vite's `process.env` precedence and Task's dotenv/env semantics were measured, not assumed. That is how one trap surfaced: Task sets an `env:` key even when its value resolves to empty, and Vite treats an empty `process.env` `VITE_*` as authoritative over a committed `.env`. Putting the Supabase vars on the shared `dev:_run` would have blanked Supabase config for the core, proprietary and desktop dev servers, so the SaaS path has its own runner. - `:saas:spotlessApply` and `:saas:compileJava` green. `DevProfileProjectNotice` becomes `SaasProjectNotice` and covers both profiles, stating the project ref and `ddl-auto` at startup so which environment you are on is never a guess. No behaviour change for prod: the `saas` profile is untouched. |
||
|
EthanHealy01
|
0f8803f35f |
Require the policy-management role to run a policy against its sources (#7565)
## What
Running a stored policy against its **configured sources** (`POST
/api/v1/policies/{id}/trigger`, the manual "run now") now requires the
policy-management role — global admin self-hosted, team leader on SaaS —
alongside the existing team scoping.
## Why
A source sweep operates on the team's configured sources using the
server's stored connection credentials, so it belongs with the other
policy-management capabilities rather than with ordinary use. Team
scoping on its own didn't express that distinction.
## Not changed
- `POST /{id}/run` — running a policy over documents the **caller
supplied** stays open to every team member. That's ordinary editor
enforcement on upload and export, and gating it would break it.
- Ad-hoc pipelines (`/run`, `/run/stream`).
- The scheduled, folder-watch and webhook triggers.
- Single-user deployments (login disabled), which have no roles.
## Implementation
`PolicyManagementAuthority` gains `canTriggerPolicies()`, kept separate
from `canEditPolicies()` so the two capabilities can diverge later. Both
current implementations grant it to the same principals that may edit
policies.
## Tests
- role absent → 403, rejected before any run starts
- role present → 202
- login disabled → check skipped entirely
- `/{id}/run` asserted to consult neither authority method, so the gate
can't quietly extend to the editor path later
|
||
|
ConnorYoh
|
f15832b2bb |
chore(saas): make schema ownership explicit and enforce it (#7489)
## The problem The SaaS database has two writers and always has: the Supabase migrations in the SaaS repo, and Hibernate's `ddl-auto`. That was a convention rather than a rule, and it leaked twice. - An older `ddl-auto` run widened `team_memberships.role` to varchar(255), which needed [a dedicated migration](https://github.com/Stirling-Tools/Stirling-PDF-SaaS/blob/v3/supabase/migrations/20260804000000_fix_team_memberships_role_varchar50.sql) to repair, because RLS policies depended on the column. - `payg_instance_usage` shipped with an entity and **no migration**, and nobody noticed for months — staging already had the table from an earlier `ddl-auto` run. It surfaced only when a fresh preview branch, built from migrations alone, threw `relation does not exist`. Both are the same bug: nobody had to *say* who owned a table, so the answer got decided by accident. ## The fix `SaasSchemaOwnership` is the register — **29 migration-owned, 29 inherited** and left to Hibernate. `MigrationOwnedSchemaFilter` applies it via Hibernate's `hbm2ddl.schema_filter_provider`, wired on the **saas profile only**. Hibernate is never shown a migration-owned table, so it cannot create, alter, drop or truncate one whatever `ddl-auto` is set to. Inherited tables stay managed, so a fresh preview branch still heals itself on first boot. Self-hosted is untouched — there Hibernate rightly owns everything. **Why a filter rather than just `ddl-auto=none`:** off, and a fresh branch is missing the 29 inherited tables. On, and Hibernate can reach the other 29. The filter is what lets both be true at once. **Why per-table, not per-schema:** Hibernate's schema management runs over every mapped entity regardless of namespace. Moving SaaS tables to their own schema would *not* by itself keep Hibernate out of them — worth knowing, because that was the intuitive fix and it doesn't work. ## The part that makes it stick `SaasSchemaOwnershipTest` makes the register binding: every `@Entity` on the SaaS classpath must appear in exactly one set, so **a new entity fails the build until someone states who owns its table**. That's the forcing function that would have caught `payg_instance_usage`. I verified it bites rather than assuming it — removing a single entry fails with: ``` These entity tables are not declared in SaasSchemaOwnership, so nobody owns them. Offending tables -> entities: [policies (stirling.software.proprietary.policy.store.PolicyEntity)] ``` naming both the table and the class, which is what the next person actually needs. ## One debatable call The **validate** filter excludes them too. Letting validation through would flag drift, which is genuinely useful — but `ddl-auto=validate` fails startup, and it would fail on differences we've deliberately accepted (`ai_create_sessions` carries columns from a reverted Typst feature that nothing maps). A boot failure over a table we chose not to manage is noise. Argued in the javadoc; happy to flip it if you'd rather have the signal. ## Dependency Depends on [Stirling-PDF-SaaS#324](https://github.com/Stirling-Tools/Stirling-PDF-SaaS/pull/324), which adds migrations for the four SaaS-owned tables that had none. They're listed here as migration-owned on that basis, so #324 should land first. Companion to [#7483](https://github.com/Stirling-Tools/Stirling-PDF/pull/7483) (dev/staging profiles with per-profile `ddl-auto`). ## Verification `:saas:test` green including the 5 new tests, `spotlessCheck` green, and the mutation check above. |
||
|
EthanHealy01
|
08b08aa8a1 |
Let everyone read the failures they caused (Review Flow PR 3) (#7477)
Review Flow PR 3. Stacked on #7296. A recorded failure becomes readable by the person who caused it. ## What changes Before this, reading or triaging a failure required leader permissions: `FileRunEventController.requireFailureReviewAllowed()` returned 403 to anyone who could not edit policies. #7296 lets any user report a failure, so they could file into a queue they could never read. That gate is removed from the endpoints and the decision moves into `FileRunEventService`: | Caller | Reads and closes | |---|---| | Team leader or admin | the whole team's failures (unchanged) | | Anyone else | only failures where `actor` is them | | Team unresolvable | nothing | | Name unresolvable | nothing | `GET /kinds` is also opened. It returns static enum metadata, and a member needs it to render failures they can already see. ## Additions - An `actor` predicate on both list queries in `FileRunEventRepository`, threaded through `FileRunEventStore.list`. - `ReadScope` (permitted, teamId, actor) replacing `TeamScope`, with `wholeTeam` / `mine` / `denied` factories. - An actor filter on `dispatch`, so acting on another person's row answers **404, not 403** — the same response as an id that does not exist. ## Fixes - **`report()` filed rows under the wrong team.** It took the team from the read scope, which returns null for a caller who cannot be named, so such a report landed unteamed in the bucket every team shares. It now uses a dedicated `currentTeamId()`. - **`forgetFiles` narrows to the caller even for a leader.** File ids are minted by each client, so scoping on team alone would let one caller close a colleague's incidents by naming ids. - The controller no longer injects `PolicyManagementAuthority` or `ApplicationProperties`; with the gate gone it decides nothing. ## Team isolation Unchanged and covered by database-backed tests rather than mocks. `FileRunEventStoreDbTest` asserts that a caller with a team sees only their own team's rows and never the unteamed ones, and that the actor predicate narrows within a team without ever widening across one. Delete either clause from the JPQL and one of those tests fails. No endpoint accepts a team parameter; the team always comes from the authenticated principal. **Attribution is fixed here too, because this PR depends on it.** A failure's actor was read from the MDC audit principal, which carries the BILLING identity — for a stored policy, always its owner. Since reads are now narrowed to the rows you are the actor on, a wrong actor means the member who caused a failure and holds the document reads nothing, while the policy owner is handed incidents from runs they never triggered. The triggering user is now carried on the run, separate from the billing principal and the output owner, and is null for a trigger-fired sweep so an unattended failure stays ownerless. `PolicyFailureAttributionTest` runs the real engine, recorder, store and service together. The two sides used to assert independently — the engine's test matched the actor with `any()`, which is how this went unnoticed. ## How to test Needs a proprietary or SaaS build with login enabled and two accounts in the same team, one a leader and one not. `task dev:all` gives you the stack. 1. **As the member**, fail a tool: open a PDF and run **Remove Password** with a wrong password. 2. **Still as the member**, go to `/processor/documents` → **Failures**. Before this PR you got nothing here. Now you see your own row, and only yours. 3. **As the leader**, open the same view. You see the whole team's rows, including the member's. 4. **Member cannot reach a colleague's row.** As the leader, copy a row's id from **Show raw JSON**. As the member, `POST /api/v1/file-run-events/{thatId}/actions/DISMISS`. It answers **404**, and the row is untouched — it must not answer 403, which would confirm the row exists. 5. **Member can close their own.** Dismiss your own row as the member. It leaves the default view. 6. **Deleting a file only closes your own rows.** As the leader, delete a file in your editor. The member's incidents are untouched even if the leader's client happened to name the same ids. ## Migration None. `actor` is an existing column; this only adds predicates to existing queries. |
||
|
EthanHealy01
|
2483e9f37a |
Report editor-originated failures into the same queue (Review Flow PR 2) (#7296)
Review Flow PR 2 of 5. Editor tool failures now reach the same durable queue as failures from folders, buckets and webhooks. ## What's added **A report endpoint** — `POST /api/v1/file-run-events/reports`, open to any authenticated user. Takes four fields: `operation`, `errorCode`, `fileIds`, `detail`. No team, no actor, no filename: the first two come from the session, the third is never a field. Refused with 400 above 200 file ids, and nothing is written when refused. **Automatic reporting from every tool** — wired into `useToolOperation`, so no per-tool work is needed. Client-side refusals (an unsupported format that never reaches the server) are reported too. User cancellations are not. **Error codes parsed from Blob bodies as well as JSON** — a download-typed tool call fails with a Blob, so `errorCodeOf` handles both shapes. **Source attribution for unattended runs** — `sourceId` is threaded from `PolicyRunner` through `PolicyRun` to the recorded row and out to the wire, so a folder, bucket or webhook failure names what fed it. Previously it had none. **Deleting a file closes its failures** — `FileContext.removeFiles` notifies `POST /removed-files`, which transitions those incidents to `FILE_REMOVED`. Terminal, so they leave every reviewer's queue. The rows stay for audit. **The queue can be emptied** — reads now default to open statuses only; ask for a status explicitly to see closed rows. ## Behaviour changes - **Editor failures dedup per person.** `RecordFailure.scopeRef()` includes the actor for TOOL-origin rows, so two people hitting the same failure on the same file are two incidents rather than one. Processor rows are unaffected and their dedup key is byte-identical to before. - **`UNKNOWN` offers only Dismiss.** Acknowledge is no longer offered on it. - **Background reports no longer raise a toast.** Both calls pass `suppressErrorToast`, so a failed report is silent as intended; previously a core build showed the user a "Not Found" toast on every tool failure. ## What is stored File ids only, never names. The request type has no filename field, and a `fileNames` value handed to the client reporter is accepted and ignored. One caveat to review deliberately: the free-text `detail` is stored **verbatim**. `RecordFailure` truncates it at 2000 characters and nothing else; the redaction that used to strip name-shaped text was reverted in `024899f3f6` because it made an unclassified failure impossible to act on. A backend message that embeds a filename (LibreOffice conversion errors, IO errors) will therefore persist that text and show it to a team leader. ## How to test Needs a proprietary or SaaS build with login enabled. `task dev:all` gives you one. 1. **Report a failure from a tool.** Open a PDF, run **Remove Password** on it with a wrong password. Nothing visible changes for you: reporting is silent by design. 2. **See it recorded.** Go to `/processor/documents` and scroll to **Failures** (dev builds only). A row appears titled "Password-protected document", with `Hit by <your user>`. Press **Show raw JSON** to see exactly what was stored. 3. **Confirm no filename is stored as data.** In that JSON, `fileId` is an opaque uuid and there is no name field. Note the `detail` string may contain a filename if the backend put one in its message, per the caveat above. 4. **Confirm the request is capped.** In DevTools, POST to `/api/v1/file-run-events/reports` with 201 entries in `fileIds`. It returns 400 naming the limit, and no rows are added. 5. **Deleting a file clears its failure.** Back in the editor, delete the file you just failed on. Refresh the failures list: its row is gone from the default view. Filter by `FILE_REMOVED` to see it still exists. 6. **Two people, two incidents.** Have a colleague fail the same tool on their own copy of the same file. Two rows, not one occurrence count. ## Migration `source_id` is a new column and `FILE_REMOVED` a new status value. Both are already in the SaaS migration ([Stirling-PDF-SaaS #322](https://github.com/Stirling-Tools/Stirling-PDF-SaaS/pull/322)); self-hosted picks them up from `ddl-auto`. |
||
|
James Brunton
|
6f2b829f72 |
Filter Pipelines page to only show what the user thinks as pipelines (#7495)
# Description of Changes Currently, the Pipelines page shows all backend Policies, which was the desired behaviour when we first designed this, but as it's come along, it doesn't feel right anymore. This adds a filter so the Pipelines table only shows things that have been defined by the user as a New Pipeline, so not Policies etc. ## Before <img width="1510" height="789" alt="image" src="https://github.com/user-attachments/assets/5aebb065-3d42-4483-be3c-253fd8918d49" /> ## After <img width="1512" height="790" alt="image" src="https://github.com/user-attachments/assets/2966a0de-ec9f-43e6-bb1d-c4aeb30dfbf8" /> |
||
|
Anthony Stirling
|
0be10b2dff |
Cucumber concurrency validation plus fix (#7379)
# Description of Changes cucumber tests to run multiple threads of commands at same time --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
Ludy
|
5170509695 |
deps: upgrade mwiede JSch to 2.28.6 and adapt SFTP password handling (#7496)
# Description of Changes This PR replaces #7490 and upgrades `com.github.mwiede:jsch` from `0.2.23` to `2.28.6`. In addition to the dependency bump from the original Dependabot PR, this PR includes the required compatibility adjustment for SFTP password authentication: - Updated `jschVersion` in `build.gradle` from `0.2.23` to `2.28.6`. - Updated `SftpFileClient` to pass the configured password to JSch as UTF-8 encoded bytes instead of using the `String` overload. - Preserved the existing SFTP connection and host-key verification behavior. - Addresses the API compatibility changes introduced by the newer JSch version that prevented the dependency upgrade from being used unchanged. This supersedes #7490 --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
briosandAnthony Stirling
|
4a2329ab6d |
refactor(hibernate): implement manual Hibernate-compliant equals/hashCode for entity classes (#6433)
# Description of Changes This PR refactors our JPA entity classes to replace Lombok's `@Data` and auto-generated `@EqualsAndHashCode` annotations with explicit Lombok annotations and custom, JPA-compliant `equals()` and `hashCode()` implementations. ### Rationale Lombok's default `@Data` and `@EqualsAndHashCode` annotations are not recommended for JPA entities. They often lead to: - Severe performance issues (e.g., loading lazy collections when evaluating `hashCode` or `toString`). - Identity mismatches or collection bugs (e.g., when database-generated IDs transition from `null` to assigned, breaking the entity's lookup in a `Set` or `Map`). This change ensures all JPA entities use safe Hibernate proxy checking and use only the entity's database identifier for equality and hash code calculations. <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [X] I have performed a self-review of my own code - [X] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [X] I have run `task check` to verify linters, typechecks, and tests pass - [X] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. --------- Co-authored-by: Anthony Stirling <77850077+Frooodle@users.noreply.github.com> |
||
|
imgbot[bot]andImgBotApp
|
a7eb6ebcc3 |
[ImgBot] Optimize images (#7488)
## Beep boop. Your images are optimized! Your image file size has been reduced by **16%** 🎉 <details> <summary> Details </summary> | File | Before | After | Percent reduction | |:--|:--|:--|:--| | /frontend/editor/src-tauri/icons/ios/AppIcon-512@2x.png | 32.25kb | 9.86kb | 69.44% | | /frontend/editor/src/core/assets/brand/modern-logo/logo512.png | 7.96kb | 4.49kb | 43.61% | | /app/core/src/main/resources/static/apple-touch-icon.png | 6.05kb | 3.55kb | 41.39% | | /frontend/editor/src-tauri/icons/Square150x150Logo.png | 5.10kb | 3.13kb | 38.52% | | /frontend/editor/public/og_images/saas/app-processor.png | 125.15kb | 77.41kb | 38.15% | | /frontend/editor/public/mstile-150x150.png | 4.32kb | 2.68kb | 37.99% | | /frontend/editor/src-tauri/icons/mstile-150x150.png | 4.32kb | 2.68kb | 37.99% | | /frontend/editor/src-tauri/icons/Square142x142Logo.png | 4.89kb | 3.07kb | 37.28% | | /frontend/editor/public/og_images/saas/app.png | 118.49kb | 76.07kb | 35.80% | | /frontend/editor/src-tauri/icons/mstile-310x150.png | 4.77kb | 3.09kb | 35.16% | | /frontend/editor/public/mstile-310x150.png | 4.77kb | 3.09kb | 35.16% | | /frontend/editor/src-tauri/icons/android/mipmap-mdpi/ic_launcher_foreground.png | 3.81kb | 2.50kb | 34.32% | | /frontend/editor/public/og_images/saas/app-editor.png | 119.24kb | 78.94kb | 33.80% | | /frontend/editor/src/core/assets/brand/modern-logo/logo192.png | 3.09kb | 2.06kb | 33.22% | | /frontend/editor/src-tauri/icons/ios/AppIcon-60x60@3x.png | 3.91kb | 2.73kb | 30.17% | | /frontend/editor/src-tauri/icons/ios/AppIcon-76x76@2x.png | 3.53kb | 2.48kb | 29.84% | | /frontend/editor/src-tauri/icons/android/mipmap-xhdpi/ic_launcher_round.png | 3.36kb | 2.36kb | 29.82% | | /frontend/editor/src-tauri/icons/android/mipmap-xhdpi/ic_launcher.png | 3.36kb | 2.36kb | 29.82% | | /frontend/editor/src-tauri/icons/ios/AppIcon-83.5x83.5@2x.png | 3.77kb | 2.65kb | 29.66% | | /frontend/editor/src-tauri/icons/64x64.png | 2.46kb | 1.86kb | 24.53% | | /frontend/editor/src-tauri/icons/ios/AppIcon-29x29@3x.png | 2.37kb | 1.82kb | 23.05% | | /frontend/editor/src-tauri/icons/Square89x89Logo.png | 3.24kb | 2.50kb | 22.64% | | /frontend/editor/src-tauri/icons/ios/AppIcon-40x40@2x-1.png | 2.27kb | 1.76kb | 22.22% | | /frontend/editor/src-tauri/icons/ios/AppIcon-40x40@2x.png | 2.27kb | 1.76kb | 22.22% | | /frontend/editor/src-tauri/icons/ios/AppIcon-76x76@1x.png | 2.19kb | 1.70kb | 22.17% | | /frontend/editor/src/core/assets/brand/classic-logo/logo512.png | 99.72kb | 78.32kb | 21.47% | | /frontend/editor/src-tauri/icons/ios/AppIcon-60x60@2x.png | 2.35kb | 1.86kb | 20.92% | | /frontend/editor/src-tauri/icons/ios/AppIcon-40x40@3x.png | 2.35kb | 1.86kb | 20.92% | | /frontend/editor/src/core/assets/brand/modern-logo/Firstpage.png | 210.88kb | 169.27kb | 19.73% | | /frontend/editor/src-tauri/icons/Square71x71Logo.png | 2.73kb | 2.25kb | 17.59% | | /frontend/editor/src-tauri/icons/ios/AppIcon-29x29@2x.png | 1.71kb | 1.43kb | 16.47% | | /frontend/editor/src-tauri/icons/ios/AppIcon-29x29@2x-1.png | 1.71kb | 1.43kb | 16.47% | | /frontend/editor/src-tauri/icons/Square44x44Logo.png | 1.72kb | 1.46kb | 15.31% | | /frontend/editor/src-tauri/icons/android/mipmap-hdpi/ic_launcher.png | 1.90kb | 1.62kb | 14.63% | | /frontend/editor/src-tauri/icons/android/mipmap-hdpi/ic_launcher_round.png | 1.90kb | 1.62kb | 14.63% | | /frontend/editor/src-tauri/icons/android/mipmap-mdpi/ic_launcher_round.png | 1.79kb | 1.54kb | 14.25% | | /frontend/editor/src-tauri/icons/android/mipmap-mdpi/ic_launcher.png | 1.79kb | 1.54kb | 14.25% | | /frontend/editor/src-tauri/icons/Square284x284Logo.png | 9.32kb | 8.03kb | 13.78% | | /app/core/src/main/resources/static/images/signature.png | 20.06kb | 17.39kb | 13.30% | | /docs/stirling.png | 20.06kb | 17.39kb | 13.30% | | /frontend/editor/src-tauri/icons/android-chrome-512x512.png | 20.06kb | 17.39kb | 13.30% | | /frontend/editor/public/android-chrome-512x512.png | 20.06kb | 17.39kb | 13.30% | | /frontend/editor/public/favicon.png | 20.06kb | 17.39kb | 13.30% | | /frontend/editor/src-tauri/icons/ios/AppIcon-20x20@3x.png | 1.67kb | 1.45kb | 13.03% | | /frontend/editor/src-tauri/icons/Square310x310Logo.png | 10.43kb | 9.09kb | 12.79% | | /frontend/editor/src/core/assets/brand/classic-logo/Firstpage.png | 405.84kb | 355.87kb | 12.31% | | /frontend/editor/src-tauri/icons/android/mipmap-xxxhdpi/ic_launcher_foreground.png | 16.87kb | 14.83kb | 12.09% | | /frontend/editor/src-tauri/icons/android/mipmap-xxhdpi/ic_launcher_foreground.png | 10.69kb | 9.41kb | 11.98% | | /frontend/editor/src-tauri/icons/128x128@2x.png | 8.59kb | 7.60kb | 11.55% | | /frontend/editor/src-tauri/icons/android/mipmap-xhdpi/ic_launcher_foreground.png | 6.70kb | 5.99kb | 10.70% | | /frontend/editor/src-tauri/icons/192x192.png | 6.10kb | 5.47kb | 10.36% | | /frontend/editor/public/android-chrome-192x192.png | 6.10kb | 5.47kb | 10.36% | | /frontend/editor/src-tauri/icons/android-chrome-192x192.png | 6.10kb | 5.47kb | 10.36% | | /frontend/editor/src-tauri/icons/android/mipmap-xxxhdpi/ic_launcher_round.png | 6.29kb | 5.67kb | 9.85% | | /frontend/editor/src-tauri/icons/android/mipmap-xxxhdpi/ic_launcher.png | 6.29kb | 5.67kb | 9.85% | | /frontend/editor/src/core/assets/brand/classic-logo/logo192.png | 23.45kb | 21.19kb | 9.62% | | /frontend/editor/src-tauri/icons/android/mipmap-hdpi/ic_launcher_foreground.png | 5.21kb | 4.74kb | 9.06% | | /frontend/editor/src-tauri/icons/mstile-310x310.png | 11.48kb | 10.45kb | 8.95% | | /frontend/editor/public/mstile-310x310.png | 11.48kb | 10.45kb | 8.95% | | /frontend/editor/public/mstile-144x144.png | 4.98kb | 4.53kb | 8.95% | | /frontend/editor/src-tauri/icons/mstile-144x144.png | 4.98kb | 4.53kb | 8.95% | | /frontend/editor/src-tauri/icons/android/mipmap-xxhdpi/ic_launcher_round.png | 4.87kb | 4.44kb | 8.89% | | /frontend/editor/src-tauri/icons/android/mipmap-xxhdpi/ic_launcher.png | 4.87kb | 4.44kb | 8.89% | | /frontend/editor/src-tauri/icons/StoreLogo.png | 1.89kb | 1.76kb | 7.03% | | /frontend/editor/src-tauri/icons/128x128.png | 4.16kb | 3.95kb | 5.07% | | /app/core/src/main/resources/static/favicon-32x32.png | 1.29kb | 1.23kb | 4.90% | | /frontend/editor/src-tauri/icons/32x32.png | 1.29kb | 1.23kb | 4.90% | | /frontend/editor/src/core/assets/login/microsoft.svg | 0.29kb | 0.27kb | 4.79% | | /frontend/editor/src-tauri/icons/Square107x107Logo.png | 3.72kb | 3.54kb | 4.78% | | /frontend/editor/src-tauri/icons/ios/AppIcon-40x40@1x.png | 1.13kb | 1.08kb | 4.25% | | /frontend/editor/src-tauri/icons/ios/AppIcon-20x20@2x-1.png | 1.13kb | 1.08kb | 4.25% | | /frontend/editor/src-tauri/icons/ios/AppIcon-20x20@2x.png | 1.13kb | 1.08kb | 4.25% | | /frontend/editor/public/og_images/shared-sign.png | 620.42kb | 597.33kb | 3.72% | | /frontend/editor/src-tauri/icons/mstile-70x70.png | 3.34kb | 3.25kb | 2.66% | | /frontend/editor/public/mstile-70x70.png | 3.34kb | 3.25kb | 2.66% | | /frontend/editor/src/core/assets/login/authentik.svg | 6.85kb | 6.81kb | 0.70% | | /frontend/editor/src/core/assets/brand/classic-logo/logo-tooltip.svg | 1.49kb | 1.48kb | 0.59% | | /frontend/editor/src/core/assets/login/oidc.svg | 11.32kb | 11.27kb | 0.43% | | /frontend/editor/src/core/assets/login/github.svg | 1.44kb | 1.44kb | 0.20% | | | | | | | **Total :** | **2,144.28kb** | **1,792.57kb** | **16.40%** | </details> --- [📝 docs](https://imgbot.net/docs) | [:octocat: repo](https://github.com/imgbot/ImgBot) | [🙋🏾 issues](https://github.com/imgbot/ImgBot/issues) | [🏪 marketplace](https://github.com/marketplace/imgbot) <i>~Imgbot - Part of [Optimole](https://optimole.com/) family</i> Signed-off-by: ImgBotApp <ImgBotHelp@gmail.com> Co-authored-by: ImgBotApp <ImgBotHelp@gmail.com> |
||
|
brios
|
cd49daf5c6 |
refactor(api): move DeletingRandomAccessFile to CustomPDFDocumentFactory as a private static class (#7344)
# Description of Changes It was in a seperate dir (app/common/src/main/java/org/apache/pdfbox/examples/util/) which i felt out of place for it. <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [X] I have performed a self-review of my own code - [X] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [X] I have run `task check` to verify linters, typechecks, and tests pass - [X] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
Anthony Stirling
|
18e056ea8d |
feat: switch default branding to the modern Stirling logo (#7485)
# Description of Changes logo changes! --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
brios
|
1447ed8b62 |
refactor(redact): replace PDFBox-based text redaction with JPDFium (#7364)
# Description of Changes Refactors automatic text redaction to use JPDFium-based redaction/text removal instead of PDFBox Changes: * The `RedactController` now uses the JPDFium native redaction engine (`PdfRedactor.redact`) as the primary method for PDF redaction, with automatic fallback to the manual redaction service if JPDFium fails or throws an exception. This improves reliability and leverages more robust native features when available. * Regex patterns provided by the user are now validated before redaction begins, ensuring invalid patterns are rejected early with clear error messages. * The code now trims and filters out empty or excessively long redaction terms, preventing unnecessary processing and potential errors. <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have run `task check` to verify linters, typechecks, and tests pass - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
Ludy
|
fdc1682863 |
chore: relocate frontend static assets and improve backend-only resource handling (#7171)
# Description of Changes Move favicons, SVGs, and images from backend resources to frontend public directory. Update Gradle build to copy sample files in backend-only mode. Fix og-metadata image references for shared-sign feature. Update .gitignore to exclude generated/frontend-managed assets from backend. --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
Ludy
|
a28a950aa4 |
feat: modernize codebase using Java switch expressions and List#getFirst/getLast APIs (#6334)
# Description of Changes This PR introduces a broad modernization of the codebase by adopting newer Java language features and improving code readability and maintainability. ## What was changed - Replaced traditional `switch` statements with modern switch expressions (`case ->`) across multiple classes. - Replaced usages of `List#get(0)` and `List#get(size - 1)` with `getFirst()` and `getLast()` respectively. - Simplified conditional logic using pattern matching (e.g., `instanceof` and switch pattern matching). - Refactored various utility and controller classes to reduce boilerplate and improve clarity. - Removed unused or redundant code (e.g., `parseClientFileIds` method in `MergeController`). - Improved type safety (e.g., using `Class::isInstance` instead of `instanceof` checks in streams). - Cleaned up Spring annotations by removing unnecessary `@Autowired` where constructor injection is already used. - Added a new test (`UIDataControllerTest`) to ensure correct handling of identical JSON configs with different filenames. - Minor formatting and style fixes (e.g., Spotless formatting adjustment). ## Why the change was made - To align the codebase with modern Java standards (Java 17+ features). - To improve readability and maintainability by reducing verbosity. - To eliminate common indexing patterns that are more error-prone. - To standardize coding style across the project. - To improve test coverage for edge cases discovered during refactoring. --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. --------- Signed-off-by: Ludy87 <Ludy87@users.noreply.github.com> |
||
|
stirlingbot[bot]
|
8d0414acf3 |
Update Backend 3rd Party Licenses (#7401)
Auto-generated by stirlingbot[bot] This PR updates the backend license report based on dependency changes. Signed-off-by: stirlingbot[bot] <stirlingbot[bot]@users.noreply.github.com> Co-authored-by: stirlingbot[bot] <195170888+stirlingbot[bot]@users.noreply.github.com> |
||
|
Anthony Stirling
|
7a748d4ad2 |
Add stored supporting files for pipeline steps (#7146)
# Description of Changes Backend only change for pipelines to support files (ie pipeline to sign all files with the same cert file etc) --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
Reece Browne
|
34819ae502 |
Draw signatures on a phone via QR code in the Sign tool (#7335)
# Description of Changes Scan a QR code in the Sign tool, draw your signature on your phone, and it appears on your desktop ready to place. Rides the mobile scanner's existing transfer sessions — no new backend endpoints. **Desktop:** a **Mobile upload** button above the signature source selector shows a QR code. When the signature arrives, the modal closes, it lands in the matching source, and **placement activates automatically** — click the PDF to place. **Phone:** a new public `/mobile-sign` page with three tabs (same order as the desktop sources): - **Draw** → canvas signature. Touch-first pad (pointer events, DPR-aware, smoothed strokes, undo/clear, black/blue ink, 3 pen sizes), exported as a transparent PNG cropped to the ink. Compact layout in phone landscape. - **Photo** → image signature. "Take a photo" opens the camera directly; "From gallery" opens the picker. A preview of the current image signature now shows in the desktop's Image source (previously arrival was invisible until placement — also fixes this for saved image signatures). - **Type** → text signature. Travels as data (text + font + colour), so it stays *editable* on the desktop. Fonts are the sign tool's own text-mode list. **Security:** the transfer endpoints are unauthenticated by design (10-min sessions, files deleted after download — same model as the scanner). The desktop treats every arrival as untrusted: images only, and the text payload is clamped field by field. **Config:** new `system.enableMobileSignature` flag (default on), independent of `enableMobileScanner`; the shared endpoints accept either. The Tauri desktop app serves a self-contained `mobile-sign.html` (draw-only), mirroring `mobile-upload.html`. **Refactor:** the session lifecycle (create/poll/download/expiry) moved out of `MobileUploadModal` into a shared `useMobileTransferSession` hook; the scanner modal now uses it, behaviour unchanged. Also fixes two bugs hit along the way: the signature pad collapsing to its 150px intrinsic height (indefinite parent height), and a setState loop in `SignSettings` when text parameters are set programmatically (draft-sync effects ping-ponging). ## Screenshots | Desktop: QR entry | Phone: draw | Desktop: received | |---|---|---| |  |  |  | ## How to test 1. Open the app on an address your phone can reach (not `localhost`), Sign tool → **Mobile upload**, scan the QR. 2. Draw → **Send to computer** → it becomes the active canvas signature and placement is live: click the PDF to place. 3. Photo tab → arrives in the Image source with a preview. Type tab → arrives editable in the Text source. 4. Flags: `enableMobileSignature: false` hides the button; signature still works with the scanner disabled. Verified end-to-end (all three kinds, portrait/landscape/tablet) plus `task frontend:check` and the touched backend tests. --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [x] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [x] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have run `task check` to verify linters, typechecks, and tests pass - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
Anthony Stirling
|
8b1bfb87f7 |
Add S3 Object Lock retention to policy outputs (#7094)
# Description of Changes Add S3 Object Lock retention to policy outputs (create file and cant be deleted untill after a set deadline passed) --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
ConnorYoh
|
c146f7e877 |
chore(saas): drop the last dead Flyway migration (#7433)
Removes `app/saas/src/main/resources/db/migration/saas/V33__api_keys.sql`, the only file left in that tree. ## Flyway does not run There is no Flyway dependency in any `build.gradle` and no Flyway configuration in any properties file. Nothing has executed these for some time, so `V33` was never applied by anything. SaaS schema has exactly two writers today: 1. Supabase CLI migrations in the `Stirling-PDF-SaaS` repo, applied by that repo's PR CI 2. Hibernate `ddl-auto=update` in the app, which only ever adds ## Why delete rather than leave it A directory of plausible-looking migrations is a trap. The next person to make a schema change adds a `V34`, assumes it will run, and it silently does not. I nearly did exactly that while working on [#7414](https://github.com/Stirling-Tools/Stirling-PDF/pull/7414) before checking whether Flyway was actually wired. ## Nothing is lost Both tables it declared, `api_keys` and `api_key_daily_usage`, have JPA entities (`ApiKey`, `ApiKeyDailyUsage`), so `ddl-auto` creates them. That is already how they exist on every deployment that has them, since Flyway was not the thing creating them. ## Checks No references anywhere: nothing in code, config, gradle or docs mentions `db/migration`, `flyway` or `V33`. Two code comments mention Flyway historically, explaining why a column looks the way it does; those are accurate history and are left alone. `:saas:compileJava` and `:saas:processResources` green after the removal. |
||
|
ConnorYohandReece Browne
|
df170fd4a6 |
feat(storage): encryption-at-rest ops — audit, admin kill switch, migration, key rotation (PR2) (#7173)
# Description of Changes
**PR2 of the encrypt-at-rest initiative — PR1 was #7155** Makes the P1
crypto operable and compliance-credible: admins can see the feature's
state, flip the kill switch over an API instead of raw SQL, encrypt the
pre-existing plaintext backlog, rotate the master key, and every
security-relevant event lands in the audit trail. No frontend — that's
PR3.
**What was changed**
- **Audit events** — new `STORAGE_ENCRYPTION` audit type, emitted
through a small listener interface so the crypto classes stay plain
objects: `encrypt`, `decrypt` (per-read events honour
`storage.encryption.auditReads`, default **on** — HIPAA reviewers expect
read audit; busy installs can disable), `decrypt.denied` (always),
`key.created/disabled/enabled`, `master.rotated`, `migration.completed`,
plus a `plaintextExport` marker whenever a plaintext copy of
encrypted-at-rest content is served (with `inline` flag to distinguish
in-app view from saved download).
- **Admin API** `/api/v1/admin/storage-encryption` (`hasRole('ADMIN')`):
- `GET /status` — write/decrypt state, **master-key fingerprint**
(SHA-256 prefix for backup verification, never key material), encrypted
vs plaintext file counts, full key list with status history.
- `POST /keys/{id}/disable` / `enable` — the kill switch, now with
active cache invalidation so revocation is immediate on the handling
node (cross-node converges within the 60s cache TTL). Enable is
restricted to DISABLED keys so two ACTIVE keys can't exist per scope.
- `POST /migrate` + `GET /migrate/status` — encrypt-existing job.
- `POST /master/rotate` — key material is never accepted over HTTP; keys
come from config/env.
- **Deliberately no delete endpoint** — key material can be disabled but
never destroyed through the API.
- **Encrypt-existing migration job** — new writes are encrypted from the
moment the flag is on; this converts the backlog. Crash-safe per file:
store the encrypted copy under a NEW storage key → compare-and-swap the
DB row → only then delete the old blob. A CAS miss (user replaced the
file mid-run) discards the job's copy — the user's file always wins.
Worst crash outcome is an orphaned blob, never a lost file; re-runs are
idempotent (`encryption_key_id IS NULL` selection, cursor-paged so
failures can't wedge the loop). Handles all three blobs per row
(main/history/audit-log), runs on a throttled virtual thread,
single-flight guarded.
- **Master-key rotation** — cheap by design thanks to the P1 hierarchy:
rotate re-wraps the handful of KEK rows, zero file I/O. New config
`stirling.security.fileEncryptionKeyPrevious` (+env) gives `unwrap` a
fallback during rotation, and
`stirling.security.fileEncryptionKeyVersion` marks which master wrapped
each row. Runbook: set new key primary + old as previous + bump version
→ restart (startup self-check passes via fallback, warns about pending
rows) → `POST /master/rotate` → remove the previous key.
- **Shared state bean** — `StorageEncryptionState` is built once and
shared by the storage decorator and the admin API, so kill-switch cache
invalidation hits the same caches the decorator reads.
**Reviewer notes**
- The revoked→403 mapping promised for PR2 already landed in #7155 after
manual testing; this PR adds the matching `decrypt.denied` audit event.
- 19 new tests: audit emission (encrypt/decrypt/denied, legacy plaintext
emits nothing), kill-switch immediacy (no TTL wait), rotation
(previous-key fallback, re-wrap + cleanup, idempotent second call),
migration (backlog encrypted byte-identical, CAS-miss discards own copy,
per-file failure counting, concurrent-start rejection, write-disabled
rejection), admin controller status/conflict/not-found paths.
- Full proprietary suite: 2246/2247 green (the one failure is the
pre-existing Windows-symlink FolderIdentitiesTest, unrelated).
---
[ENCRYPTION_AT_REST_TEST_REPORT.html](https://github.com/user-attachments/files/30664158/ENCRYPTION_AT_REST_TEST_REPORT.html)
---------
Co-authored-by: Reece Browne <74901996+reecebrowne@users.noreply.github.com>
|
||
|
|
05eb74022a |
chore(ci): migrate Python tooling to uv and standardize workflow execution (#7386)
# Description of Changes This PR modernizes the project's Python tooling across GitHub Actions by migrating CI workflows from pip-based dependency management to `uv` and aligning Python execution with the engine project's managed environment. ### What was changed - Replaced `actions/setup-python` and ad-hoc `pip install` steps with `astral-sh/setup-uv` across CI workflows. - Configured shared `uv` dependency caching using `engine/pyproject.toml` and `engine/uv.lock`. - Updated Python script execution to use `uv run --project engine --locked` for a consistent runtime environment. - Replaced package installation steps with `uv sync` for the required dependency groups (e.g. `tools` and `cucumber`). - Added Docker image build validation for both production and development AI engine images. - Updated workflow cache configuration and Docker build context where required. - Removed obsolete Python requirements files that are no longer needed after the migration. - Applied minor Python code modernizations, including import cleanup, modern built-in generic type annotations (`list[...]`, `tuple[...]`, `float | None`), and small style improvements. - Removed unnecessary Python formatter/linter extensions from the development container configuration. ### Why the change was made - Standardize Python dependency management across the repository. - Reduce duplicated dependency installation logic in CI. - Improve workflow performance through shared dependency caching. - Ensure all Python utilities execute against the same locked dependency set managed by the engine project. - Simplify long-term maintenance by eliminating legacy requirements files and pip-specific workflow steps. --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. --------- Signed-off-by: Carsten Drewes <c.drewes@stud.uni-hannover.de> Co-authored-by: albanobattistella <34811668+albanobattistella@users.noreply.github.com> Co-authored-by: kastenherri <116314318+kastenherri@users.noreply.github.com> Co-authored-by: Anthony Stirling <77850077+Frooodle@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: James Brunton <jbrunton96@gmail.com> |
||
|
EthanHealy01
|
c929386442 |
Record policy-run failures as durable, actionable events (Review Flow PR 1) (#7269)
# Description of Changes PR 1 of the failure-notification work: a durable, team-scoped record of **why a policy run failed**, surfaced in the portal with the triage actions each failure allows. Today a failed policy run is not quite invisible, but it is unusable: the ledger marks the file `ERROR`, and the audit aspect keeps the exception message and status code. Nothing classifies either one, nothing surfaces them, and neither offers a next step. If the file came from a folder, bucket or webhook there is also no user watching, so nobody learns it never made it through. This adds the record and the read surface; the remediation that acts on documents comes later (see below). ## What this does **A failure kind registry as data.** `FailureKind` describes what can go wrong: a stable wire id, i18n keys, an English fallback, and four facets the review surface needs (`Stage`, `Severity`, `Remedy`, `Scope`). It is shaped like the existing `ExceptionUtils.ErrorCode` and *links* to that vocabulary rather than replacing it. **Classification off structured codes, not message matching.** Policy steps dispatch over loopback HTTP, so a tool's 4xx arrives as a `RestClientResponseException` whose body is the Problem Details document carrying `errorCode`. `FailureClassifier` reads that. Anything unrecognised becomes `UNKNOWN`, which is the point: every failed run gets an addressable record from day one, and which kinds to promote next is answered by production frequency rather than guesswork. **Actions declared by a kind, implemented as beans.** A kind lists the `FailureActionId`s it offers; behaviour lives in `FailureAction` beans resolved by id — the idiom this codebase already uses for `InputSource`, `PolicyOutputSink` and `PolicyTrigger`. A kind cannot be sent an action it never declared (400), so an incoherent pairing is unreachable rather than merely unrendered. A new kind ships as a registry entry plus copy: no new endpoint, no UI change. **Repeat folding.** Recording folds a genuine repeat into the existing incident instead of inserting again, keyed on `(team_id, dedup_key)`. That matters for a snapshot-mode source that re-lists every file on each sweep: the same broken file is one incident, not one per sweep. Distinct files keep distinct rows. The unique constraint is enforced by the database, and a writer that loses the insert race folds into the winner's row. One granularity caveat worth naming: nothing populates `file_id` in this PR, so every row has it NULL. A FILE-scoped kind therefore dedups on `policy + run` rather than `policy + file`. That still yields one row per document for the sources shipped here, because the folder, S3 and webhook sources each start one run per file; it stops holding as soon as a single run carries several documents, which is why editor-origin reporting (item 3 below) populates `file_id`. **No document identity is stored.** No file name, no content. `fileId` is an opaque reference only the owner's own client can resolve locally. `detail` keeps the raw message (the only diagnostic an `UNKNOWN` failure has) with anything path- or filename-shaped stripped on the way in, capped at 2,000 characters. `PolicyExecutor`'s type-mismatch message now reports the *extension* rather than the filename, since that message becomes the stored `detail`. **Access.** Reads and triage are leader-only, gated exactly the way `PolicyController` gates policy editing, with the single-user carve-out when login is disabled. Every read and write is scoped to the caller's own team from the authenticated principal — there is no team parameter on the API. Self-hosted needs no migration: the table is created from the entity by `ddl-auto=update`, as with every other table. ## What this does not do yet - **Actions are incident dispositions, not document dispositions.** Acknowledge and Dismiss change how a failure is displayed and touch nothing else — not the document, not the processed-file ledger, not the run, not any output destination. That is what makes them safe to offer against `UNKNOWN`, and why there is no Approve/Release yet. - **Two kinds only.** `INPUT_PASSWORD_PROTECTED` and `UNKNOWN`. Everything else classifies as `UNKNOWN` and shows its raw message. - **Editor-origin failures are not reported.** Every row is `PROCESSOR`. `FailureOrigin.EDITOR` and `API` exist in the enum but nothing writes them. - **The list is dev-only for now.** The section renders behind `import.meta.env.DEV`, so it ships in no production bundle. The endpoints are live and gated. - **No retention or per-team cap** on `file_run_events`. Tracked separately. - **No suspend-and-prompt.** `PolicyInputRequiredException` and the engine's `suspend()` exist but nothing throws it, so a run cannot pause to ask for a password today. - **SaaS needs a migration** in `Stirling-PDF-SaaS` (`CREATE TABLE IF NOT EXISTS stirling_pdf.file_run_events`), per the convention documented at `app/saas/src/main/resources/application-saas.properties:21`. ## What follows in later PRs 1. **Map the remaining error codes to specific kinds** — corrupted file, OCR unavailable, output destination unreachable, entitlement refusals, and so on — each with its own copy and its own action set, replacing today's `UNKNOWN` catch-all with a named notification in the review UI. 2. **Real remediation actions** attached to those kinds: fix (supply a password and resume), skip (drop this file, continue the batch), and decline (reject an incoming file outright), acting on the held document rather than only on the incident row. This is where the suspend-and-prompt path gets wired. 3. **Editor-origin reporting**, so a failure a user hits in the editor lands in the same queue as one from a bucket. 4. **The user-facing review surface**: notifications with a sticky review section, per-file badges, and an export gate, with the dev-only list here replaced by the real thing. ## How to test Needs a SaaS or proprietary build with login enabled, and an account that leads a team. 1. Create a policy in the Processor with any step (Auto-redact is fine) and a source you can drop files into. 2. Upload two files that will fail it: **a password-protected PDF**, and **a corrupted PDF** (truncate a valid one, or rename a `.csv` to `.pdf`). 3. Let the policy run and fail on both. 4. Go to the portal's **Documents** view and scroll to **Failures** (dev builds only). Expect two rows: - **Password-protected document** — classified from `E004`, with the kind's own labels **"I'll unlock this"** and **"Skip this file"** rather than generic wording. - **Unrecognised failure** — the corrupted file, classified `UNKNOWN` (`E001` is not claimed by a kind yet), showing its raw message with generic **Acknowledge** / **Dismiss**. Neither row contains a file name anywhere, including in the raw message. Press **Show raw JSON** to read exactly what the server returned. Acting on a row transitions it and comes back with both buttons disabled and a reason. Re-running the same batch increments the occurrence count on the existing rows rather than adding new ones; two *different* password-protected files produce two separate rows. --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass |
||
|
Anthony Stirling
|
59ed4f5fd1 |
Fix automate unrunnable tools (#7311)
# Description of Changes Fix automate unrunnable tools ## Problem - Remove Image failed in Automate with `Tool operation not supported: removeImage` - Its registry entry had `operationConfig: undefined` even though the config existed and was already tested - The Automate picker only filtered on `supportsAutomate`, never on `operationConfig` — so broken tools were selectable and failed only at run time ## Fixes - Wire up `removeImage` and `pageLayout` operation configs (both already existed, just never registered) - Exclude `validateSignature` (report tool, not on the operationConfig seam) and `scannerEffect` (no frontend implementation) via `supportsAutomate: false` - Picker now also filters on `operationConfig`, so this class of bug can't reach users again - `overlay-pdfs` returns 400 instead of 500 when overlay files or mode are missing - Fix `new URL().pathname` Windows path bug that stopped 2 test suites from loading --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
James Brunton
|
af5f54274d |
Add defaults to calculations for ToolIO (#7289)
# Description of Changes Currently when calculating the output file type for some tools, the system will get it wrong because it doesn't know about what the default parameters in tools are, so if it doesn't have a value for some key, it'll just bail out and say "it might not be compatible". This PR adds logic to `ToolIO` to read the default values set for the parameters if the tool has `ToolIOCase`s and takes them into account when figuring out the output type. I've built it with horrible Java reflection magic to avoid having to specify the default for params twice, which will make it impossible for the defaults to disagree with each other. This just runs once at startup so there's negligible performance impact. The change is easily tested with Change Parameters, which is just `add-password` behind the scenes but with the password params omitted (so Change Password is always PDF->PDF, never encrypted like Add Password). Also (somewhat hackily) fixes a bug I noticed where saving a Change Permissions step then leaving and returning to the pipeline will cause the step to be reloaded as Add Password. I've added a system to disambiguate tools which share the same endpoint (which is only these two currently). ## Currently <img width="455" height="135" alt="image" src="https://github.com/user-attachments/assets/c8867d6a-599b-4f21-a2db-4a1b6ac22d73" /> ## Now <img width="415" height="122" alt="image" src="https://github.com/user-attachments/assets/bd8d1bab-f00a-421b-8c91-5af0d2ad5335" /> |
||
|
brios
|
4e901f7524 |
refactor(package): rename example classes and update package structure (#7400)
# Description of Changes Refactors a small set of previously vendored/derived PDFBox "example" classes into Stirling’s own package namespaces. <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [X] I have performed a self-review of my own code - [X] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [X] I have run `task check` to verify linters, typechecks, and tests pass - [X] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
Ludy
|
0c0a96aa83 |
build(deps): bump org.simplejavamail from 8.12.0 to 9.2.0 (#7398)
Bump org.simplejavamail:simple-java-mail and outlook-module from 8.12.6 to 9.2.0 in app/common/build.gradle. Add a Dependabot group for the org.simplejavamail artifacts in .github/dependabot.yml so updates for those packages are grouped into a single PR. --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
dependabot[bot]
|
6d08cb2f52 |
build(deps): bump com.drewnoakes:metadata-extractor from 2.20.0 to 2.21.0 (#7338)
Bumps [com.drewnoakes:metadata-extractor](https://github.com/drewnoakes/metadata-extractor) from 2.20.0 to 2.21.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/drewnoakes/metadata-extractor/releases">com.drewnoakes:metadata-extractor's releases</a>.</em></p> <blockquote> <h2>2.21.0</h2> <h2>What's Changed</h2> <ul> <li>Replace custom number formatting in IccDescriptor with String.format by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/721">drewnoakes/metadata-extractor#721</a></li> <li>Fix OOM DoS vector in BmpHeaderDescriptor.formatHex via unbounded digits parameter by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/722">drewnoakes/metadata-extractor#722</a></li> <li>Normalize sign to numerator in Rational.toString() by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/724">drewnoakes/metadata-extractor#724</a></li> <li>Extract IPTC metadata from PNG text chunks by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/723">drewnoakes/metadata-extractor#723</a></li> <li>Tolerate duplicate PNG chunks that are not allowed to appear multiple times by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/725">drewnoakes/metadata-extractor#725</a></li> <li>Null-check and length-guard getPowerUpTimeDescription by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/727">drewnoakes/metadata-extractor#727</a></li> <li>Move DisposalMethod description logic to GifControlDescriptor by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/729">drewnoakes/metadata-extractor#729</a></li> <li>Port .NET RiffReader.processChunks error checking to Java by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/728">drewnoakes/metadata-extractor#728</a></li> <li>Fix NPE in ItemLocationBox when offset_size/length_size is 0 (valid AVIF) by <a href="https://github.com/hanskr"><code>@hanskr</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/732">drewnoakes/metadata-extractor#732</a></li> <li>Harden ICO parsing against oversized image counts by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/734">drewnoakes/metadata-extractor#734</a></li> <li>Support LONG8 and SLONG8 TIFF data formats by <a href="https://github.com/dschmidt"><code>@dschmidt</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/739">drewnoakes/metadata-extractor#739</a></li> <li>Detect QuickTime files that lack a leading ftyp box by <a href="https://github.com/dschmidt"><code>@dschmidt</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/736">drewnoakes/metadata-extractor#736</a></li> <li>Add basic MP4 udta metadata (Title, Comment, Subtitle, Rating, Category, Mood) by <a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/740">drewnoakes/metadata-extractor#740</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/drewnoakes"><code>@drewnoakes</code></a> with <a href="https://github.com/Copilot"><code>@Copilot</code></a> made their first contribution in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/721">drewnoakes/metadata-extractor#721</a></li> <li><a href="https://github.com/hanskr"><code>@hanskr</code></a> made their first contribution in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/732">drewnoakes/metadata-extractor#732</a></li> <li><a href="https://github.com/dschmidt"><code>@dschmidt</code></a> made their first contribution in <a href="https://redirect.github.com/drewnoakes/metadata-extractor/pull/739">drewnoakes/metadata-extractor#739</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/drewnoakes/metadata-extractor/compare/2.20.0...2.20.1">https://github.com/drewnoakes/metadata-extractor/compare/2.20.0...2.20.1</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/6f037943c0811799a59b0ea19896cb2b07da17be"><code>6f03794</code></a> Merge pull request <a href="https://redirect.github.com/drewnoakes/metadata-extractor/issues/740">#740</a> from drewnoakes/dev/drnoakes/mp4-metadata-pr-review</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/d01cc419eea457b8d482f864d1f1bbacee834828"><code>d01cc41</code></a> Detect QuickTime files that lack a leading ftyp box (<a href="https://redirect.github.com/drewnoakes/metadata-extractor/issues/736">#736</a>)</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/1b45d70723192a02bde7626d6e011081d52c3592"><code>1b45d70</code></a> Support LONG8 and SLONG8 TIFF data formats</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/353e27c37c414702e92304a4067de96bb383def1"><code>353e27c</code></a> Address Copilot review: align entry parsing and fix tag name casing</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/31632d2d70497333e5aa71401323f17e0f6d515a"><code>31632d2</code></a> Clean up salvaged MP4 udta metadata code</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/845cdbab9a8f1348c52b1b4e10a6f774929ba303"><code>845cdba</code></a> Add more UDTA metadata to MP4 parser (Title, Comment, Subtitle, Rating, Categ...</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/5647ffd0541279bc488f6387ea91aa3c785de36b"><code>5647ffd</code></a> Harden ICO parsing against oversized image counts (<a href="https://redirect.github.com/drewnoakes/metadata-extractor/issues/734">#734</a>)</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/99383f6d345dfa9a72e0780c37876a8ebd31ce31"><code>99383f6</code></a> Merge pull request <a href="https://redirect.github.com/drewnoakes/metadata-extractor/issues/732">#732</a> from hanskr/fix-iloc-zero-offset-size-npe</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/35af34ae39dec240e1e0a1bded0161f6f86df38e"><code>35af34a</code></a> Fix NPE in ItemLocationBox when offset_size/length_size is 0</li> <li><a href="https://github.com/drewnoakes/metadata-extractor/commit/520e07fed8167863e2245f67d2622f9bb473d017"><code>520e07f</code></a> Merge pull request <a href="https://redirect.github.com/drewnoakes/metadata-extractor/issues/728">#728</a> from drewnoakes/copilot/enhance-error-checking-riffre...</li> <li>Additional commits viewable in <a href="https://github.com/drewnoakes/metadata-extractor/compare/2.20.0...2.21.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Anthony Stirling
|
2cf6db99ce |
Fix timing-fragile Valkey rate-limit boundary test (#7302)
# Description of Changes Fix timing-fragile Valkey rate-limit boundary test --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
