- AD prefill: 'Din cont' button pre-fills name + company from Authentik session
- Logo size slider: 50%-200% scale control in Stil & Aranjare section
- Promotional banner: configurable image+link below signature with preview
- US/SDT custom graphics: dedicated dash (US) and dot (SDT) decorative icons
replacing Beletage's grey/accent slashes for company-specific branding
- Remove 'initials' type, expirationDate, legalStatus, usageNotes fields
- Add subcategory field with creatable input + 6 default categories
- Add TIFF upload support with client-side utif2 decode for preview
- Store original TIFF data separately for faithful downloads
- Add download dropdown: Original file, Word (.docx), PDF (.pdf)
- Group assets by subcategory in list view
- Add subcategory filter in search bar
- Install docx, jspdf, utif2 packages
- Closes 3.07
The client-side migration was downloading 25-50MB of base64 data to the
browser before showing anything. getAllEntries also lost its lightweight flag.
Fix:
- New POST /api/storage/migrate-blobs endpoint runs entirely server-side
(loads entries one-at-a-time from PostgreSQL, never sends heavy data to browser)
- Restore lightweight:true on getAllEntries (strips remaining base64 in API)
- Migration fires on mount (fire-and-forget) while list loads independently
- Remove client-side migrateEntryBlobs function
Replace complex prisma.\ with simple Prisma findMany + JS stripping.
Now that entries are inherently small (base64 in separate blob namespace),
JS-based stripping is instant. Also fix migration to check flag before loading.
Root cause: even with SQL-level stripping, PostgreSQL must TOAST-decompress
entire multi-MB JSONB values from disk before any processing. For 5 entries
with PDF attachments (25-50MB total), this takes several seconds.
Fix: store base64 attachment data in separate namespace 'registratura-blobs'.
Main entries are inherently small (~1-2KB). List queries never touch heavy data.
Changes:
- registry-service.ts: extractBlobs/mergeBlobs split base64 on save/load,
migrateEntryBlobs() one-time migration for existing entries
- use-registry.ts: dual namespace (registratura + registratura-blobs),
migration runs on first mount
- registratura-module.tsx: removed useContacts/useTags hooks that triggered
2 unnecessary API fetches on page load (write-only ops use direct storage)
Before: 3 API calls on mount, one reading 25-50MB from PostgreSQL
After: 1 API call on mount, reading ~5-10KB total
Previous fix stripped data in Node.js AFTER Prisma loaded the full JSON
from PostgreSQL. For 5 entries with PDF attachments, this still meant
25-50MB transferring from DB to Node.js on every page load.
Now uses prisma.\ with nested jsonb_each/jsonb_object_agg to
strip data/fileData/imageUrl strings >1KB inside the database itself.
Heavy base64 never leaves PostgreSQL when lightweight=true.
ROOT CAUSE: RegistryEntry stores file attachments as base64 strings in JSON.
A single 5MB PDF becomes ~6.7MB of base64. With 6 entries, the exportAll()
endpoint was sending 30-60MB of JSON on every page load taking 2+ minutes.
Fix: Added ?lightweight=true parameter to /api/storage GET endpoint.
When enabled, stripHeavyFields() recursively removes large 'data' and
'fileData' string fields (>1KB) from JSON values, replacing with '__stripped__'.
Changes:
- /api/storage route.ts: stripHeavyFields() + lightweight query param
- StorageService.export(): accepts { lightweight?: boolean } option
- DatabaseStorageAdapter.export(): passes lightweight flag to API
- LocalStorageAdapter.export(): accepts option (no-op, localStorage is fast)
- useStorage.exportAll(): passes options through
- registry-service.ts: getAllEntries() uses lightweight=true by default
- registry-service.ts: new getFullEntry() loads single entry with full data
- use-registry.ts: exports loadFullEntry() for on-demand full loading
- registratura-module.tsx: handleEdit/handleNavigateEntry load full entry
Result: List loading transfers ~100KB instead of 30-60MB. Editing loads
full data for a single entry on demand (~5-10MB for one entry vs all).
CRITICAL PERF BUG: Every hook did storage.list() (1 HTTP call fetching ALL
items with values, discarding values, returning only keys) then storage.get()
for EACH key (N individual HTTP calls re-fetching values one by one).
With 6 entries + contacts + tags, Registratura page fired ~40 sequential
HTTP requests on load, where 3 would suffice.
Fix: Replace list()+N*get() with single exportAll() call in ALL hooks:
- registratura/registry-service.ts (added exportAll to RegistryStorage interface)
- address-book/use-contacts.ts
- it-inventory/use-inventory.ts
- password-vault/use-vault.ts
- word-templates/use-templates.ts
- prompt-generator/use-prompt-generator.ts
- hot-desk/use-reservations.ts
- email-signature/use-saved-signatures.ts
- digital-signatures/use-signatures.ts
- ai-chat/use-chat.ts
- core/tagging/tag-service.ts (uses storage.export())
Additional fixes:
- registratura/use-registry.ts: addEntry uses optimistic local state update
instead of double-refresh; closeEntry batches saves with Promise.all +
single refresh
- server-rack.tsx: reversed slot rendering so U1 is at bottom (standard
rack numbering, per user's physical rack)
Performance impact: ~90% reduction in HTTP requests on page load for all modules
- Added ClosureInfo type with reason, closedBy, closedAt, linkedEntry, hadActiveDeadlines, attachment
- Rewrote close-guard-dialog into universal close dialog (always shown on close)
- Reason field (always required)
- Optional continuation entry search+link
- Optional closing document attachment (file upload)
- Active deadlines shown as warning banner when present
- Created ClosureBanner component (read-only, shown at top of closed entry edit)
- Shows who, when, why, linked entry (clickable), attached doc (downloadable)
- All closes now go through the dialog no more silent closeEntry
- Linked-entries sub-dialog preserved as second step
- Dynamic document types: string-based DocumentType synced with Tag Manager
(new types auto-create tags under 'document-type' category)
- Added default types: 'Apel telefonic', 'Videoconferinta'
- Bidirectional Address Book: quick-create contacts from sender/recipient/
assignee fields via QuickContactDialog popup
- Simplified status: Switch toggle replaces dropdown (default open)
- Responsabil (Assignee) field with contact autocomplete (ERP-ready)
- Entry threads: threadParentId links entries as replies, ThreadView shows
parent/current/children tree with branching support
- Info tooltips on deadline, status, and assignee fields
- New Resp. column and thread icon in registry table
- All changes backward-compatible with existing data
AI Assistant