ATESZ Event Planner – Technikai API dokumentáció

Dokumentáció verzió:

A lenyíló lista segítségével választható az eredeti dokumentáció (v1) és a refaktorált frontend struktúrát bemutató dokumentáció (v2).

v1 dokumentáció

Dokumentáció célja

Ez az oldal a rendszer végpontjait nem csak felsorolja, hanem üzleti és technikai oldalról is elmagyarázza. A dokumentáció célja, hogy fejlesztés, karbantartás, átadás vagy bővítés közben egyértelműen látható legyen, melyik route mire szolgál, melyik frontend fájl használja, milyen adatokat vár, milyen választ ad vissza, és milyen hibákat vagy validációkat kell figyelembe venni.

Planner session mentés

Quote / CRM generálás

Dashboard summary

Naptár API

Hitelesítés

Upload / config route-ok

1. Rendszeráttekintés

A rendszer két fő entitás köré épül: a planner session és a quote. A planner session a teljes rendezvényadatlapot jelenti, amelyből JSON, PDF és ICS készül. A quote ettől külön életciklust kap, mert egy eseményhez több ajánlat, módosított ajánlat vagy follow-up dokumentum is tartozhat.

Planner modul

Eseményadatok, menetrend, zenei igények, technikai igények, pénzügyi és jóváhagyási mezők, PDF / ICS generálás.

CRM / Quote modul

Árajánlatok, accepted quote-ok, follow-up visszatöltés, quote PDF-ek és pénzügyi utókövetés.

A planner és a quote logika szétválasztása tudatos tervezési döntés. Ez teszi lehetővé, hogy a rendezvényadatlapok és az árajánlatok külön indexben, külön mappában és külön munkafolyamatban maradjanak.

2. Rendszertérkép

Ez a blokk gyors áttekintést ad a teljes alkalmazásról: melyik oldal mit csinál, melyik JavaScript fájl milyen szerepet tölt be, és a backend milyen fő tárolási pontokra dolgozik.

Frontend oldalak

main.html – planner fő űrlap
crm.html – árajánlat / CRM felület
dashboard.html – összesítő admin nézet
calendar.html – havi naptárnézet
dj-view.html – rendezvény DJ preview

Frontend JS modulok

app.js – planner logika
crm.js – quote logika
dashboard.js – admin dashboard
calendar.js – naptár
dj-view.js – preview és timeline

Backend

server.js – teljes route, PDF, index, template és storage logika
Express alapú kiszolgálás
PDFKit alapú dokumentumgenerálás
Multer alapú file upload

Tárolás

/data – planner session fájlok
/data/quotes – quote fájlok
/uploads – feltöltött képek
/public/templates – sablonok és payment config

Frontend oldalak és UI entrypointok

A rendszer több különálló HTML felülettel rendelkezik, amelyek mind saját JavaScript logikát töltenek be és különböző API végpontokkal kommunikálnak. Ezek az oldalak a rendszer belépési pontjai (entrypointok), és meghatározzák, hogy a felhasználó mely funkcionális modulhoz fér hozzá.

HTML oldal	Funkció	Fő JS fájl	Használt API-k	Felhasználói szerep
`index.html`	Planner wizard – eseményadatok rögzítése	`app.js`	`/api/sessions` `/api/upload` `/api/venues` `/api/autotimeline` `/api/conflicts` `/api/planner-accepted-quotes`	Admin / szervező
`crm.html`	CRM és ajánlatgeneráló felület	`crm.js`	`/api/quotes/generate` `/api/quotes` `/api/quote/:stamp`	Admin / értékesítés
`dashboard.html`	Rendszer dashboard és pénzügyi összesítés	`dashboard.js`	`/api/auth/dashboard` `/api/dashboard-summary`	Admin
`calendar.html`	Havi eseménynaptár és eseménylista	`calendar.js`	`/api/calendar`	Admin / DJ
`dj-view.html`	DJ esemény nézet (egyeztető lap)	`dj-view.js`	`/api/session/:stamp` `/api/auth/price-view`	DJ / technikai személyzet

Az egyes HTML oldalak különálló entrypointként működnek, ezért a hozzájuk tartozó JavaScript fájlok több helper függvényt saját példányban tartalmaznak. Ez jelenleg nem hiba, hanem a moduláris felépítés következménye. Későbbi refaktor során ezek közös utility modulba szervezhetők.

Frontend → Backend kommunikáció A HTML oldal betölt egy JS modult (pl. app.js), amely a felhasználói interakciók hatására HTTP kéréseket küld a backend API végpontokra.

Tipikus adatfolyam index.html → app.js → /api/sessions → JSON mentés → PDF generálás → ICS generálás → válasz a frontendnek.

Frontend moduláris logika Minden oldal csak a saját funkciójához szükséges API-kat használja. Ez csökkenti a kódfüggőségeket és egyszerűbbé teszi a későbbi fejlesztést vagy refaktorálást.

Rendszer architektúra – adatfolyam

Az alábbi diagram a rendszer fő komponenseit és az adatok áramlását mutatja. A cél nem az egyes endpointok részletezése, hanem a teljes működési modell áttekintése: hogyan jut el egy felhasználói művelet a frontend felülettől a backend feldolgozáson át a fájlrendszerben tárolt dokumentumokig.

1. Felhasználói felület (UI) A felhasználó egy HTML oldalon keresztül lép be a rendszerbe. Az egyes oldalak külön funkcionális modulokat képviselnek.


index.html        → planner wizard
crm.html          → ajánlat generálás
dashboard.html    → admin dashboard
calendar.html     → havi eseménynaptár
dj-view.html      → esemény egyeztető lap

2. Frontend logika Az oldalak saját JavaScript modulokat töltenek be, amelyek kezelik a felhasználói interakciókat és API hívásokat indítanak.


app.js        → planner logika
crm.js        → ajánlatgeneráló logika
dashboard.js  → dashboard statisztika
calendar.js   → naptár nézet
dj-view.js    → esemény preview

3. Backend API réteg A frontend HTTP kéréseket küld a backend szervernek, amely validálja az adatokat, feldolgozza a kérést és létrehozza vagy módosítja a szükséges fájlokat.


/api/sessions
/api/quotes/generate
/api/dashboard-summary
/api/calendar
/api/session/:stamp

4. Feldolgozási logika A backend több lépésben dolgozza fel a beérkező adatokat. A payload normalizálása után külön modulok készítik el a dokumentumokat.


payload normalizálás
↓
id / stamp generálás
↓
JSON rekord mentés
↓
PDF dokumentum generálás
↓
ICS naptárfájl generálás
↓
index fájl frissítés

5. Fájlrendszer alapú tárolás A rendszer adatbázis helyett strukturált fájlrendszert használ. Ez egyszerűbb deploy-t és könnyebb backup kezelést tesz lehetővé.


/data
  ├─ planner rekordok
  ├─ _index.json
  └─ _counters.json

/data/quotes
  ├─ quote JSON
  ├─ quote PDF
  └─ _quotes_index.json

/uploads
  └─ feltöltött képek

/public/templates
  └─ eseménysablonok

6. Válasz a frontendnek A backend a feldolgozás végén egy strukturált JSON választ küld vissza, amely tartalmazza az elkészült dokumentumok elérési útját.


{
  "ok": true,
  "stamp": "2026-05-14_kiss_nagy",
  "pdf": "/data/2026-05-14_kiss_nagy.pdf",
  "ics": "/data/2026-05-14_kiss_nagy.ics"
}

Ez az architektúra tudatosan egyszerű: a rendszer **stateless API + fájlrendszer alapú tárolás** elvre épül. Előnyei: • könnyű telepítés • egyszerű backup • gyors fejlesztés • nincs adatbázis függőség Hátránya: • nagyon nagy adatmennyiség esetén érdemes lehet később adatbázis alapú megoldásra váltani.

Teljes rendszer komponens diagram

Ez az ábra a rendszer fő komponenseit mutatja meg magas szinten. A cél itt nem az endpointok részletes felsorolása, hanem annak bemutatása, hogy a frontend oldalak, a JavaScript modulok, a backend logika és a fájlrendszer hogyan kapcsolódnak egymáshoz.

Felhasználó A rendszer használata mindig valamelyik frontend oldalon indul.

User
  ↓
HTML page

Frontend entrypointok Az egyes oldalak külön funkcionális belépési pontok.

index.html
crm.html
dashboard.html
calendar.html
dj-view.html

Frontend JavaScript réteg Minden HTML oldal saját JS modult használ, amely a UI logikát és az API kommunikációt kezeli.

index.html       → app.js
crm.html         → crm.js
dashboard.html   → dashboard.js
calendar.html    → calendar.js
dj-view.html     → dj-view.js

Express backend A backend központi belépési pontja a server.js, amely route-okat, PDF generálást, template kezelést, indexelést és fájlműveleteket kezel.

Frontend JS
   ↓
Express routes (server.js)
   ↓
Planner / Quote / Dashboard / Calendar logika

Backend belső alrendszerek A szerver logikailag több részre bontható, még ha fizikailag jelenleg egy fájlban is van.

Planner session kezelés
Quote / CRM kezelés
Dashboard aggregáció
Calendar aggregáció
Upload kezelés
Template rendszer
PDF generálás
ICS generálás
Index rebuild / index update

Tárolási réteg A rendszer nem adatbázisra, hanem strukturált fájlrendszerre épül.

/data
/data/quotes
/uploads
/public/templates
/public/venues.json

Dokumentumkimenetek A backend strukturált üzleti dokumentumokat és listafájlokat hoz létre.

Planner JSON
Planner PDF
Planner ICS
Quote JSON
Quote PDF
_index.json
_quotes_index.json
_counters.json

Ez a komponensdiagram jól mutatja, hogy a rendszer jelenleg monolitikus, de logikailag rétegezett. Ez kedvez a gyors fejlesztésnek, ugyanakkor később viszonylag könnyen szétbontható külön modulokra vagy service rétegekre.

Frontend → API dependency matrix

Ez a mátrix azt mutatja meg, hogy az egyes frontend modulok pontosan mely backend végpontoktól függenek. Ez különösen hasznos hibakeresésnél, refaktorálásnál vagy új funkciók tervezésénél.

Frontend modul	Függő API-k	Függőség típusa	Mi történik, ha az API hibás?
`app.js`	`GET /api/venues` `POST /api/venues` `GET /api/payment-transfer-config` `POST /api/upload` `GET /api/conflicts` `POST /api/autotimeline` `POST /api/sessions` `GET /api/sessions` `GET /api/session/:stamp` `DELETE /api/session/:stamp` `GET /api/stats` `GET /api/planner-accepted-quotes` `GET /api/planner-accepted-quote/:stamp`	erős függőség	A planner fő működése részlegesen vagy teljesen leáll.
`crm.js`	`GET /api/session/:stamp` `POST /api/quotes/generate` `GET /api/quotes` `GET /api/quote/:stamp` `DELETE /api/quote/:stamp`	erős függőség	Az ajánlatgenerálás és follow-up kezelés nem működik.
`dashboard.js`	`POST /api/auth/dashboard` `GET /api/dashboard-summary`	közepes függőség	A dashboard nem tölti be az összesítő adatokat.
`calendar.js`	`GET /api/calendar`	egypontos függőség	A naptár nézet üres vagy hibás lesz.
`dj-view.js`	`GET /api/session/:stamp` `POST /api/auth/price-view`	közepes függőség	A preview megjelenhet részben, de pénzügyi feloldás nélkül.

Miért hasznos ez a mátrix?

gyors hibaforrás-beazonosítás
frontend refaktor támogatása
API változtatások hatásvizsgálata
moduláris bővítés előkészítése

Technikai megfigyelés

A legerősebb backend függősége jelenleg az app.js-nek van, mert ez kezeli a legtöbb üzleti folyamatot: mentés, visszatöltés, feltöltés, validáció, accepted quote import, statisztika és konfliktusellenőrzés.

Refaktorálás során ez a blokk segít eldönteni, hogy mely frontend modulokat lehet a legkisebb kockázattal leválasztani, külön bundle-be szervezni vagy új UI keretrendszerre migrálni.

Planner lifecycle – rekord életciklus

Ez a blokk a planner rekord tipikus életciklusát mutatja meg. Nem alacsony szintű technikai állapotgépről van szó, hanem üzleti és működési nézetről: hogyan jön létre egy esemény, mikor módosul, milyen dokumentumok kapcsolódnak hozzá, és hogyan kerülhet törlésre.

