The signature feature used a named-preset dropdown, inconsistent with how the supplier profile works (one saved profile, loaded automatically for new invoices). This made saving/reusing a signature more cumbersome than it needed to be.
What changed
Replaced the signature_presets (multiple named signatures) model with a single signature_profiles row per user, mirroring supplier_profiles.
New /api/signature GET/PUT/DELETE endpoints replace /api/signature-presets.
db.js migrates any existing preset data into the new table on startup (keeps the most recently created preset per user), so no signatures are lost.
Frontend: removed the "Uložený podpis" dropdown and preset name field; added "Uložit podpis" / "Načíst uloženého" buttons like the supplier section. The saved signature now auto-loads when starting a new invoice.
Removed now-unused .signature-save-row CSS.
Notes for reviewers
The legacy signature_presets table is left in place (not dropped) purely as the source for the one-time migration into signature_profiles; it's no longer written to going forward.
Verified with npm test (4 passing) and a syntax check of the edited JS files.
## Why
The signature feature used a named-preset dropdown, inconsistent with how the supplier profile works (one saved profile, loaded automatically for new invoices). This made saving/reusing a signature more cumbersome than it needed to be.
## What changed
- Replaced the `signature_presets` (multiple named signatures) model with a single `signature_profiles` row per user, mirroring `supplier_profiles`.
- New `/api/signature` GET/PUT/DELETE endpoints replace `/api/signature-presets`.
- `db.js` migrates any existing preset data into the new table on startup (keeps the most recently created preset per user), so no signatures are lost.
- Frontend: removed the "Uložený podpis" dropdown and preset name field; added "Uložit podpis" / "Načíst uloženého" buttons like the supplier section. The saved signature now auto-loads when starting a new invoice.
- Removed now-unused `.signature-save-row` CSS.
## Notes for reviewers
- The legacy `signature_presets` table is left in place (not dropped) purely as the source for the one-time migration into `signature_profiles`; it's no longer written to going forward.
- Verified with `npm test` (4 passing) and a syntax check of the edited JS files.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
The signature feature used a named-preset dropdown, inconsistent with how the supplier profile works (one saved profile, loaded automatically for new invoices). This made saving/reusing a signature more cumbersome than it needed to be.
What changed
signature_presets(multiple named signatures) model with a singlesignature_profilesrow per user, mirroringsupplier_profiles./api/signatureGET/PUT/DELETE endpoints replace/api/signature-presets.db.jsmigrates any existing preset data into the new table on startup (keeps the most recently created preset per user), so no signatures are lost..signature-save-rowCSS.Notes for reviewers
signature_presetstable is left in place (not dropped) purely as the source for the one-time migration intosignature_profiles; it's no longer written to going forward.npm test(4 passing) and a syntax check of the edited JS files.