GrottoCenter / grottocenter-api / 41425829662

91%

push

github

fix(document): accept page offsets on new PDFs with padded extensions (#1955)

## 🤔 What

- `DocumentService.findPdfExtensions()` now trims and lowercases `t_file_format.extension` before adding it to the set of PDF extensions, and drops empty values.
- New regression tests in `test/integration/4_routes/Documents/pdf-page-offset.test.js` run with the extension column switched to production's `bpchar(12)`.

Closes #1955

## 🤷‍♂️ Why

Uploading a new PDF with a page offset, at creation or on an update, failed with:

```text
Bad request: newFilesMetadata[0][pdfPageOffset] is only allowed for a PDF file, not for "lpu339_anonyme.pdf".
```

In production `t_file_format.extension` is a fixed-width `bpchar(12)`, so the PDF format comes back as `'pdf         '`. `isPdfFileName()` compared the file's `pdf` extension against that padded value and never matched. Offsets on existing files were not affected: that check compares the trimmed MIME type.

The test database is built by Waterline, which declares the column as `text`, and the fixture holds `'pdf'`, so the existing tests could not catch it.

## 🔍 How

- Normalize the extensions once when building the set: `format.extension?.trim().toLowerCase()`, then `.filter(Boolean)`. The filename side was already lowercased.
- The new `with padded file-format extensions (#1955)` block changes the test column to `bpchar(12)` in `before`, checks that the PDF format now reads back as `'pdf         '`, and restores the original type (with `rtrim`) in `after`. Inside it:
  - creation accepts `0`, `7` and `-126` offsets on a new PDF and stores them;
  - an update accepts `0` and `-3` offsets on a new PDF and keeps them on the pending row;
  - an offset on a new `.txt` file is still rejected with 400, at creation and on update.

No migration, endpoint or Swagger change.

## 🧪 Testing

- The new tests fail without the fix: the 5 PDF cases get 400 instead of 200, and the 2 non-PDF rejection cases pass.
- With the fix, `pdf-page... (continued)

6375 of 7420 branches covered (85.92%)

Branch coverage included in aggregate %.

1 of 1 new or added line in 1 file covered. (100.0%)

11699 of 12755 relevant lines covered (91.72%)

229693.72 hits per line