1. Üres űrlap állapot A felhasználó megnyitja a planner oldalt, és egy új rekord létrehozására készül.

Állapot:
nincs mentett rekord
nincs stamp
nincs PDF / ICS

2. Template alapú előtöltés A felhasználó kiválaszthat sablont, vagy accepted quote-ból tölthet elő adatokat. Ez még nem jelent mentett rekordot, csak szerkesztési állapotot.

Űrlap előtöltve
↓
még nincs végleges mentés
↓
szerkeszthető állapot

3. Validált szerkesztési állapot A felhasználó kitölti a kötelező mezőket, beállítja a menetrendet, pénzügyeket, jóváhagyást.

Kötelező mezők kitöltve
↓
frontend validáció
↓
mentésre kész állapot

4. Mentett rekord A POST /api/sessions route létrehozza vagy frissíti a planner rekordot.

JSON mentés
↓
PDF generálás
↓
ICS generálás
↓
index frissítés

5. Visszatölthető állapot A rekord megjelenik a keresésekben, a naptárban, a dashboard összesítésekben és a DJ preview oldalon is.

GET /api/sessions
GET /api/session/:stamp
GET /api/calendar
GET /api/dashboard-summary

6. Módosított rekord Ugyanazzal a stamp-pel újramenthető a rekord, ezzel a JSON / PDF / ICS is frissül.

létező rekord
↓
űrlap visszatöltés
↓
adatok módosítása
↓
újramentés

7. Törölt rekord A DELETE /api/session/:stamp route törli a kapcsolódó fájlokat és indexbejegyzést.

JSON törlés
PDF törlés
ICS törlés
index frissítés

Kapcsolódó dokumentumok

planner JSON rekord
planner PDF dokumentum
ICS naptárfájl
feltöltött képek / aláírások

Kapcsolódó üzleti nézetek

planner keresőlista
dashboard összesítés
calendar havi nézet
DJ preview

A planner rekord életciklusa nem lineáris, mert egy mentett esemény többször is módosítható. Gyakorlatilag egy újraírható dokumentum-alapú entitásról van szó, amelyhez minden mentéskor újragenerált kimenetek tartoznak.

3. Fájlszerkezet

PUBLIC_DIR/                         → frontend HTML / JS / CSS / template fájlok
PUBLIC_DIR/templates/               → eseménysablonok + payment-transfer.json
PUBLIC_DIR/venues.json              → helyszínek forrásfájlja
DATA_DIR/                           → planner session mentések
DATA_DIR/_index.json                → planner index
DATA_DIR/_counters.json             → quote sorszámozási számláló
DATA_DIR/quotes/                    → quote JSON és PDF fájlok
DATA_DIR/quotes/_quotes_index.json  → quote index
UPLOADS_DIR/                        → feltöltött képek, jegyzetek, aláírások

Miért jó az indexfájl?

Gyors listázást ad a frontendnek, így nem kell minden keresésnél egyenként végigolvasni az összes rekordfájlt.

Miért jó az atomic írás?

A JSON / PDF / ICS ideiglenes fájlba íródik, majd átneveződik. Ez csökkenti a félig elkészült sérült állományok kockázatát.

4. Helper függvények

A backend és a frontend több olyan segédfüggvényt használ, amelyek nem önálló üzleti végpontok, mégis kulcsszerepet játszanak a működésben. Ezek biztosítják az egységes névformázást, dátumkezelést, indexelést, pénzügyi számítást és dokumentum-előkészítést.

Backend helper-ek

safeSlug() – biztonságos fájlnév-részlet képzése
loadCounters() – quote számlálók betöltése
saveCounters() – quote számlálók mentése
nextQuoteNumber() – új quote sorszám generálása
normalizeQuotePayload() – quote mezők egységesítése
makeQuoteStamp() – quote fájlnév-stamp készítése
loadQuoteIndex() / saveQuoteIndex()
makeQuoteIndexEntry() – quote index rekord készítése
rebuildQuoteIndexFromFiles() – quote index újraépítése
upsertQuoteIndexEntry() – quote index frissítése
normalizeDate() – dátum egységesítése YYYY-MM-DD formára
fileStamp() – egyedi stamp létrehozása név + dátum alapján
writeJsonAtomic() – JSON biztonságos, atomikus mentése
readJson() – JSON fájl olvasása
normalizeText()
normalizeArray()
toIntOrNull()
toFloatOrZero()
formatMoney()
toBool()
pad2()
isValidTime()
addMinutesToTime()
escapeICS()
replaceFileAtomic() – ideiglenes fájl véglegesítése
safeUnlink() – biztonságos fájltörlés
ensureVenuesFile()
loadVenuesFile()
saveVenuesFile()
addVenueToFile()
ensureTemplateFiles()
ensurePaymentTransferFile()
loadPaymentTransferConfig()
buildAutoTimeline() – automatikus időpont-kalkuláció
generateICS() – ICS generálás
loadIndex() / saveIndexAtomic()
makeIndexEntryFromRecord() – planner index rekord készítése
rebuildIndexFromFiles() – planner index újraépítése
upsertIndexEntry() – planner index frissítése
includesCI()
filterIndexItems()
findConflictsByDate()
setBaseFont(), moveToContentStart()
ensureSpace(), ensureSectionSpace()
startSection(), drawHeader()
titleLine(), kvInline(), divider()
drawTable()
eventTypeLabelHu()
paymentStatusLabelHu()
effectListText()
getExtraServiceFees()
generatePdf()
generateQuotePdf()

Frontend helper-ek

escapeHtml() – biztonságos HTML kiírás
$() – elemlekérés
getModalRefs(), getPdfModalRefs()
showAppModal(), closeAppModal()
showPdfProgressModal(), finishPdfProgressModal()
bindModalEvents()
showStep()
loadTemplateIndex(), loadTemplateById()
applyTemplate(), clearTemplateDrivenFields()
inferEventTypeFromQuote(), inferTemplateIdFromQuote()
loadPlannerAcceptedQuotes(), applyAcceptedQuoteToPlanner()
renderGenres(), getSelectedGenres()
setChecked(), isChecked()
toNumberOrZero(), formatMoney(), truthy()
loadTransferConfig(), applyTransferConfig()
recalcFinance(), recalcQuoteFinance()
syncStep4UI(), syncBillingUI()
syncCeremonyMusicLocks(), syncConditionalSections()
syncEventTypeUI(), syncContactVisibility()
initSignaturePad(), clearSignaturePad()
renderAttachments()
loadVenues(), renderVenueOptions(), saveVenueIfNeeded()
validateForm()
renderConflictNotice(), checkConflicts()
getPayload(), setPayload()
setResultLinks()
runSearch(), renderSearchResults()
loadCalendar(), renderCalendar(), renderDayList()
loadDashboard(), renderDashList(), renderAlertList()
loadView(), buildTimeline(), annotateTimeline()
collectQuotePayload(), generateQuotePdf()

A helper függvények több helyen duplikáltan jelennek meg a frontend JS fájlokban. Ez jelenleg nem logikai hiba, hanem abból adódik, hogy az oldalak külön entrypointként működnek. Későbbi refaktor során ezek közös utility fájlba emelhetők.

5. Frontend → endpoint mátrix

Ez a blokk fordított nézetben mutatja meg, hogy az egyes frontend JS modulok pontosan mely backend végpontokat használják. Hibakeresésnél ez gyakran gyorsabb, mint endpointonként keresgélni.

Frontend JS	Használt endpointok	Fő cél
`app.js`	`GET /api/venues` `POST /api/venues` `GET /api/payment-transfer-config` `POST /api/upload` `GET /api/conflicts` `POST /api/autotimeline` `POST /api/sessions` `GET /api/sessions` `GET /api/session/:stamp` `DELETE /api/session/:stamp` `GET /api/stats` `GET /api/planner-accepted-quotes` `GET /api/planner-accepted-quote/:stamp`	planner űrlap, mentés, keresés, statisztika, accepted quote előtöltés
`crm.js`	`GET /api/session/:stamp` `POST /api/quotes/generate` `GET /api/quotes` `GET /api/quote/:stamp` `DELETE /api/quote/:stamp`	árajánlat generálás, follow-up betöltés, quote törlés
`dashboard.js`	`POST /api/auth/dashboard` `GET /api/dashboard-summary`	dashboard hitelesítés és összesítő kártyák
`calendar.js`	`GET /api/calendar`	havi naptár, napi eseménylista, PDF / ICS / Preview linkek
`dj-view.js`	`GET /api/session/:stamp` `POST /api/auth/price-view`	részletes preview, pénzügyi mezők opcionális feloldása

6. Adatmodellek

A rendszer több, egymással összefüggő objektummal dolgozik. Ezek nem formális TypeScript interfészek, de logikailag stabil szerkezetek, amelyeket a frontend és backend is követ.

Planner payload

{
  "eventTemplate": "wedding_classic",
  "eventTemplateName": "Esküvő – klasszikus magyar",
  "eventType": "wedding",
  "coupleName": "Minta Pár",
  "eventDate": "2026-08-15",
  "venue": "Szeged - Kastélykert Birtok",
  "primaryContactName": "Tarján Attila",
  "primaryContactPhone": "+36 30 123 4567",
  "genres": ["Retro", "Pop"],
  "guestArrivalTime": "17:00",
  "dinnerTime": "19:00",
  "serviceFee": "250000",
  "paymentMethod": "átutalás"
}

Quote objektum

{
  "quoteNumber": "AJ-2026-0001",
  "quoteDate": "2026-03-12",
  "validFrom": "2026-03-12",
  "validUntil": "2026-03-19",
  "servicePeriodFrom": "2026-08-15T12:00",
  "servicePeriodTo": "2026-08-15T23:00",
  "packageName": "Esküvő – Prémium",
  "basePrice": 250000,
  "extrasTotal": 60000,
  "discountAmount": 10000,
  "totalPrice": 300000,
  "status": "draft",
  "documentMode": "offer"
}

Planner index item

{
  "stamp": "minta_par_2026-08-15",
  "json": "/data/minta_par_2026-08-15.json",
  "pdf": "/data/minta_par_2026-08-15.pdf",
  "ics": "/data/minta_par_2026-08-15.ics",
  "eventType": "wedding",
  "coupleName": "Minta Pár",
  "eventDate": "2026-08-15",
  "venue": "Szeged - Kastélykert Birtok",
  "status": "szerződött",
  "isPaid": "nem"
}

Quote index item

{
  "stamp": "minta_par_2026-08-15_aj-2026-0001",
  "quoteNumber": "AJ-2026-0001",
  "quoteDate": "2026-03-12",
  "validUntil": "2026-03-19",
  "status": "accepted",
  "coupleName": "Minta Pár",
  "eventType": "wedding",
  "eventDate": "2026-08-15",
  "venue": "Szeged - Kastélykert Birtok",
  "totalPrice": 300000
}

Dashboard summary response

{
  "ok": true,
  "summary": {...},
  "nextEvent": {...},
  "todayItems": [...],
  "next7Days": [...],
  "openFinance": [...],
  "incompleteItems": [...],
  "alerts": {...},
  "quotes": {...}
}

Calendar day item

{
  "date": "2026-08-15",
  "day": 15,
  "inMonth": true,
  "isToday": false,
  "items": [
    {
      "stamp": "minta_par_2026-08-15",
      "coupleName": "Minta Pár",
      "venue": "Szeged - Kastélykert Birtok",
      "eventType": "wedding",
      "pdf": "/data/minta_par_2026-08-15.pdf",
      "json": "/data/minta_par_2026-08-15.json",
      "ics": "/data/minta_par_2026-08-15.ics"
    }
  ]
}

7. Kötelező / opcionális mezők

A frontend sok validációt már mentés előtt elvégez, de a backend is ellenőrzi a legfontosabb mezőket. Az alábbi táblák a legfontosabb mezőket foglalják össze.

Planner payload fő mezők

