Files

469 lines
10 KiB
Plaintext
Executable File
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
2⃣ TELJES FEJLESZTÉSI JELENTÉS (2026-01-31 állapot)
🔹 Projekt állapot: PRE-BETA / ARCHITEKTÚRA STABILIZÁLÁS
2.1. INFRASTRUKTÚRA ÁLLAPOT
✅ Docker alapú architektúra
Konténerek:
service_finder_api FastAPI backend
postgres-db PostgreSQL
redis cache / session / későbbi rate limit
minio objektumtár
nginx-proxy-manager későbbi élesítéshez
pgadmin DB admin
✔️ Konténerhálózat rendben
✔️ Környezeti változók Dockerből érkeznek
✔️ App újraépítés sikeres
2.2. KÖRNYEZETI VÁLTOZÓK (.env) RENDBE TÉVE
✅ Amit helyre tettünk
SECRET_KEY csak 1× szerepel
ALGORITHM csak 1×
DB paraméterek egységesítve
SendGrid + SMTP fallback elkészítve
App-szintű DB user (service_finder_app) elkülönítve
Superadmin (kincses) megmaradt
✔️ Ez már éles kompatibilis struktúra
2.3. ADATBÁZIS JOGOSULTSÁGOK KÉSZ
✅ service_finder_app
LOGIN = true
USAGE schema data
SELECT / INSERT / UPDATE / DELETE minden táblán
USAGE / SELECT / UPDATE sequence-eken
ALTER DEFAULT PRIVILEGES beállítva
👉 Ez nagyon jó minőségű, biztonságos megoldás
👉 Superadmin nem zárható ki a DB-ből
2.4. AUTH & SECURITY NAGY ELŐRELÉPÉS
✅ Elkészült
JWT alapú auth (HS256)
Központi password policy (settings)
Tokenek hash-elve tárolva
Email verify / password reset logika
Anti-enumeration (forgot password mindig azonos válasz)
Token TTL kezelve
SendGrid API elsődleges, SMTP fallback
❗ Tudatos döntés
OAuth2PasswordRequestForm marad
JWT payload minimalista (sub, is_admin)
Stateless auth (később Redis session bővíthető)
2.5. TOKEN KEZELÉS ÁTALAKÍTÁS FOLYAMATBAN
✅ Amit tisztáztunk
Nem törlünk tokeneket automatikusan
Soft-delete elv
Token:
expires_at
is_used
auditálható
❌ Ami még nincs véglegesítve
Token archíválás
Admin UI kezelés
Több kommunikációs csatorna (Telegram, WhatsApp stb.)
2.6. PERSON ↔ USER ↔ COMPANY MODELL STRATÉGIA KÉSZ
✅ DÖNTÉS MEGSZÜLETETT
Person = valódi személy életút
User = technikai belépési identitás
Company = jogi / üzleti entitás
Soft delete mindenhol
Új regisztráció:
új user
ugyanahhoz a person-höz kapcsolható
Rossz értékelés nem tűnik el
❌ Ami még hátra van
persons tábla létrehozása
users.person_id
companies.owner_person_id
Backfill meglévő adatokra
Alembic vagy dokumentált SQL migráció
⚠️ Itt megálltunk technikailag, de a logika teljesen tiszta
2.7. REGISZTRÁCIÓS SZINTEK LOGIKA KÉSZ
Tervezett szintek
Felhasználók
Free
Premium
Premium+
Cégek
Free
VIP
VIP+
Elv
Free: minimális adat
Upgrade → kötelező validáció
KYC-szerű ellenőrzés később
❌ Implementáció még nincs
✔️ Architektúra támogatja
2.8. MIGRÁCIÓ JELENLEGI ÁLLAPOT
Alembic mappa létezik
Automatikus migráció NINCS
Kézi SQL futtatás közben:
ADD CONSTRAINT IF NOT EXISTS → Postgres nem támogatja
DO $$ → pgAdmin / psql verziófüggő hiba
👉 Holnap ezt egy PG-kompatibilis, biztos SQL-re javítjuk
3⃣ MI KÉSZ, MI VAN HÁTRA (CHECKLIST)
✅ ELKÉSZÜLT
Docker architektúra
.env rendbetéve
DB role & privilege modell
Auth v2 stabil
Email rendszer (SendGrid + fallback)
Token policy elvi döntések
Person/User/Company koncepció
Soft delete stratégia
🔧 HÁTRAVAN (KÖVETKEZŐ NAPOK)
Persons + owner_person SQL migráció (javított verzió)
Backfill script (user → person)
Auth.py frissítés person logikával
Subscription tier kezelés backend oldalon
Rate limit / brute force védelem (Redis)
Audit & security logging
Alembic stratégia véglegesítése
Admin kontrollpontok előkészítése
ZÁRÁS
👉 Nagyon jó állapotban van a projekt.
👉 Amit ma csináltunk, az alapozás, nem látszik, de kritikus.
👉 Holnap strukturáltan, tisztán tudjuk folytatni, nincs adósság.
Ha szeretnéd, holnap a következő lépést én indítom egy “1⃣ lépés persons migráció (javított)” tervvel, és onnan megyünk tovább.
____________________________________________________________________
Idővonal (2026-01-30) FRISSÍTETT
(nap közben) Konténerek futnak, erőforrás stabil.
~17:09 körül API route tesztek, /openapi.json 404, /api/v2/openapi.json OK.
(később) Több auth teszt:
register egyes emaillel 400, info@profibot.hu 200
login 200
forgot-password 404 (POST-tal)
users/me 404 (GET)
(később) DB stat lekérés: seed adatok igazolva (7k fuel station + 7k provider)
(később) Alembic konténerben OK (current=head)
(később) Frontend forrásban hardcoded API URL-ek és V1 route hívások azonosítva
Idővonal (2026-01-30)
Ahol nincs pontos timestamp, ott a kimenetből és a file-mtime-okból következtetek (percre pontos rekonstrukciót majd log fájlokból lehet).
~Jan 29 (kb. 21:0022:00)
A service_finder compose stack elindul (konténerek “20 hours ago / 17 hours ago” jelleg).
2026-01-30 17:09 (curl header alapján, GMT-ben 17:09:57, HU időben +1)
API smoke test:
/openapi.json 404
/docs 200
/ 200 (status online)
2026-01-30 ~17:58
api_spec.json létrejön (de 404 tartalommal, 22 byte)
2026-01-30 (nap közben / este)
api_spec_v2.json mentve /api/v2/openapi.json-ról (12600 byte), route-ok ellenőrizve jq-val
2026-01-30
DB elérésnél kiderül: postgres role nincs; helyes admin user: kincses
2026-01-30
Backend routerek és frontend view-k feltérképezése; Alembic CLI hiány és MinIO access denied rögzítve
IDŐVONAL — 2026-01-30 (frissítve)
17:09:57 — /openapi.json 404, /docs 200, root / 200 online/version
17:58 — api_spec.json (hibás endpoint miatt 404 tartalom) létrejön
később — fájlrendszer snapshot (ls/find/du, logs üres)
később — compose render + docker compose ps + last200 log mentések
később — psql -U postgres → “role postgres does not exist”
most — /api/v2/openapi.json mentés sikeres → api_spec_v2.json 12 600 byte
most — endpoint-lista kinyerve (v1 + v2 vegyes)
IDŐVONAL — 2026-01-30 (konkrét időbélyegekkel, ahol van)
17:58 — api_spec.json létrejön/írás (api_spec.json timestamp)
17:09:57 — API ellenőrzések (headerben):
/openapi.json → 404
/docs → 200, Swagger UI
/ → 200, status json
~18:xx — fájlrendszer snapshot (ls, find, du, logs)
~18:xx — compose render + docker compose ps, log exportok
~18:xx — psql -U postgres kísérlet → role nincs
IDŐVONAL — 2026-01-30
Időpontok: a parancsokhoz konkrét óra:perc nem volt rögzítve a másolatban, ezért sorrendi idővonalat adok (ez stabil, később időbélyeggel pontosítható).
Docker futó konténerek ellenőrzése (docker ps)
Compose projektek listázása (docker compose ls)
Compose szolgáltatások állapotának listázása (docker compose ps)
OpenAPI export kísérlet (curl .../openapi.json > api_spec.json) → 22 byte-os eredmény, anomália
RENDSZERFELTÁRÁS — mi kész, mi nincs kész (jelen bizonyítékok alapján)
Ami biztosan kész / működik
Alaprendszer Compose-ban fut: service_finder stack “running(9)”.
Frontend él: port 3000 publikusan kint.
API él: port 8000 publikusan kint.
Postgres él és healthy: postgres:15, publikus 5432.
Redis él.
MinIO él.
Admin eszközök élnek: pgAdmin (5050), NPM (80/81/443), Dozzle (8888), code-server (8443).
Létezik lokális projekt struktúra és volume-ok: /opt/service_finder/... alatt backend, frontend, logs, migrations, postgres_data, redis data, proxy-manager adatok.
filesystem_map
Ami valószínűleg nincs kész / hibás / tisztázandó
OpenAPI endpoint: a mentett fájlméret alapján nem jó választ ad az /openapi.json (vagy nem ott van, vagy proxy/route gond).
Biztonsági hardening: Postgres jelenleg 0.0.0.0:5432-n lóg (ez később sürgős).
Migrációs konzisztencia: van migrations struktúra a fájlrendszerben (több helyen is), de nem tudjuk, hogy DB-séma ténylegesen “head”-en van-e.
filesystem_map
FÁJLRENDSZER-HELYZETKÉP (amit már látunk)
A feltöltött map alapján a fontos csomópontok:
Projekt gyökér: /opt/service_finder
filesystem_map
Backend kód: /opt/service_finder/backend (+ app/, models/, auth/, schemas/, templates/, migrations/versions)
filesystem_map
Frontend kód: /opt/service_finder/frontend (+ src/views/admin, router, stores, services, components, public, node_modules)
filesystem_map
Log könyvtár: /opt/service_finder/logs
filesystem_map
Postgres adatok: /opt/service_finder/postgres_data/... (és van egy /opt/service_finder/postgres/data/... jellegű ág is)
filesystem_map
Redis data: /opt/service_finder/redis/data/...
filesystem_map
NPM/Proxy manager adatok + LE: /opt/service_finder/proxy-manager/...
filesystem_map
Megjegyzés: a map alapján mintha két postgres adatútvonal is jelen lenne: postgres/data és postgres_data. Ezt tisztázni kell, nehogy két külön volume/útvonal keveredjen (backup, restore, space, stb.).
filesystem_map
ADATBÁZIS-HELYZETKÉP (a feltöltött táblalistád alapján)
A feltöltött tablak_2026.01.30_0.csv alapján a data sémában 54 tábla van. (Ezt használom alapnak a DB audit lépések priorizálásához.)
A következő lépésben ebből fogok csinálni:
“core domain” csoportosítást (org/account/auth/vehicle/provider/request/evidence/stb.),
és egy “migráció és integráció” ellenőrző checklistet (táblák + FK + index + RLS jelek).
📜 PROJEKT IDŐVONAL — HIGH-LEVEL TIMELINE
Phase 1 — Core Foundations (2026-01-27)
DB core stabil
Config engine
Auth + Email
Enum & integrity fixes
Phase 2 — Fleet & Vehicle Core (2026-01-28)
Jármű hierarchia
VIN rendszer
Variant bővítés
Seed & backup
Phase 3 — Service Search & Matching (2026-01-28)
Provider geo-keresés
Ranking engine
Match API
Phase 4 — Infrastructure & Stability (2026-01-29)
Docker stack
Storage
Backup
Phase 5 — UI & MVP Presentation (2026-01-30)
Frontend
Dashboard
Expense UI
Phase 6 — Governance & Scaling (2026-01-30)
Log governance
Project memory
Audit readiness
✅ KÖVETKEZŐ FÁZIS: RENDSZER FELTÁRÁS (AUDIT)
Most átlépünk ebbe az üzemmódba:
🎯 Cél
Objektíven feltárni:
mi van KÉSZ
mi FÉLKÉSZ
mi HIÁNYZIK
mi TECHNIKAI ADÓSSÁG