[PR #2471] [MERGED] fix: return all documents from V1 API regardless of folder #2326

New issue

Closed

opened 2026-02-26 20:33:24 +03:00 by kerem · 0 comments

kerem commented

2026-02-26 20:33:24 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/documenso/documenso/pull/2471
Author: @ephraimduncan
Created: 2/11/2026
Status: ✅ Merged
Merged: 2/26/2026
Merged by: @Mythie

Base: main ← Head: feat/add-folder-support-to-v1-api

📝 Commits (2)

8a5859c fix: return all documents from V1 API regardless of folder
7516738 chore: dont skip folderId

📊 Changes

3 files changed (+218 additions, -0 deletions)

View changed files

➕ .agents/plans/wild-teal-wind-add-folder-support-to-v1-api.md (+210 -0)
📝 packages/api/v1/implementation.ts (+3 -0)
📝 packages/api/v1/schema.ts (+5 -0)

📄 Description

Summary

The GET /api/v1/documents endpoint only returned root-level documents, silently hiding any documents placed in folders from API consumers. This also adds folderId to both the list and single-document response schemas.

Problem

findDocuments() defaults folderId to null when no value is provided, meaning only root-level documents are returned. The V1 API never passed folderId, so folder documents were invisible. Neither endpoint exposed folderId in the response, so consumers couldn't know which folder a document belonged to.

Changes

packages/api/v1/schema.ts — Add optional folderId query param to ZGetDocumentsQuerySchema. Add folderId: z.string().nullish() to ZSuccessfulDocumentResponseSchema (inherited by ZSuccessfulGetDocumentResponseSchema).
packages/api/v1/implementation.ts — getDocuments passes folderId and skipFolderFilter to findDocuments() and includes folderId in the list response. getDocument includes folderId in the single-document response.
packages/lib/server-only/document/find-documents.ts — Add skipFolderFilter?: boolean to FindDocumentsOptions. When true, the folder WHERE clause is skipped entirely, returning all documents. Existing callers are unaffected since they don't pass this flag.

Behavior

Request	Before	After
`GET /api/v1/documents`	Root docs only	All docs (root + folders)
`GET /api/v1/documents?folderId=abc`	Not supported	Docs in folder `abc` only
`GET /api/v1/documents?folderId=nonexistent`	Not supported	Empty array, 200 OK
`GET /api/v1/documents/:id` response	No `folderId` field	Includes `folderId`

Breaking Change

GET /api/v1/documents now returns more documents than before. This is intentional — the previous behavior was a bug that silently hid folder documents from API consumers. The new folderId response field is additive and won't break existing response parsing.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/documenso/documenso/pull/2471 **Author:** [@ephraimduncan](https://github.com/ephraimduncan) **Created:** 2/11/2026 **Status:** ✅ Merged **Merged:** 2/26/2026 **Merged by:** [@Mythie](https://github.com/Mythie) **Base:** `main` ← **Head:** `feat/add-folder-support-to-v1-api` --- ### 📝 Commits (2) - [`8a5859c`](https://github.com/documenso/documenso/commit/8a5859c1b5281dfbd1891a8ac17ba55385257e25) fix: return all documents from V1 API regardless of folder - [`7516738`](https://github.com/documenso/documenso/commit/75167388529c0d01268a61bfe788779a7ef5238a) chore: dont skip folderId ### 📊 Changes **3 files changed** (+218 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `.agents/plans/wild-teal-wind-add-folder-support-to-v1-api.md` (+210 -0) 📝 `packages/api/v1/implementation.ts` (+3 -0) 📝 `packages/api/v1/schema.ts` (+5 -0) </details> ### 📄 Description ## Summary The `GET /api/v1/documents` endpoint only returned root-level documents, silently hiding any documents placed in folders from API consumers. This also adds `folderId` to both the list and single-document response schemas. ## Problem `findDocuments()` defaults `folderId` to `null` when no value is provided, meaning only root-level documents are returned. The V1 API never passed `folderId`, so folder documents were invisible. Neither endpoint exposed `folderId` in the response, so consumers couldn't know which folder a document belonged to. ## Changes - **`packages/api/v1/schema.ts`** — Add optional `folderId` query param to `ZGetDocumentsQuerySchema`. Add `folderId: z.string().nullish()` to `ZSuccessfulDocumentResponseSchema` (inherited by `ZSuccessfulGetDocumentResponseSchema`). - **`packages/api/v1/implementation.ts`** — `getDocuments` passes `folderId` and `skipFolderFilter` to `findDocuments()` and includes `folderId` in the list response. `getDocument` includes `folderId` in the single-document response. - **`packages/lib/server-only/document/find-documents.ts`** — Add `skipFolderFilter?: boolean` to `FindDocumentsOptions`. When true, the folder WHERE clause is skipped entirely, returning all documents. Existing callers are unaffected since they don't pass this flag. ## Behavior | Request | Before | After | |---|---|---| | `GET /api/v1/documents` | Root docs only | All docs (root + folders) | | `GET /api/v1/documents?folderId=abc` | Not supported | Docs in folder `abc` only | | `GET /api/v1/documents?folderId=nonexistent` | Not supported | Empty array, 200 OK | | `GET /api/v1/documents/:id` response | No `folderId` field | Includes `folderId` | ## Breaking Change `GET /api/v1/documents` now returns more documents than before. This is intentional — the previous behavior was a bug that silently hid folder documents from API consumers. The new `folderId` response field is additive and won't break existing response parsing. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-02-26 20:33:24 +03:00

closed this issue
added the
pull-request
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#2326

No description provided.

Rows
Columns