Mező	Típus	Kötelező	Mikor releváns	Megjegyzés
`eventTemplate`	string	igen	mindig	template kiválasztás kötelező
`eventType`	string	igen	mindig	wedding / corporate / prom / ball
`coupleName`	string	igen	mindig	üzleti és fájlnévi azonosítóban is szerepet kap
`eventDate`	date string	igen	mindig	conflict check és stamp alap
`venue`	string	igen	mindig	select vagy egyedi venue
`primaryContactName`	string	igen	mindig	kapcsolattartó
`primaryContactPhone`	string	igen	mindig	kapcsolattartó telefon
`guestArrivalTime`	time	igen	wedding	menetrend alapja
`dinnerTime`	time	igen	wedding	menetrend alapja
`eventEndTime`	time	igen	wedding	másnapi zárás is lehet
`evGuestArrivalTime`	time	igen	non-wedding	általános rendezvény kezdési pont
`evEventEndTime`	time	igen	non-wedding	általános rendezvény vége
`paymentMethod`	string	igen	mindig	KP vagy átutalás
`bankAccount`	string	feltételes	átutalás	átutalásnál kötelező
`invoiceName`	string	feltételes	invoiceNeeded=true	számlázásnál kötelező

Quote mezők

Mező	Típus	Kötelező	Megjegyzés
`quoteNumber`	string	nem	hiány esetén backend generálja
`quoteDate`	date	nem	default: mai nap
`validFrom`	date	nem	default: mai nap
`validUntil`	date	nem	default: +7 nap
`packageName`	string	nem	template vagy kézi kitöltés
`basePrice`	number	nem	normalizálva lesz
`extrasTotal`	number	nem	effect gépek alapján is számolható
`discountAmount`	number	nem	levonás
`totalPrice`	number	nem	backend is újraszámolhatja
`status`	string	nem	draft / sent / accepted stb.
`documentMode`	string	nem	offer vagy followup

8. Eseménytípus-logika

A rendszer nem csak más szöveget jelenít meg az egyes eseménytípusoknál, hanem eltérő mezőket, menetrendet és validációkat is használ.

Wedding

ceremónia blokk elérhető
nyitótánc, torta, éjféli keringő, menyasszonytánc
menyasszony és vőlegény telefon mezők
ceremóniamester blokk
guestArrivalTime, dinnerTime, eventEndTime kiemelt mezők

Corporate / Prom / Ball

általános rendezvény menetrend
organizerName / Phone / Email
techStage / techProjector / techMicCount
evGuestArrivalTime, evOpeningTime, evEventEndTime
nincs külön wedding-specifikus blokk

Az autotimeline és a PDF generálás is eseménytípus-specifikus logikával dolgozik, tehát a mezők nem csak UI szinten, hanem backend oldalon is eltérően viselkednek.

9. Planner API végpontok

POST /api/sessions

Új planner session mentése, PDF és ICS generálása

A planner fő mentési route-ja. A teljes esemény payloadot fogadja, validál, opcionálisan automatikus menetrendet generál, majd létrehozza a JSON, PDF és ICS fájlokat.

Frontend JS	Miért használja	Létrejövő fájlok	Fő mellékhatás
`app.js`	Planner űrlap mentése	JSON + PDF + ICS	index frissítés + ütközésellenőrzés

Request példa

{
  "eventTemplate": "wedding_classic",
  "eventType": "wedding",
  "coupleName": "Minta Pár",
  "eventDate": "2026-08-15",
  "venue": "Szeged - Kastélykert Birtok",
  "primaryContactName": "Tarján Attila",
  "primaryContactPhone": "+36 30 123 4567",
  "guestArrivalTime": "17:00",
  "dinnerTime": "19:00",
  "eventEndTime": "04:00",
  "autoTimeline": true,
  "attachments": ["/uploads/123_note.png"]
}

Response példa

{
  "ok": true,
  "id": "uuid",
  "stamp": "minta_par_2026-08-15",
  "json": "/data/minta_par_2026-08-15.json",
  "pdf": "/data/minta_par_2026-08-15.pdf",
  "ics": "/data/minta_par_2026-08-15.ics",
  "conflicts": []
}

Validációk

eventTemplate kötelező
eventType kötelező
coupleName kötelező
eseménytípustól függően időmezők kötelezők
átutalás esetén számlaadatok kötelezők

Hibalehetőségek

hiányzó eseménytípus vagy sablon
hibás aláírásfájl vagy hiányzó feltöltés
PDF generálási hiba
ICS írási hiba
fájlrendszer jogosultsági probléma

GET /api/sessions

Mentett planner események listázása és szűrése

A planner keresője, az admin listák és bizonyos összesítő nézetek ezt a route-ot használják. Az indexfájlból dolgozik, majd query paraméterek alapján szűr.

Frontend JS	Használat	Query mezők	Válasz jellege
`app.js`	Keresés és listaépítés	q, couple, venue, style, status, paid, eventType, eventTemplate, dateFrom, dateTo	Index szintű tömör rekordlista

GET /api/sessions?q=kastely&eventType=wedding&dateFrom=2026-08-01&dateTo=2026-08-31

{
  "ok": true,
  "items": [
    {
      "stamp": "minta_par_2026-08-15",
      "json": "/data/minta_par_2026-08-15.json",
      "pdf": "/data/minta_par_2026-08-15.pdf",
      "ics": "/data/minta_par_2026-08-15.ics",
      "eventType": "wedding",
      "coupleName": "Minta Pár"
    }
  ]
}

Ez a route nem a teljes rekordot adja vissza, hanem gyors listázásra optimalizált indexadatokat.

GET /api/session/:stamp

Egy konkrét planner rekord teljes visszaolvasása

A visszatöltés, a DJ Preview és több részletes nézet ezt használja. A teljes mentett rekordot adja vissza.

Frontend JS	Miért használja	Bemenet	Kimenet
`app.js`, `crm.js`, `dj-view.js`	Részletes rekordbetöltés	stamp paraméter	teljes JSON rekord

{
  "ok": true,
  "record": {
    "id": "uuid",
    "createdAt": "2026-03-12T20:00:00.000Z",
    "updatedAt": "2026-03-12T20:15:00.000Z",
    "payload": { "coupleName": "Minta Pár", "eventType": "wedding" },
    "attachments": []
  }
}

Validáció

Csak létező stamp esetén ad választ. Hiányzó vagy hibás fájlnál 404 válasz jön.

Tipikus hibák

nem létező stamp
kézzel törölt JSON fájl
sérült JSON tartalom

DELETE /api/session/:stamp

Planner rekord törlése

Törli a sessionhöz tartozó JSON, PDF és ICS fájlt, majd frissíti az indexet.

{ "ok": true }

Frontend JS

app.js – a keresési eredményekből történő törlésnél.

Hibalehetőségek

fájl nem törölhető
index nem menthető
jogosultsági hiba a fájlrendszerben

10. CRM / Quote API végpontok

POST/api/quotes/generate

Árajánlat JSON és PDF generálás

A CRM űrlap ezt a route-ot hívja. A backend normalizálja a quote adatokat, sorszámot generál, majd PDF-et készít és indexel.

Frontend JS	Miért használja	Fő bemenet	Kimenet
`crm.js`	Ajánlat generálása	payload + quote	quote JSON + quote PDF

Request példa

{
  "payload": {
    "coupleName": "Minta Pár",
    "eventDate": "2026-08-15",
    "venue": "Szeged - Kastélykert Birtok",
    "eventType": "wedding"
  },
  "quote": {
    "quoteDate": "2026-03-12",
    "packageName": "Esküvő – Prémium",
    "basePrice": 250000,
    "discountAmount": 10000,
    "status": "draft"
  }
}

Response példa

{
  "ok": true,
  "stamp": "minta_par_2026-08-15_aj-2026-0001",
  "record": { "payload": {}, "quote": {} },
  "pdf": "/data/quotes/minta_par_2026-08-15_aj-2026-0001.pdf",
  "json": "/data/quotes/minta_par_2026-08-15_aj-2026-0001.json"
}

Validációk

coupleName kötelező
eventDate kötelező
quote normalizálás automatikusan történik
sorszám automatikusan generálódik, ha hiányzik

Hibalehetőségek

hiányzó alap adatok
PDF generálási hiba
quote fájl mentési hiba
quote index írási hiba

GET/api/quotes

Quote lista lekérése

A CRM follow-up lista és a korábbi ajánlatok visszatöltő dropdownja ezt használja.

GET /api/quotes?q=minta&status=accepted

{
  "ok": true,
  "items": [
    {
      "stamp": "minta_par_2026-08-15_aj-2026-0001",
      "quoteNumber": "AJ-2026-0001",
      "status": "accepted"
    }
  ]
}

Frontend JS

crm.js – follow-up ajánlatlista betöltése.

Hibalehetőségek

Quote index hiánya vagy sérülése esetén a backend újraépíti azt, de hibás JSON fájlok kieshetnek a listából.

GET/api/quote/:stamp

Egy quote teljes rekordjának visszaolvasása

Follow-up visszatöltéshez és korábbi ajánlat adatok újrafelhasználásához szükséges route.

Frontend JS	Használat	Validáció	Válasz
`crm.js`	Kiválasztott ajánlat visszatöltése	létező quote fájl kell	teljes quote rekord

{
  "ok": true,
  "record": {
    "id": "uuid",
    "payload": { "coupleName": "Minta Pár" },
    "quote": { "quoteNumber": "AJ-2026-0001" }
  }
}

DELETE/api/quote/:stamp

Quote törlése

Törli a kiválasztott quote JSON és PDF fájlt, majd kiveszi azt a quote indexből.

Frontend JS

crm.js – generált ajánlat és follow-up ajánlat törlése.

Tipikus hibák

nem létező quote stamp
fájltörlési hiba
quote index mentési hiba

GET/api/planner-accepted-quotes

Accepted quote-ok listája planner előtöltéshez

Csak az elfogadott státuszú ajánlatokat adja vissza, hogy a planner oldal ezekből tudjon új eseményt előkészíteni.

Frontend JS

app.js – accepted quote lista betöltése.

Miért külön route?

Nem kell a frontendnek külön szűrnie a teljes quote listát, így tisztább és biztonságosabb a workflow.

{
  "ok": true,
  "items": [
    {
      "stamp": "minta_par_2026-08-15_aj-2026-0001",
      "quoteNumber": "AJ-2026-0001",
      "quoteDate": "2026-03-12",
      "coupleName": "Minta Pár",
      "eventType": "wedding",
      "eventDate": "2026-08-15",
      "venue": "Szeged - Kastélykert Birtok",
      "status": "accepted",
      "totalPrice": 300000,
      "updatedAt": "2026-03-12T20:12:00.000Z"
    }
  ]
}

GET/api/planner-accepted-quote/:stamp

Egy accepted quote részletes betöltése plannerre

Csak akkor ad vissza rekordot, ha a kiválasztott quote valóban accepted állapotú.

Frontend JS

app.js – accepted ajánlatból planner űrlap előtöltése.

Hibalehetőségek

hiányzó quote azonosító
nem accepted státusz
nem található quote rekord

{
  "ok": true,
  "record": {
    "payload": { "coupleName": "Minta Pár", "eventDate": "2026-08-15" },
    "quote": { "status": "accepted", "quoteNumber": "AJ-2026-0001" }
  }
}

11. Segédvégpontok

GET/

Fő planner felület kiszolgálása

A gyökérútvonal a planner frontend főoldalát szolgálja ki.

Frontend fájl

main.html

Megjegyzés

Ez nem JSON API, hanem HTML kiszolgáló route.

GET/api/venues

Helyszínek lekérése

A planner helyszínlista töltése. A javított frontend már ezt az API-t használja a statikus JSON helyett.

Frontend JS

app.js

Response példa

{
  "ok": true,
  "options": [
    "Szeged - Kastélykert Birtok",
    "Mórahalom - Babos Tanya"
  ]
}

POST/api/venues

Új helyszín mentése

Az „Egyéb…” mezőből érkező új helyszínt menti, majd visszaadja a frissített listát.

{ "venue": "Új Helyszín Kft. Rendezvényterem" }

{
  "ok": true,
  "added": true,
  "venue": "Új Helyszín Kft. Rendezvényterem",
  "options": ["..."]
}

Frontend JS

app.js

Hibalehetőségek

üres venue mező
fájlrendszer írási hiba
venues.json sérülése

POST/api/upload

Képfeltöltés

Jegyzetek és aláírások feltöltéséhez használt route. Csak PNG / JPG / WEBP fájlokat enged be 12 MB méretig.

Frontend JS

app.js

Hibák / validáció

nem támogatott MIME típus
12 MB feletti fájl
hiányzó file mező

{
  "ok": true,
  "file": "/uploads/1700000000000_signature.png",
  "original": "signature.png"
}

GET/api/conflicts

