GrottoCenter / grottocenter-api / 41804161769

91%

push

github

fix(entranceDuplicate): stamp the creation date when materializing a duplicate (#1802)

## 🤔 What

- `POST /api/v1/entrances/from-duplicate/:id` now creates the entrance, and its name, description and location, with `dateInscription` set to the time of the request. Before, they kept the date from the CSV import.
- `POST /api/v1/documents/from-duplicate/:id` gets the same fix for the document and its description.
- Both actions now log `Entrance duplicate <id> → entrance <id> by caver <id>` (or the document equivalent) after materializing a duplicate.

Closes #1802

## 🤷‍♂️ Why

A duplicate parked during a CSV import keeps the payload built at import time, including `dateInscription` taken from `dct:rights/dct:created`. The "not a duplicate" action replayed that payload as is. `EntranceService.createEntrance` only sets a date when none is given (`?? new Date()`), so the old date was kept. That gave a new row an ID from the current sequence but a `date_inscription` weeks older, which has happened once in production. `DocumentService.createDocument` passes `documentData` straight to `TDocument.create`, so the document path had the same latent bug.

Nothing logged which entity a duplicate became or who resolved it, so tracing the production case meant matching log lines across three weeks.

## 🔍 How

- In both `create-from-duplicate` controllers, the parked content is copied with `dateInscription` overwritten by one `new Date()` before it is passed to the service. The stored content is not changed, and neither is any other field, including `dateReviewed`.
- The fix sits in the controllers, not in `createEntrance` / `createDocument`. A direct CSV import still deliberately keeps the karstlink creation date, and these services also serve that path.
- The original import date is not stored in a separate field. Doing so would need a schema change, and the import provenance (`idDbImport`, `nameDbImport`) is still on the row. This can be a follow-up if the date ... (continued)

6506 of 7559 branches covered (86.07%)

Branch coverage included in aggregate %.

8 of 8 new or added lines in 2 files covered. (100.0%)

11983 of 13041 relevant lines covered (91.89%)

240538.54 hits per line