Dátumütközések lekérdezése

Az esemény dátuma alapján visszaadja, van-e már másik mentett session ugyanarra a napra.

GET /api/conflicts?eventDate=2026-08-15&excludeStamp=minta_par_2026-08-15

{
  "ok": true,
  "items": [
    {
      "stamp": "masik_par_2026-08-15",
      "coupleName": "Másik Pár",
      "eventDate": "2026-08-15",
      "venue": "Másik helyszín"
    }
  ]
}

Frontend JS

app.js

Miért fontos?

Nem tiltja automatikusan a mentést, csak figyelmeztet, így az adminisztratív döntés a felhasználónál marad.

POST/api/autotimeline

Automatikus menetrend generálása

A backend kiszámol hiányzó időpontokat a már megadott eseményidők alapján.

Frontend JS

app.js

Hibalehetőségek

Hibás vagy hiányos időformátumok esetén a visszaadott generált mezők részlegesek lehetnek.

{
  "ok": true,
  "generated": {
    "guestArrivalTime": "17:00",
    "dinnerTime": "19:00",
    "cakeTime": "22:00"
  }
}

GET/api/payment-transfer-config

Átutalási konfiguráció lekérése

A szolgáltató fix számlaadatainak lekérdezésére szolgál.

Frontend JS

app.js

Response példa

{
  "ok": true,
  "config": {
    "bankAccount": "11712345-12345678-12345678",
    "accountOwner": "Tarján Attila",
    "bankName": "CIB Bank Zrt"
  }
}

GET/api/stats

Statisztikai összesítés

Műfaji, tiltólistás, helyszín- és státuszgyakorisági adatokat ad a planner rekordok alapján.

Frontend JS

app.js – statisztika panel.

Hibalehetőségek

Sérült planner rekordok esetén egyes elemek hiányozhatnak a statisztikából, de az endpoint ettől még általában működőképes marad.

{
  "ok": true,
  "totalSessions": 18,
  "topGenres": [{"key":"retro","count":6}],
  "venueFrequency": [{"key":"Szeged - Kastélykert Birtok","count":4}]
}

12. Dashboard és naptár végpontok

GET/api/dashboard-summary

Dashboard összesítő route

A dashboard oldal már ezt a route-ot használja, így a számolási logika a backendben marad, és nem duplikálódik a frontendben.

Frontend JS	Tartalom	Fő blokkok	Miért jobb így?
`dashboard.js`	összesítő dashboard adatok	summary, nextEvent, todayItems, next7Days, openFinance, incompleteItems, alerts, quotes	kevesebb frontend logika, egységes üzleti szabályok

{
  "ok": true,
  "summary": {
    "totalEvents": 18,
    "todayCount": 1,
    "next7DaysCount": 4,
    "openFinanceTotal": 540000
  },
  "nextEvent": { "stamp": "...", "coupleName": "Minta Pár" },
  "alerts": {
    "missingDeposit": [],
    "missingInvoiceInfo": []
  },
  "quotes": {
    "totalQuotes": 9,
    "activeQuotes": 3,
    "acceptedQuotes": 2,
    "expiredQuotes": 1
  }
}

Ez a route aggregáló végpont, tehát nem egyetlen rekordot kezel, hanem több planner és quote rekordból épít üzleti nézetet.

GET/api/calendar?month=YYYY-MM

Havi naptár adatai

A naptár oldal a teljes havi rácsot és a napokhoz tartozó eseménylistát innen kapja meg.

Frontend JS

calendar.js

Javított működés

A frontend most már az API által visszaadott it.ics mezőt használja, nem kézzel rakja össze az ICS útvonalat.

{
  "ok": true,
  "month": "2026-08",
  "monthLabel": "2026. augusztus",
  "prevMonth": "2026-07",
  "nextMonth": "2026-09",
  "days": [
    {
      "date": "2026-08-15",
      "day": 15,
      "inMonth": true,
      "items": [
        {
          "stamp": "minta_par_2026-08-15",
          "pdf": "/data/minta_par_2026-08-15.pdf",
          "json": "/data/minta_par_2026-08-15.json",
          "ics": "/data/minta_par_2026-08-15.ics"
        }
      ]
    }
  ]
}

Validáció

A month paraméternek YYYY-MM formátumúnak kell lennie.

Hibalehetőségek

érvénytelen month paraméter
planner index hiánya
sérült eseménydátumok a rekordokban

13. PDF generálási logika és template rendszer

A rendszer kétféle PDF-et készít: planner PDF-et és quote PDF-et. Ezekhez közös tipográfiai és tördelési helper-ek tartoznak, de az üzleti tartalom eltérő. A template rendszer pedig előre definiált eseménytípus-alapbeállításokat biztosít.

Planner PDF logika

generatePdf() készíti el a planner PDF-et
fejléc logóval, eseménynévvel, dátummal és helyszínnel
külön blokkok: alapadatok, kapcsolattartás, zenei igények, menetrend, technika, pénzügyek
esküvő és nem esküvő eseménytípusnál eltérő szekciók
jóváhagyás és aláírás kép beillesztése
csatolt jegyzetképek külön oldalakra rakása

Quote PDF logika

generateQuotePdf() készíti el az ajánlati PDF-et
ajánlati fejléc, érvényességi idő, szolgáltatási időintervallum
csomagnév, csomagleírás, technikai tartalom
pénzügyi összesítés, kedvezmény, extra szolgáltatások
follow-up mód esetén számla- és utókövetési mezők is megjelennek

Közös PDF helper-ek

drawHeader() – fejléc rajzolása
titleLine() – szekciócím
divider() – elválasztó vonal
kvInline() – kulcs-érték sorok
drawTable() – menetrendi táblázatok
ensureSpace() – oldalváltás kezelése
setBaseFont() – alap betűkészlet és szín beállítása

Template rendszer

ensureTemplateFiles() hozza létre az alap sablonokat, ha hiányoznak
templates/index.json tartalmazza a választható sablonlistát
külön fájlok: wedding_classic.json, wedding_premium_show.json, corporate_gala.json, prom_standard.json, ball_classic.json
a frontend app.js és crm.js tölti be őket
a template-ek alap időpontokat, technikai szinteket és fizetési módokat tudnak előtölteni

{
  "id": "wedding_premium_show",
  "name": "Esküvő – prémium látvány",
  "eventType": "wedding",
  "payload": {
    "ceremonyOn": true,
    "ceremonyBy": "DJ",
    "effectColdSpark": true,
    "effectHeavyFog": true,
    "djTechLevel": "max",
    "lightTechLevel": "max",
    "paymentMethod": "átutalás"
  }
}

A template rendszer célja, hogy ne kelljen minden eseményt nulláról felépíteni. A sablon nem végleges adatot jelent, hanem kiinduló konfigurációt, amit a felhasználó tovább finomíthat.

14. Fájl-létrejövési mátrix

Az alábbi mátrix összefoglalja, hogy melyik route milyen állományokat hoz létre, frissít vagy töröl. Ez különösen hasznos hibakeresésnél és karbantartásnál.

Route	Művelet	Létrejövő / módosuló fájl	Típus	Megjegyzés
`GET /`	kiszolgál	/public/main.html	HTML	planner főoldal
`GET /api/venues`	olvas	/public/venues.json	konfiguráció	helyszínlista forrás
`POST /api/venues`	frissít	/public/venues.json	konfigurációs lista	helyszínlista bővítése
`POST /api/upload`	létrehoz	/uploads/<generated_name>	kép / aláírás	planner csatolmány vagy signature
`GET /api/payment-transfer-config`	olvas	/public/templates/payment-transfer.json	konfiguráció	átutalási adatok
`POST /api/sessions`	létrehoz / frissít	/data/<stamp>.json	planner rekord	teljes payload mentés
`POST /api/sessions`	létrehoz / frissít	/data/<stamp>.pdf	planner PDF	egyeztető lap
`POST /api/sessions`	létrehoz / frissít	/data/<stamp>.ics	naptárfájl	importálható esemény
`POST /api/sessions`	frissít	/data/_index.json	planner index	listázáshoz szükséges
`DELETE /api/session/:stamp`	töröl	/data/<stamp>.json/.pdf/.ics	planner fájlok	index is frissül
`POST /api/quotes/generate`	létrehoz / frissít	/data/quotes/<stamp>.json	quote rekord	ajánlat mentés
`POST /api/quotes/generate`	létrehoz / frissít	/data/quotes/<stamp>.pdf	quote PDF	árajánlat vagy follow-up PDF
`POST /api/quotes/generate`	frissít	/data/quotes/_quotes_index.json	quote index	quote lista és accepted lista alapja
`POST /api/quotes/generate`	frissít	/data/_counters.json	számláló	quote sorszám növelése
`DELETE /api/quote/:stamp`	töröl	/data/quotes/<stamp>.json/.pdf	quote fájlok	quote index is frissül
`GET /api/quotes`	olvas	/data/quotes/_quotes_index.json	quote index	quote lista alapja
`GET /api/sessions`	olvas	/data/_index.json	planner index	session lista alapja
`GET /api/quote/:stamp`	olvas	/data/quotes/<stamp>.json	quote rekord	részletes betöltés
`GET /api/session/:stamp`	olvas	/data/<stamp>.json	planner rekord	részletes betöltés

A legtöbb végpont nem adatbázist, hanem fájlrendszert használ elsődleges tárolóként. Emiatt különösen fontos a fájlok, indexek és ideiglenes állományok viselkedésének ismerete.

15. Auth végpontok

POST/api/auth/dashboard

Dashboard feloldása jelszóval

A dashboard oldal belépő jelszavát ellenőrzi.

{ "password": "ateszadmin" }

{ "ok": true, "authorized": true }

Frontend JS

dashboard.js

Hibalehetőségek

Hibás jelszó esetén az endpoint nem dob hibát, hanem authorized: false választ ad.

POST/api/auth/price-view

Ármezők feloldása a DJ Preview oldalon

A DJ Preview felület alapértelmezetten elrejti a pénzügyi adatokat. Ezzel a route-tal lehet azokat ideiglenesen megjeleníteni.

{ "password": "ateszadmin" }

{ "ok": true, "authorized": true }

Frontend JS

dj-view.js

Megjegyzés

Jelenleg ugyanazt a master passwordöt használja, mint a dashboard auth, de funkcionálisan külön jogosultsági pontként kezelt route.

16. Hibakezelési stratégia

A rendszer vegyes hibakezelési modellt használ: egyes route-ok HTTP státuszkóddal jeleznek hibát, míg mások üzleti hibát { ok:false } szerkezetben adnak vissza.

Tipikus HTTP státuszkódok

200 – sikeres válasz
400 – hiányzó vagy hibás bemenet
403 – jogosultsági üzleti tiltás, pl. nem accepted quote
404 – nem található rekord
500 – belső szerverhiba / fájlrendszer / PDF / JSON probléma

Frontend reakciók

app.js – modal hibaüzenet
crm.js – modal vagy error box
dashboard.js – auth error vagy alert
calendar.js – alert
dj-view.js – inline hibaüzenet a nézetben

A jövőbeni refaktor egyik jó célja lehetne egy teljesen egységes error contract kialakítása.

17. Gyors hibakeresés

Ha nem jelenik meg a venue lista Ellenőrizd a GET /api/venues végpontot és a /public/venues.json fájlt.

Ha nem készül PDF Ellenőrizd a generatePdf() vagy generateQuotePdf() logikát, a fontfájlokat, a logó elérési útját és a write permissiont.

Ha quote nem jelenik meg a listában Ellenőrizd a /data/quotes/_quotes_index.json fájlt és a rebuildQuoteIndexFromFiles() működését.

Ha dashboard üres Ellenőrizd a POST /api/auth/dashboard és GET /api/dashboard-summary válaszokat.

Ha a naptárban nincs esemény Ellenőrizd az eventDate formátumokat és a GET /api/calendar?month=... válaszát.

Ha accepted quote nem tölthető be plannerre Ellenőrizd, hogy a quote státusza valóban accepted-e és a GET /api/planner-accepted-quote/:stamp nem ad-e 403-at.

18. Fő működési folyamatok

Planner mentés folyamata app.js → opcionális /api/upload → /api/sessions → JSON + PDF + ICS → index frissítés → frontend eredmény linkek.

Quote generálás folyamata crm.js → /api/quotes/generate → quote JSON + quote PDF → quote index.

Accepted quote → planner előtöltés app.js → /api/planner-accepted-quotes → kiválasztás → /api/planner-accepted-quote/:stamp → űrlap előtöltés.

Dashboard betöltés dashboard.js → /api/auth/dashboard → /api/dashboard-summary → kártyák és riasztások renderelése.

Naptár betöltés calendar.js → /api/calendar?month=... → havi rács + napi események + PDF / ICS / Preview linkek.

DJ Preview dj-view.js → /api/session/:stamp → eseményadatok és menetrend kirajzolása → opcionális /api/auth/price-view árak feloldásához.

19. Tesztelési forgatókönyvek

1. Új wedding planner mentése Tölts ki kötelező mezőket, generálj PDF-et és ellenőrizd a JSON / PDF / ICS létrejöttét.

2. Corporate template használata Válassz corporate sablont, ellenőrizd a nem-wedding mezők aktiválódását és a PDF tartalmát.

3. Signature upload Rajzolt aláírás → upload → planner save → PDF-ben aláírás megjelenik.

4. Accepted quote előtöltés Accepted státuszú quote legyen elérhető, majd planner oldalon töltsd vissza.

5. Follow-up quote törlés CRM-ben korábbi quote betöltése, majd törlése és index frissülés ellenőrzése.

6. Dashboard auth Hibás jelszó → authorized:false, helyes jelszó → summary betöltés.

7. Calendar month navigation Előző / következő hónap váltás és adott napi események ellenőrzése.

20. Ismert korlátok

Jelenlegi korlátok

nincs adatbázis, fájlrendszer-alapú tárolás van
nincs teljes role-based auth rendszer
nincs API verziózás
nincs rate limiting
nincs dedikált audit log
a frontend helper-ek részben duplikáltak
nagy rekordszámnál az index újraépítés drágább lehet

Refaktor backlog

közös frontend util modul
route handler-ek külön modulokba bontása
service layer bevezetése planner / quote logikára
schema validation middleware
közös auth middleware
OpenAPI / Swagger export
opcionális adatbázis backend

21. Fejlesztői megjegyzések

Erősségek

Planner és quote logika jól elválasztva
Fájlalapú indexelés gyors listázásokhoz
Atomic mentés a JSON / PDF / ICS esetén
Külön dashboard summary végpont
Naptárhoz előkészített napi bontás
Accepted quote → planner workflow tiszta felépítésű
PDF generálás elkülönül a frontendtől

Későbbi bővítési irányok

közös frontend utility modul a duplikált helper függvények helyett
szigorúbb backend validáció
egységesebb mezőelnevezés planner és CRM oldalon
esetleges adatbázisra váltás nagyobb terhelésnél
részletesebb auth modell külön szerepkörökkel
OpenAPI / Swagger alapú automatikus dokumentáció

Ez a dokumentáció alkalmas belső technikai átadásra, saját fejlesztői jegyzetnek, valamint arra is, hogy később új funkciókat azonos szerkezeti elvek mentén lehessen beépíteni.

v2 dokumentáció

Dokumentáció célja

Ez az oldal a rendszer refaktorált frontend szerkezetét dokumentálja. A cél nem pusztán az, hogy felsoroljuk az új fájlokat, hanem az, hogy pontosan rögzítsük: melyik modul milyen felelősséget visz, melyik HTML oldal milyen sorrendben tölti be a scriptjeit, mely modul melyik másik modulra támaszkodik, mely backend végpontokat használja, és milyen tesztelési pontokon kell ellenőrizni az átállást.

A v2 dokumentáció úgy készült, hogy fejlesztés, hibakeresés, átadás vagy tovább-refaktorálás során önálló referenciaanyagként használható legyen. A dokumentáció fókusza a frontend, de mindenhol megjelöli a backend kapcsolódási pontokat is.

AppCore

UiModal

Planner feature-modulok

CRM feature-modulok

Dashboard auth / render / app

Calendar API adapter

DJ View timeline / auth / render / app

HTML script sorrend

1. V2 rendszeráttekintés

A v2 frontend refaktor lényege, hogy az eredetileg oldalanként monolit JavaScript állományokat felelősség-alapú modulokra bontja, miközben:

a HTML tagek és ID-k változatlanok maradnak,
a backend route-ok változatlanok maradnak,
a funkcionális működésnek meg kell egyeznie az eredeti rendszerrel,
az átállás fokozatosan, kis kockázattal történik.

Mi a rendszer magja?

Továbbra is két fő üzleti entitás van: a planner session és a quote. A refaktor ezek körüli frontend logikát bontja kisebb egységekre.

Mi a refaktor magja?

A monolit oldallogikák helyett külön fájlba kerül a közös helper, a modal, a pénzügy, a template-kezelés, a keresés, az auth, a render vagy a timeline.

A v2 nem új termékverzió üzleti értelemben, hanem technikai szerkezeti verzió. Ezért a dokumentáció a működést ugyanazzal a részletességgel írja le, de már a refaktorált fájlszerkezetre vetítve.

2. Refaktor célja és alapelvei

A refaktor nem „mindent közösítsünk” elven épül, hanem a következő működési szabályok mentén:

1. A HTML marad stabil A meglévő formmezők, ID-k, canvasok, modal elemek és listadobozok a refaktor után is ugyanazok. Ez csökkenti a regressziók esélyét és egyszerűsíti a fokozatos átállást.

2. A közös logika csak akkor kerül ki, ha valóban közös Nem minden hasonló függvény kerül a core-ba. Csak az, ami több modulban ugyanúgy használható, stabil, és nem hordoz feature-specifikus mellékhatást.

3. A feature modulok saját felelősséget visznek A planner-finance nem keres rekordokat, a planner-search nem számol pénzügyet, a dashboard-render nem authol, a djview-timeline nem renderel DOM-ot.

4. Klasszikus script betöltés marad A rendszer nem áll át ES module import/export szerkezetre. A modulok window.XYZ namespace-en keresztül érhetők el.

5. A betöltési sorrend a működés része Mivel nincs bundler vagy module loader, a script sorrend logikai függőséget is jelent. A dokumentáció ezért ezt külön fejezetben kezeli.

A refaktor fő célja a karbantarthatóság, átláthatóság, tesztelhetőség és részleges újrafelhasználhatóság, nem pedig a technológiai stack lecserélése.

3. V2 rendszertérkép

Ez a blokk összefoglalja, hogy a refaktorált frontendben melyik oldal milyen modulhalmazt használ, és ezek hogyan kapcsolódnak a backendhez.

Frontend oldalak

main.html – launcher / navigáció
index.html – planner wizard
crm.html – ajánlatkészítés és follow-up
dashboard.html – összesítő admin nézet
calendar.html – havi naptárnézet
dj-view.html – live preview
user-manual.html – technikai dokumentáció

Refaktorált JS szintek

core/ – alap helper és API wrapper
ui/ – közös modal logika
planner/ – planner feature modulok
crm/ – CRM feature modulok
dashboard/ – dashboard auth / render / app
calendar/ – calendar entry
djview/ – DJ preview logika

Backend kapcsolódások

/api/sessions és kapcsolódó route-ok
/api/quotes és kapcsolódó route-ok
/api/dashboard-summary
/api/calendar
/api/auth/dashboard és /api/auth/price-view

Állandó technikai szabályok

nincs bundler
nincs import/export
nincs HTML ID átnevezés
nincs backend route átnevezés ebben a körben

4. Frontend oldalak és belépési pontok

A refaktorált frontendben az egyes HTML oldalak továbbra is önálló entrypointok. A különbség az, hogy már nem egyetlen nagy JS fájl van mögöttük, hanem több kisebb modul.

HTML oldal	Funkció	Core függőségek	Feature modulok	Entrypoint
`index.html`	Planner wizard	`base.js`, `api.js`, `formar.js`	`ui-modal.js` `planner-templates.js` `planner-venues.js` `planner-signature.js` `planner-finance.js` `planner-search.js` `planner-accepted-qoutes.js`	`planner-app.js`
`crm.html`	CRM / quote felület	`base.js`, `api.js`, `formar.js`	`ui-modal.js` `crm-finance.js` `crm-follwup.js` `crm-templates.js`	`crm-app.js`
`dashboard.html`	Admin dashboard	`base.js`, `api.js`, `formar.js`	`dashboard-auth.js` `dashboard-render.js`	`dashboard-app.js`
`calendar.html`	Havi naptár	`base.js`, `api.js`, `formar.js`	—	`calendar-app.js`
`dj-view.html`	DJ preview	`base.js`, `api.js`, `formar.js`	`djview-timeline.js` `djview-auth.js` `djview-render.js`	`djview-app.js`

Mivel minden HTML oldal önálló entrypoint, a közös helper-ek csak azon az oldalon érhetők el, ahol a megfelelő script hivatkozások be vannak töltve. Ezért a hiányzó script nem csak részfunkciót, hanem teljes oldalhibát is okozhat.

5. Refaktorált fájlszerkezet

public/
  assets/
    JS/
      calendar/
        calendar-app.js
      core/
        api.js
        base.js
        formar.js
      crm/
        crm-app.js
        crm-finance.js
        crm-follwup.js
        crm-templates.js
      dashboard/
        dashboard-app.js
        dashboard-auth.js
        dashboard-render.js
      djview/
        djview-app.js
        djview-auth.js
        djview-render.js
        djview-timeline.js
      planner/
        planner-accepted-qoutes.js
        planner-app.js
        planner-finance.js
        planner-search.js
        planner-signature.js
        planner-templates.js
        planner-venues.js
      ui/
        ui-modal.js

Miért így jó?

oldalankénti monolit helyett feature-szegmensek vannak
könnyebb egy hiba forrását izolálni
jobban látszik, mi közös és mi oldal-specifikus
későbbi backend service bontáshoz is jobban illeszkedik

Miért nem lett több core fájl?

Az első frontend refaktor célja a stabilitás volt. Ezért csak az igazoltan közös és alacsony kockázatú logikák kerültek ki a core-ba.

6. Fontos név- és fájlmegkötések

A projektben több olyan fájlnév van, amely történelmi okból elírt formában maradt meg. Ezeket a dokumentáció külön kiemeli, mert a script hivatkozásnál a tényleges fájlnevet kell használni.

Logikai név	Tényleges fájlnév	Megjegyzés
`format.js`	`formar.js`	tartalmilag format helper, de a projektben a fájlnév így szerepel
`crm-followup.js`	`crm-follwup.js`	followup elírással szerepel
`planner-accepted-quotes.js`	`planner-accepted-qoutes.js`	quotes elírással szerepel

Ezeket a neveket ebben a körben nem érdemes átírni, mert az több helyen egyszerre okozna törést. Ha később lesz külön naming-cleanup kör, azt érdemes önálló regressziós teszttel kezelni.

7. HTML script betöltési sorrend

A refaktorált frontendben a script sorrend logikai függőségeket is jelent. Mivel nincs import/export, a modulok csak akkor működnek, ha a rájuk épülő függőségek előbb betöltődtek.

index.html

<script src="./assets/JS/core/base.js"></script>
<script src="./assets/JS/core/api.js"></script>
<script src="./assets/JS/core/formar.js"></script>
<script src="./assets/JS/ui/ui-modal.js"></script>
<script src="./assets/JS/planner/planner-templates.js"></script>
<script src="./assets/JS/planner/planner-venues.js"></script>
<script src="./assets/JS/planner/planner-signature.js"></script>
<script src="./assets/JS/planner/planner-finance.js"></script>
<script src="./assets/JS/planner/planner-search.js"></script>
<script src="./assets/JS/planner/planner-accepted-qoutes.js"></script>
<script src="./assets/JS/planner/planner-app.js"></script>

crm.html

<script src="./assets/JS/core/base.js"></script>
<script src="./assets/JS/core/api.js"></script>
<script src="./assets/JS/core/formar.js"></script>
<script src="./assets/JS/ui/ui-modal.js"></script>
<script src="./assets/JS/crm/crm-finance.js"></script>
<script src="./assets/JS/crm/crm-follwup.js"></script>
<script src="./assets/JS/crm/crm-templates.js"></script>
<script src="./assets/JS/crm/crm-app.js"></script>

dashboard.html

<script src="./assets/JS/core/base.js"></script>
<script src="./assets/JS/core/api.js"></script>
<script src="./assets/JS/core/formar.js"></script>
<script src="./assets/JS/dashboard/dashboard-auth.js"></script>
<script src="./assets/JS/dashboard/dashboard-render.js"></script>
<script src="./assets/JS/dashboard/dashboard-app.js"></script>

calendar.html

<script src="./assets/JS/core/base.js"></script>
<script src="./assets/JS/core/api.js"></script>
<script src="./assets/JS/core/formar.js"></script>
<script src="./assets/JS/calendar/calendar-app.js"></script>

dj-view.html

<script src="./assets/JS/core/base.js"></script>
<script src="./assets/JS/core/api.js"></script>
<script src="./assets/JS/core/formar.js"></script>
<script src="./assets/JS/djview/djview-timeline.js"></script>
<script src="./assets/JS/djview/djview-auth.js"></script>
<script src="./assets/JS/djview/djview-render.js"></script>
<script src="./assets/JS/djview/djview-app.js"></script>

main.html

<script>
document.getElementById("year").textContent = new Date().getFullYear();
</script>

A main launcher jelenleg nem használ refaktorált JS modult.

A leggyakoribb refaktor utáni hibák: rossz script útvonal, felcserélt sorrend, kimaradt core vagy ui modul.

8. Frontend architektúra – adatfolyam

A v2 architektúra lényege, hogy az oldal entrypoint csak összehangolja a feature modulokat. Az adatmozgás már kisebb egységeken keresztül történik.

1. HTML oldal betölt A HTML oldal betölti a core modulokat, majd az oldalhoz szükséges feature modulokat, végül az adott entrypoint futtatja az inicializálást.

2. Core réteg inicializálódik Az AppCore biztosítja az alap DOM, path, format és API helper-eket, amelyeket később minden feature modul egységesen használ.

3. Feature modulok regisztrálódnak A window.PlannerFinance, window.CrmFollowup, window.DashboardRender, window.DjViewTimeline típusú namespace-ek elérhetővé válnak a globális térben.

4. Entrypoint összefogja a működést Az entrypoint modul hívja meg a részmodulokat: pl. template betöltés, venue lista, finance sync, search bind, timeline render vagy auth bind.

5. Felhasználói interakció indul Gombnyomás, input változás vagy page load hatására valamelyik feature modul API hívást indít, állapotot módosít, vagy újrarendereli az oldal egy részét.

6. API válasz → részleges UI frissítés Nem mindig az egész oldal rajzolódik újra. Sok helyen csak a szükséges rész: lista, summary mező, modal, result link vagy timeline blokk.

A v2 frontend ezért már részben komponens-szerű gondolkodást követ, még ha technikailag nem is React vagy Vue alapú.

9. Teljes rendszer komponens diagram

Ez az ábra a refaktorált frontend és a változatlan backend magas szintű kapcsolódását mutatja.

Felhasználó

User
  ↓
HTML page

Frontend entrypointok

index.html
crm.html
dashboard.html
calendar.html
dj-view.html

Core réteg

AppCore.BASE
AppCore.$
AppCore.apiGet / apiPost / apiDelete
AppCore.escapeHtml / normalizeText / formatMoney / truthy

Feature modulok

Planner*
Crm*
Dashboard*
CalendarApp
DjView*

Backend API

/api/sessions
/api/session/:stamp
/api/quotes
/api/quote/:stamp
/api/dashboard-summary
/api/calendar
/api/venues
/api/upload
/api/auth/*

Tárolási réteg

/data
/data/quotes
/uploads
/public/templates
/public/venues.json

A frontend szét lett bontva, de a backend még ugyanazt a monolit route- és storage-logikát szolgálja ki. Emiatt a frontend refaktor különösen jó előkészítő lépés a későbbi backend service-bontáshoz.

10. Frontend → modulfüggőségi mátrix

Ez a mátrix azt mutatja meg, hogy az entrypoint és a feature modulok milyen frontend namespace-ekre épülnek.

Modul	Függő namespace-ek	Függőség erőssége	Mi történik, ha hiányzik?
`planner-app.js`	`AppCore` `UiModal` `PlannerTemplates` `PlannerVenues` `PlannerSignature` `PlannerFinance` `PlannerSearch` `PlannerAcceptedQuotes`	erős	A planner oldal részlegesen vagy teljesen használhatatlanná válik.
`crm-app.js`	`AppCore` `UiModal` `CrmFinance` `CrmFollowup` `CrmTemplates`	erős	Quote generálás, follow-up és template kezelés nem működik.
`dashboard-app.js`	`AppCore`, `DashboardAuth`, `DashboardRender`	erős	Belépés vagy dashboard render hibás lesz.
`calendar-app.js`	`AppCore`	közepes	Az oldal egyszerűbben javítható, de a calendar teljesen leállhat.
`djview-app.js`	`AppCore`, `DjViewTimeline`, `DjViewAuth`, `DjViewRender`	erős	A preview, auth vagy render egy része hibára fut.

11. Core réteg

A core réteg feladata, hogy minden oldal számára egységes technikai alapot biztosítson. Itt nincsenek planner- vagy CRM-specifikus üzleti szabályok.

`core/base.js`

A legalapvetőbb helper-eket tartalmazza.

window.AppCore = window.AppCore || {}
window.AppCore.BASE
window.AppCore.$(id)

window.AppCore.BASE = window.location.pathname.startsWith("/wedding-planner-dj")
  ? "/wedding-planner-dj"
  : "";

A BASE a későbbi API és linképítések alapja. Ha hibás, akkor az összes relatív API hívás elromlik.

`core/api.js`

Egységes fetch wrapper réteg.

apiGet(url, options)
apiPost(url, body, options)
apiDelete(url, options)

if (!json.ok) {
  throw new Error(json.error || "API hiba.");
}

Ez a wrapper biztosítja, hogy az összes modul ugyanúgy kezelje a backend { ok:false } válaszait.

`core/formar.js`

Közös formázási és normalizálási helper-ek.

escapeHtml(v)
normalizeText(v)
toNumberOrZero(v)
formatMoney(v)
truthy(v)

Helper	Használat	Fő modulok
`escapeHtml`	biztonságos HTML render stringekben	calendar, crm, dashboard, djview
`normalizeText`	query, összehasonlítás, option kezelés	crm, planner
`toNumberOrZero`	pénzügyi számítások	planner-finance, crm-finance, djview-render
`formatMoney`	dashboard, CRM kiegészítő UI	dashboard-render, crm-finance
`truthy`	bool-szerű mezők értelmezése	planner, crm, djview-timeline

12. UI réteg

A közös UI szintet a ui/ui-modal.js képviseli. Ez nem általános UI framework, hanem egy célzott közös modul a planner és a CRM közös modal igényeire.

`ui/ui-modal.js`

getModalRefs() – app modal DOM elérések
getPdfModalRefs() – PDF progress DOM elérések
showAppModal({...}) – info / success / warning / error modal
closeAppModal(result)
showPdfProgressModal(message)
finishPdfProgressModal(success, message)
hidePdfProgressModal()
bindModalEvents()

Hol használjuk?

planner save előtti validációs hibák
planner save alatti PDF progress
CRM quote generálás
CRM follow-up visszatöltés
törlési megerősítések

Mit nem kezel?

dashboard auth overlay
dj-view price modal
egyedi inline hibadobozok

A modul a meglévő HTML ID-kre támaszkodik: appModal, appModalOkBtn, pdfProgressModal stb. Ezért csak olyan oldalon használható, ahol ezek ténylegesen jelen vannak.

13. Planner modulrendszer

A planner lett a legnagyobb mértékben feature-ökre bontva. Az eredeti app.js logikája most több jól elkülöníthető részben él tovább.

Planner namespace-ek

PlannerApp

PlannerFinance

PlannerSearch

PlannerSignature

PlannerTemplates

PlannerVenues

PlannerAcceptedQuotes

Fő logikai bontás

PlannerApp – orchestration
PlannerFinance – összegzés és billing UI
PlannerSearch – keresés, statisztika, visszatöltés
PlannerSignature – aláírás és csatolmányok
PlannerTemplates – sablonok
PlannerVenues – helyszínek
PlannerAcceptedQuotes – elfogadott ajánlatok

A planner refaktor nem változtatja meg a wizard szerkezetét, a mezőket vagy a mentési payloadot. A cél itt kizárólag a felelősség-szétválasztás volt.

14. planner-app.js részletesen

A planner-app.js a planner oldal fő entrypointja és koordinátora. Nem minden logika lakik itt, de ez indítja és hangolja össze a teljes planner oldalt.

Fő state-ek

currentStep
GENRES_BY_EVENT

Fő feladatok

wizard léptetés
event type UI kapcsolás
payload összeállítás
validáció
save / reset / autotimeline
feature modulok inicializálása

Fontos metódusok

showStep(n)
getEventType()
renderGenres(selected)
syncCeremonyMusicLocks()
syncConditionalSections()
syncEventTypeUI()
applyTemplate(templateId)
checkConflicts()
validateForm(payload)
getPayload()
setPayload(p)
savePlanner()
generateAutoTimeline()
resetPlanner()
initApp()

Mire támaszkodik?

PlannerFinance.syncStep4UI()
PlannerTemplates.loadTemplateIndex()
PlannerVenues.loadVenues()
PlannerSignature.initSignaturePad()
PlannerSearch.initSearchCollapse()
PlannerAcceptedQuotes.loadPlannerAcceptedQuotes()
UiModal megerősítésekhez és hibákhoz

A PlannerApp egyik fontos szerepe, hogy a többi modul működését helyes sorrendben inicializálja. A feature modulok önmagukban nem garantálják a teljes oldal működését.

15. planner-finance.js részletesen

Ez a modul a planner pénzügyi logikáját viszi: összegszámítás, hátralék, átutalási mezők, számlázási blokk láthatóság.

State

transferConfigCache

Backend függés

GET /api/payment-transfer-config

Fő metódusok

loadTransferConfig()
applyTransferConfig()
clearTransferFields()
updateTransferAmountField()
getExtraServicesTotal()
recalcFinance()
syncBillingUI()
syncStep4UI()

Üzleti szabályok

effect gépek automatikusan növelik a végösszeget
hátralék = végösszeg - előleg
átutalás esetén bank mezők kötelező relevanciát kapnak
számlázás esetén invoice section látható
fizetett státusz alapján invoice number mező láthatóság változik

const total = Math.max(0, base + travel + extras - discount);
const remaining = Math.max(0, total - deposit);

A modul nem ment adatot önmagában. A számított értékeket az input mezőkbe írja vissza, és a mentés során a PlannerApp.getPayload() olvassa ki őket.

16. planner-search.js részletesen

A planner-search.js kezeli a kereső / visszatöltő panelt, a statisztikai összesítést és a találatok részleges műveleteit.

Fő metódusok

initSearchCollapse()
openSearchPanel()
runSearch()
renderSearchResults(items)
toggleStats()
bindSearchEvents()

API függések

GET /api/sessions
GET /api/session/:stamp
DELETE /api/session/:stamp
GET /api/stats

UI funkció	Modul metódus	Backend route
keresés	`runSearch()`	`GET /api/sessions`
statisztika	`toggleStats()`	`GET /api/stats`
visszatöltés	találati gomb → `PlannerApp.setPayload()`	`GET /api/session/:stamp`
törlés	találati gomb → `apiDelete()`	`DELETE /api/session/:stamp`

A keresőmodul jó példa arra, hogy a refaktor nem csak fájlokat bont szét, hanem a felhasználói interakciók külön felelősségi területre kerülnek.

17. planner-signature.js részletesen

Ez a modul felel a signature canvas kezeléséért és a planner mellékletek listájáért.

Fő state-ek

attachments
currentSignatureFile
signaturePad
signatureCtx
signatureDrawing
signatureDirty

Fő metódusok

initSignaturePad()
clearSignaturePad()
getSignatureDataUrl()
drawSignatureFromDataUrl()
renderAttachments()
setAttachments()
pushAttachment()
clearAttachments()
setCurrentSignatureFile()
getCurrentSignatureFile()

A modul önmagában nem tölt fel semmit a szerverre. A feltöltést a PlannerApp.savePlanner() végzi, amely a canvas dataURL-ből blobot képez, majd /api/upload hívást indít.

18. planner-templates.js részletesen

A planner template modul a sablonindex és az egyes sablon JSON fájlok betöltését végzi.

Fő state

templateIndex
templateCache

Fő metódusok

loadTemplateIndex()
getTemplateIndex()
renderTemplateOptions()
renderSearchTemplateOptions()
loadTemplateById(templateId)

const response = await fetch(`${BASE}/templates/index.json`, { cache: "no-store" });

A template modul csak adatbetöltést végez. A template tényleges alkalmazása a planner oldalon a PlannerApp.applyTemplate() feladata.

19. planner-venues.js részletesen

A venue modul a helyszínlista API integrációját és az „Egyéb…” helyszín logikát választja le a planner főappból.

State

venuesData = { options: [] }

Fő metódusok

loadVenues(selectedValue)
renderVenueOptions(selectedValue)
saveVenueIfNeeded()
getVenueValue()
bindVenueEvents()

Szituáció	Mi történik?
betöltött venue megtalálható a listában	a select ugyanarra az értékre áll
betöltött venue nincs a listában	a select `__other__` értékre vált, a custom input feltöltődik
felhasználó `__other__`-t választ	a custom venue mező láthatóvá válik
save közben `__other__` van kiválasztva	a modul új venue-t ment az API-n keresztül

20. planner-accepted-qoutes.js részletesen

Ez a modul az accepted státuszú quote-ok planner oldalra történő előtöltését kezeli. Különösen fontos, mert itt a quote és a planner közti hídlogika jelenik meg.

State

plannerAcceptedQuotes

Fő metódusok

loadPlannerAcceptedQuotes()
renderPlannerAcceptedQuoteOptions()
inferEventTypeFromQuote()
inferTemplateIdFromQuote()
applyAcceptedQuoteToPlanner()
loadSelectedAcceptedQuoteIntoPlanner()
bindAcceptedQuoteEvents()

Az inferEventTypeFromQuote() és inferTemplateIdFromQuote() azért fontos, mert nem minden accepted quote hordoz teljesen egyértelmű planner template információt. A modul ezért következtető logikát is tartalmaz.

21. CRM modulrendszer

A CRM refaktor a quote-kezelés monolit logikáját bontja szét pénzügyre, follow-up-ra, template-kezelésre és az ezek fölött álló orchestratorra.

CRM namespace-ek

CrmApp

CrmFinance

CrmFollowup

CrmTemplates

Fő logikai bontás

CrmApp – fő entrypoint és quote műveletek
CrmFinance – effect / extra / végösszeg számítás
CrmFollowup – korábbi quote visszatöltés és törlés
CrmTemplates – quote sablonok

22. crm-app.js részletesen

A CRM fő entrypointja. Betölti a kapcsolt planner sessiont, összefogja a quote form állapotát, kezeli a generálást és a törlést.

State

currentSessionRecord
currentGeneratedQuoteStamp

Fő metódusok

getCurrentSessionRecord()
getCurrentGeneratedQuoteStamp()
setCurrentGeneratedQuoteStamp()
renderEventInfo()
collectQuotePayload()
setResultLinks()
clearResultLinks()
loadSessionIfExists()
generateQuotePdf()
deleteGeneratedQuote()
bindCrmEvents()
initCrm()

A CrmApp a CRM oldalon több más modul szolgáltatásait használja, de a felhasználó számára még mindig ez viselkedik „a CRM oldal logikájaként”.

23. crm-finance.js részletesen

A CRM pénzügyi modulja főként az ajánlati összegek számítását és az eseményből felismert effect gépek kezelését végzi.

Fő metódusok

effectListFromPayload(p)
getQuoteExtrasTotal()
effectTotalFromPayload(p)
recalcQuoteFinance()
setDetectedEffectsFromEvent()
setDefaultDates()

Fontos szabályok

buborék gép +10 000 Ft
hidegszikra +60 000 Ft
nehézfüst +60 000 Ft
a végösszeg = alapár + extrák - kedvezmény
kapcsolt eventből effect mezők felismerhetők

24. crm-follwup.js részletesen

A follow-up modul kezeli az ajánlat és utókövetés mód közti váltást, a korábbi ajánlatok listáját, azok visszatöltését és törlését.

Fő metódusok

getDocumentModeValue()
syncDocumentModeUi()
loadFollowupQuoteOptions(autoLoadFirst)
loadSelectedQuoteIntoFollowup(showSuccessModal)
deleteSelectedFollowupQuote()

API függések

GET /api/quotes
GET /api/quote/:stamp
DELETE /api/quote/:stamp

A modul képes a kapcsolt planner esemény adatai alapján a korábbi quote-okat leszűrni, így a follow-up dropdown nem a teljes quote univerzumot mutatja.

25. crm-templates.js részletesen

A CRM template modul a quote sablonok betöltését és az ajánlati űrlapra való alkalmazását végzi.

State

templateIndex
templateCache

Fő metódusok

loadTemplateIndex()
renderTemplateOptions()
loadTemplateById(templateId)
buildFallbackTemplateDescription(templateData, eventPayload)
applyTemplateToQuoteForm(templateId)

A modul nem csak betölt, hanem fallback logikát is ad: ha nincs direkt package description, akkor a template meta és a kapcsolt event payload alapján állít össze leírást.

26. Dashboard modulrendszer

A dashboard refaktor célja az volt, hogy az auth, a render és a főapp logika különváljon.

Dashboard namespace-ek

DashboardApp

DashboardAuth

DashboardRender

Bontás előnye

auth hibák könnyebben izolálhatók
render helper-ek külön tesztelhetők
main app csak orchestrationt végez

27. dashboard-app.js részletesen

A dashboard fő entrypointja, amely kezeli az unlock folyamatot, az overlay-t és a summary betöltést.

State / konstans

DASHBOARD_AUTH_KEY

Fő metódusok

setText(id, value)
unlockDashboardUi()
setAuthError(message)
checkDashboardPassword()
loadDashboard()
bindDashboardEvents()
initDashboard()

A dashboard oldalon nincs általános modal modul. Itt az auth overlay és az inline auth hiba saját, oldal-specifikus megoldásként marad.

28. dashboard-auth.js részletesen

Egyetlen, jól izolált feladata van: a dashboard jelszó ellenőrzése.

async function verifyDashboardPassword(password) {
  const response = await fetch(`${BASE}/api/auth/dashboard`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ password })
  });
  ...
}

Ez tipikus példa arra, amikor külön fájlba bontás kis kockázattal nagy átláthatósági nyereséget ad.

29. dashboard-render.js részletesen

A dashboard render modul HTML stringeket gyárt a summary alatti listákhoz és a next-event blokkhoz.

Fő metódusok

renderDashList(items, options)
renderAlertList(items, emptyText)
renderNextEventBox(item)

Miért külön fájl?

a dashboard-app kisebb lett
a render logika könnyebben áttekinthető
később könnyebben cserélhető vagy bővíthető

30. calendar-app.js részletesen

A naptár jelenleg egyetlen feature modulban maradt, mert a logikája önmagában is jól körülhatárolható.

State

currentMonth
calendarData
selectedDate

Fő metódusok

updateUrlMonth(month)
dayTitle(dateStr)
renderDayList(dateStr)
renderCalendar()
loadCalendar(monthOverride)
bindCalendarEvents()
initCalendar()

A calendar modul fontos javítása, hogy az API által visszaadott it.ics mezőt használja. Ez megszünteti a korábbi kézi útvonal-összerakás kockázatát.

31. DJ View modulrendszer

A DJ preview refaktor bontja a timeline logikát, a price unlock authot, a HTML renderelést és az auto-refresh működést.

DJ View namespace-ek

DjViewTimeline

DjViewAuth

DjViewRender

DjViewApp

Refaktor előnye

timeline algoritmus külön tesztelhető
price modal auth elszigetelt
render különválik az adatlekéréstől
konzisztensebb a planner / CRM / dashboard mintával

32. djview-timeline.js részletesen

A timeline modul kizárólag az időalapú eseménysor összeállításával foglalkozik.

Fő metódusok

toMinutes(timeStr)
pad2(n)
minutesToTime(totalMinutes)
splitCeremonyTimeline(startTime, endTime, stepsCount)
parseEventDate(value)
buildDateTimeFromEvent(dateValue, timeValue, isNextDay)
buildWeddingTimeline(p)
buildGenericEventTimeline(p)
buildTimeline(p)
annotateTimeline(timeline, eventDate)
computeTimelinePhase(timeline)
computeNextEvent(timeline, eventType)

Mit nem csinál?

nem kér API-t
nem ír DOM-ot
nem kezeli a password modalt
nem kezeli a PDF gombokat

A modul időlogikája kritikus, mert a preview egyik legfontosabb eleme a „Most / Következik / Elmúlt” állapotok helyes megjelenítése.

33. djview-auth.js részletesen

Az árfeloldás és a password modal logika külön modulként él. Ez a dashboard auth mintájához hasonlóan különválasztja az auth jellegű működést a render és az adatbetöltés logikától.

Tipikus elemek

verifyPricePassword(password)
getPriceModalRefs()
openPriceModal()
closePriceModal(result)
showPriceModalError(message)
bindPriceModal()
handlePriceToggle()

Felelősség

ármezők rejtett/látható állapotának kezelése
jelszó bekérése
auth endpoint hívása
hibás jelszó kezelés

34. djview-render.js részletesen

Ez a modul a preview teljes HTML szerkezetét építi fel, a timeline adatokból és a session payloadból.

Tipikus render helper-ek

renderBlockTitle()
renderTimeline()
renderPills()
renderKV()
különböző kártya renderelők: contact, finance, transfer, billing, template, approval

Külön szabályok

esküvő és non-wedding jobb oldali kártyái eltérnek
árak rejtetten vagy láthatóan renderelhetők
timeline state osztályok külön CSS állapotokat kapnak

35. djview-app.js részletesen

A DJ View entrypoint a session rekord lekérését, a render meghívását, a gombok bekötését és az auto refresh kezelését végzi.

State

refreshTimer
a price unlock állapot auth modulban vagy app modul szintjén kezelhető

Fő metódusok

getParam(name) vagy AppCore alapú megfelelő
loadView()
startAutoRefresh()
reload gomb bind
toggle price bind
init()

Az app modul feladata, hogy a session lekérés eredményét átadja a render modulnak, és biztosítsa a 30 másodperces automatikus újratöltést.

36. Frontend modul → endpoint mátrix

Ez a mátrix azt mutatja meg, hogy a refaktorált frontend modulok pontosan mely backend végpontokat használják.

Frontend modul	Használt endpointok	Fő cél
`PlannerApp`	`POST /api/upload` `GET /api/conflicts` `POST /api/autotimeline` `POST /api/sessions`	mentés, konfliktusellenőrzés, automatikus menetrend
`PlannerSearch`	`GET /api/sessions` `GET /api/session/:stamp` `DELETE /api/session/:stamp` `GET /api/stats`	keresés, visszatöltés, törlés, statisztika
`PlannerVenues`	`GET /api/venues` `POST /api/venues`	helyszínlista
`PlannerFinance`	`GET /api/payment-transfer-config`	átutalási adatok
`PlannerAcceptedQuotes`	`GET /api/planner-accepted-quotes` `GET /api/planner-accepted-quote/:stamp`	accepted quote alapú előtöltés
`CrmApp`	`GET /api/session/:stamp` `POST /api/quotes/generate` `DELETE /api/quote/:stamp`	kapcsolt esemény betöltése, quote generálás, törlés
`CrmFollowup`	`GET /api/quotes` `GET /api/quote/:stamp` `DELETE /api/quote/:stamp`	follow-up lista és visszatöltés
`DashboardAuth`	`POST /api/auth/dashboard`	dashboard védelem
`DashboardApp`	`GET /api/dashboard-summary`	summary és listák
`CalendarApp`	`GET /api/calendar`	havi naptár és napi lista
`DjViewAuth`	`POST /api/auth/price-view`	pénzügyi adatok feloldása
`DjViewApp`	`GET /api/session/:stamp`	preview adatbetöltés

37. Használt adatmodellek

A refaktorált frontend ugyanazokra az üzleti adatmodellekre épül, mint az eredeti rendszer. A különbség az, hogy most ezekhez több kisebb modul különböző részfeladatokkal kapcsolódik.

Planner payload

{
  "eventTemplate": "wedding_classic",
  "eventTemplateName": "Esküvő – klasszikus magyar",
  "eventType": "wedding",
  "coupleName": "Minta Pár",
  "eventDate": "2026-08-15",
  "venue": "Szeged - Kastélykert Birtok",
  "headcount": "150",
  "primaryContactName": "Teszt Elek",
  "primaryContactPhone": "+36 30 123 4567",
  "genres": ["Retro", "Pop"],
  "guestArrivalTime": "17:00",
  "dinnerTime": "19:00",
  "eventEndTime": "04:00",
  "serviceFeeBase": "250000",
  "paymentMethod": "átutalás",
  "invoiceNeeded": true,
  "signatureFile": "/uploads/signature.png",
  "attachments": ["/uploads/photo1.jpg"]
}

Quote payload

{
  "quoteNumber": "AJ-2026-0001",
  "quoteDate": "2026-03-12",
  "validFrom": "2026-03-12",
  "validUntil": "2026-03-19",
  "servicePeriodFrom": "2026-08-15T12:00",
  "servicePeriodTo": "2026-08-15T23:00",
  "packageName": "Esküvő – Prémium",
  "packageDescription": "Teljes DJ és fénytechnika",
  "basePrice": 250000,
  "extrasTotal": 60000,
  "discountAmount": 10000,
  "totalPrice": 300000,
  "paymentTerms": "50% előleg",
  "status": "draft",
  "paymentMethod": "átutalás",
  "documentMode": "offer"
}

Calendar response

{
  "ok": true,
  "month": "2026-08",
  "monthLabel": "2026. augusztus",
  "prevMonth": "2026-07",
  "nextMonth": "2026-09",
  "days": [
    {
      "date": "2026-08-15",
      "day": 15,
      "inMonth": true,
      "isToday": false,
      "items": [
        {
          "stamp": "minta_par_2026-08-15",
          "coupleName": "Minta Pár",
          "venue": "Szeged - Kastélykert Birtok",
          "eventType": "wedding",
          "pdf": "/data/minta_par_2026-08-15.pdf",
          "ics": "/data/minta_par_2026-08-15.ics"
        }
      ]
    }
  ]
}

Dashboard summary response

{
  "ok": true,
  "summary": {
    "totalEvents": 18,
    "todayCount": 1,
    "next7DaysCount": 4,
    "openFinanceCount": 3,
    "openFinanceTotal": 540000,
    "paidCount": 5,
    "paidTotal": 1200000,
    "contractedEvents": 12
  },
  "nextEvent": { "stamp": "..." },
  "todayItems": [],
  "next7Days": [],
  "openFinance": [],
  "incompleteItems": [],
  "alerts": {
    "missingDeposit": [],
    "missingInvoiceInfo": [],
    "missingSignature": [],
    "missingTimeline": []
  }
}

38. Frontend állapotmodellek

A refaktor egyik fontos hozadéka, hogy az oldalak lokális state-je jobban látszik. Ez hibakeresésnél és későbbi átalakításnál is nagy előny.

Oldal / modul	Fő state változók	Jelentés
`PlannerApp`	`currentStep`	wizard aktuális lépés
`PlannerSignature`	`attachments`, `currentSignatureFile`, `signatureDirty`	aláírás és melléklet állapot
`PlannerFinance`	`transferConfigCache`	átutalási config cache
`PlannerAcceptedQuotes`	`plannerAcceptedQuotes`	accepted ajánlatlista
`CrmApp`	`currentSessionRecord`, `currentGeneratedQuoteStamp`	kapcsolt event és generált ajánlat
`CrmTemplates`	`templateIndex`, `templateCache`	quote sabloncache
`CalendarApp`	`currentMonth`, `calendarData`, `selectedDate`	naptár állapot
`UiModal`	`modalResolver`, `pdfProgressInterval`, `pdfProgressValue`	modal és PDF progress állapot
`DjViewApp/Auth`	`refreshTimer`, `priceUnlocked`, `priceModalResolver`	preview refresh és price unlock állapot

39. HTML / DOM szerződések

A refaktor egyik legfontosabb hallgatólagos szerződése, hogy a modulok meghatározott DOM ID-k létezésére számítanak. Ezeket a dokumentáció explicit módon rögzíti.

UiModal által elvárt elemek

appModal
appModalIcon
appModalTitle
appModalSubtitle
appModalBody
appModalOkBtn
appModalCancelBtn
pdfProgressModal
pdfProgressFill
pdfProgressPercent
pdfProgressText

PlannerSignature által elvárt elemek

signaturePad
attachments
coupleName

CalendarApp által elvárt elemek

calendarGrid
monthLabel
selectedDayTitle
selectedDayList
prevMonthBtn
nextMonthBtn
reloadCalendarBtn

DJ View auth által elvárt elemek

priceModal
pricePasswordInput
priceModalError
priceModalOkBtn
priceModalCancelBtn
togglePriceBtn

Ha egy modul nem találja a szükséges DOM elemeit, az vagy csendes részleges hibát, vagy közvetlen futási hibát okozhat. Ezért a refaktor utáni HTML csere ellenőrzése külön regressziós pont.

40. Mentési folyamatok

A refaktor után a mentési folyamatok üzletileg ugyanazok maradtak, de technikailag több modul együttműködésében valósulnak meg.

Planner mentés PlannerApp.savePlanner() meghívja a PlannerFinance.syncStep4UI()-t, ellenőrzi az egyéb venue mentést, validál, opcionálisan signature uploadot végez, konfliktust ellenőriz, majd meghívja a POST /api/sessions route-ot.

Planner mentés utáni UI Result linkek beállítása, conflict notice render, kereső frissítése, PDF progress lezárása, siker modal megjelenítése.

CRM quote mentés CrmApp.generateQuotePdf() összeállítja a linked payloadot és a quote objektumot, elindítja a PDF progress modalt, majd POST /api/quotes/generate hívást végez.

CRM mentés utáni UI PDF link és JSON link beállítása, quote stamp elmentése, PDF progress befejezése, siker modal megjelenítése.

41. Betöltési folyamatok

A betöltési folyamatok a refaktorált frontendben több kisebb modul között oszlanak meg.

Planner oldal első betöltés PlannerApp.initApp() → genre render → UI sync → signature pad init → modal bind → search collapse → template index → venue lista → accepted quote lista → kereső bind → wizard bind → finance sync.

CRM oldal kapcsolt sessionnel CrmApp.loadSessionIfExists() → session payload betöltés → event info render → effect detect → default date kitöltés → finance recalc.

Dashboard belépés után DashboardAuth.verifyDashboardPassword() → auth overlay eltűnik → DashboardApp.loadDashboard() → summary és listák renderelése.

Calendar oldal CalendarApp.loadCalendar() → API válasz → selectedDate kiválasztás → havi grid render → napi lista render.

DJ preview oldal DjViewApp.loadView() → session betöltés → DjViewTimeline.buildTimeline() → DjViewTimeline.annotateTimeline() → DjViewRender.render().

42. Hibakezelési stratégia

A v2 frontend hibakezelése részben egységesebb lett az AppCore.api* wrapper miatt, de továbbra is oldal-specifikus UI visszajelzések maradtak.

Közös minták

apiGet/apiPost/apiDelete kivételt dobnak, ha ok:false
a planner és CRM több helyen UiModal-t használ
a dashboard auth saját inline hibát használ
a DJ View saját modal hibaszöveget használ

Tipikus megjelenítési formák

modal warning
modal success
modal error
inline error box
empty-box placeholder
console.error fejlesztői célra

A frontend refaktor után a hibák forrása könnyebben lokalizálható: API réteg, render réteg, event bind réteg vagy HTML hiányzó elem.

43. Átállási útmutató a régi script-ekről

A v2-re való átállás során a régi oldalankénti script hivatkozások cserélődnek le az új moduláris útvonalakra.

Régi script	Új script-ek
`app.js`	`core/base.js`, `core/api.js`, `core/formar.js`, `ui/ui-modal.js`, `planner/*.js`
`crm.js`	`core/base.js`, `core/api.js`, `core/formar.js`, `ui/ui-modal.js`, `crm/*.js`
`dashboard.js`	`core/base.js`, `core/api.js`, `core/formar.js`, `dashboard/*.js`
`calendar.js`	`core/base.js`, `core/api.js`, `core/formar.js`, `calendar/calendar-app.js`
`dj-view.js`	`core/base.js`, `core/api.js`, `core/formar.js`, `djview/*.js`

Az átállás során a régi és az új script-eket nem szabad egyszerre bent hagyni ugyanazon az oldalon, mert duplikált bind, duplikált init vagy felülírt namespace lehet a következmény.

44. Tesztelési forgatókönyvek

A refaktorált frontend akkor tekinthető funkcionálisan stabilnak, ha az alábbi végponti és UI forgatókönyvek sikeresen lefutnak.

1. Planner – üres indulás Töltsön be a wizard, jelenjen meg az első lépés, működjön a léptetés, legyen alapértelmezett approval date.

2. Planner – template betöltés Event template select változásra töltsön elő mezőket, változzon a genre lista, frissüljön a Step 4 UI.

3. Planner – venue és egyéb helyszín __other__ választáskor jelenjen meg a custom input, mentéskor az új venue kerüljön elmentésre.

4. Planner – finance Effect gépek, kedvezmény, előleg, payment method és invoice checkbox változásra a pénzügyi mezők helyesen frissüljenek.

5. Planner – signature és attachment Canvas aláírás működjön egérrel és touch-al, attachment chip lista frissüljön.

6. Planner – save PDF progress modal fusson, létrejöjjön a JSON / PDF / ICS, megjelenjen a result blokk.

7. Planner – search és stats Collapse panel nyíljon, a search eredményekből működjön a visszatöltés és törlés.

8. Planner – accepted quote import Elfogadott ajánlatból a planner mezők, template és finance értékek helyesen töltődjenek vissza.

9. CRM – kapcsolt event betöltés ?stamp= paraméterrel töltse be a session alapadatait és effect gépeit.

10. CRM – template Quote template kiválasztás után package name, description és base price frissüljön.

11. CRM – follow-up Document mode váltáskor a followup card jelenjen meg vagy tűnjön el, a korábbi quote lista töltődjön, a visszatöltés működjön.

12. CRM – quote generálás és törlés PDF progress fusson, a result link létrejöjjön, a törlés után eltűnjön.

13. Dashboard Helyes jelszóval unlockoljon, hibás jelszóval maradjon zárolva, summary és listák töltődjenek be.

14. Calendar Előző/következő hónap működjön, selectedDate változzon, napi lista és PDF / ICS / DJ Preview linkek helyesek legyenek.

15. DJ View Timeline épüljön, next event blokk jelenjen meg, price unlock működjön, auto refresh fusson.

45. Regressziós ellenőrzőlista

Script és namespace

minden oldalon betöltődik a megfelelő assets/JS/... fájl
nincs 404 script hiba
nincs window.XYZ is undefined hiba
nincsenek duplikált init-ek

Planner

wizard léptetés jó
genres és eventType UI jó
finance helyes
signature működik
save után result link él

CRM

kapcsolt session betölt
quote template működik
follow-up lista helyes
delete nem hagy broken linket

Dashboard / Calendar / DJ

dashboard auth ok
calendar havi váltás ok
DJ price unlock ok
DJ auto refresh ok

46. Ismert korlátok

Jelenlegi korlátok

a backend még nem lett service / utils rétegre bontva
a frontend továbbra is globális namespace-eket használ
a script sorrend kézi karbantartást igényel
több történelmi fájlnév-elírás megmaradt
nincs automatikus build vagy lint réteg

Refaktor utáni logikus következő lépések

backend utility/service bontás
route callback-ek szervezettebb kinyerése
naming cleanup külön körben
schema validation szigorítása
később opcionális modulrendszer vagy bundling

47. Fejlesztői megjegyzések

A refaktor erősségei

a frontend felelősségek sokkal tisztábbak
könnyebb egy hibát lokalizálni
a közös helper-ek egyszer lettek leírva
az oldalak betöltési logikája dokumentálhatóbb és stabilabb
a későbbi backend bontáshoz jó előkészítés

Fontos óvintézkedések

HTML ID-khez nem szabad hozzányúlni kontroll nélkül
script sorrendet mindig dokumentáltan kell karbantartani
elírt fájlneveket csak külön cleanup körben szabad javítani
régi és új script-eket nem szabad keverni ugyanazon az oldalon

Ez a v2 dokumentáció a refaktorált frontend szerkezet hivatalos technikai leírásának tekinthető. Arra szolgál, hogy a rendszer a további bővítések, javítások és a későbbi backend szétbontás során is következetesen, ellenőrizhetően és visszakereshetően fejlődjön tovább.