refakotorálás előtti állapot
This commit is contained in:
Roo
92
.roo/history.md
Normal file
92
.roo/history.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# Service Finder Fejlesztési Történet
|
||||
|
||||
## 17-es Kártya: Billing Engine Service (Epic 3 - Pénzügyi Motor)
|
||||
|
||||
**Dátum:** 2026-03-09
|
||||
**Státusz:** Kész ✅
|
||||
**Kapcsolódó fájlok:** `backend/app/services/billing_engine.py`, `backend/app/api/v1/endpoints/billing.py`
|
||||
|
||||
### Technikai Összefoglaló
|
||||
|
||||
A Billing Engine Service-t az Epic 3 (Pénzügyi Motor) keretében implementáltuk, amely a 18-as kártya atomi tranzakciós logikájára épül. Az implementáció egyszerűsített interfészeket biztosít a gyakori számlázási műveletekhez, miközben megtartja az alapvető négyszeres wallet rendszert és a dupla könyvelést.
|
||||
|
||||
#### Főbb Implementációk:
|
||||
|
||||
1. **Új funkciók a `billing_engine.py`-ban** (689-880 sorok):
|
||||
- `charge_user()`: Atomiszámlázási tranzakciók felhasználóbarát wrapper-e
|
||||
- `upgrade_subscription()`: Előfizetési szintek frissítése árképzéssel és wallet levonással
|
||||
- `record_ledger_entry()`: Közvetlen naplóbejegyzés létrehozása kézi pénzügyi műveletekhez
|
||||
- `get_user_balance()`: Konszolidált wallet egyenleg lekérdezés minden wallet típusra
|
||||
|
||||
2. **Endpoint integráció** a `billing.py`-ban:
|
||||
- `/upgrade` endpoint most a `upgrade_subscription()` funkciót használja
|
||||
- `/wallet/balance` endpoint most a `get_user_balance()` funkciót használja
|
||||
- Az API válasz struktúra változatlan maradt a visszafelé kompatibilitás érdekében
|
||||
|
||||
3. **Megtartott alapvető funkciók:**
|
||||
- Négyszeres wallet rendszer (EARNED, PURCHASED, SERVICE_COINS, VOUCHER)
|
||||
- Okos levonási sorrend: VOUCHER → SERVICE_COINS → PURCHASED → EARNED
|
||||
- Dupla könyvelés a FinancialLedger táblában
|
||||
- Atomis tranzakciós biztonság rollback-kel hibák esetén
|
||||
- FIFO voucher lejárat 10% díjjal (SZÉP-kártya modell)
|
||||
|
||||
#### Tesztelés és Validáció:
|
||||
|
||||
A `verify_financial_truth.py` teszt javítva lett és sikeresen validálja:
|
||||
- Stripe fizetés szimulációt
|
||||
- Belső ajándék átutalásokat
|
||||
- Voucher lejáratot díjakkal
|
||||
- Dupla könyvelés konzisztenciát a wallet-ek és a pénzügyi napló között
|
||||
|
||||
Minden teszt sikeresen lefut: "MINDEN TESZT SIKERES! A PÉNZÜGYI MOTOR ATOMBIZTOS!"
|
||||
|
||||
#### Függőségek:
|
||||
- **Bemenet:** Wallet modell, FinancialLedger modell, SubscriptionTier definíciók
|
||||
- **Kimenet:** Használják a számlázási endpointok, fizetésfeldolgozás és előfizetéskezelés
|
||||
|
||||
---
|
||||
|
||||
### Korábbi Kártyák Referenciája:
|
||||
- **15-ös kártya:** Wallet modell és négyszeres wallet rendszer
|
||||
- **16-os kártya:** FinancialLedger és dupla könyvelés
|
||||
- **18-as kártya:** Atomis tranzakciós manager és okos levonási logika
|
||||
- **19-es kártya:** Stripe integráció és fizetési intent kezelés
|
||||
|
||||
---
|
||||
|
||||
## 20-as Kártya: Subscription Lifecycle Worker (Előfizetés életciklus kezelése)
|
||||
|
||||
**Dátum:** 2026-03-09
|
||||
**Státusz:** Kész ✅
|
||||
**Kapcsolódó fájlok:** `backend/app/workers/system/subscription_worker.py`
|
||||
|
||||
### Technikai Összefoglaló
|
||||
|
||||
A 20-as Gitea kártya implementációja a lejárt előfizetések automatikus kezelésére. A worker napi egyszer fut (cron) és atomis tranzakcióban végzi a következőket:
|
||||
|
||||
1. **Lekérdezés:** Azokat a User-eket, ahol `subscription_expires_at < NOW()` és `subscription_plan != 'FREE'`
|
||||
2. **Downgrade:** `subscription_plan = "FREE"`, `is_vip = False`
|
||||
3. **Naplózás:** Főkönyvi bejegyzés (`SUBSCRIPTION_EXPIRED`) a `billing_engine.record_ledger_entry` segítségével
|
||||
4. **Értesítés:** Belső dashboard értesítés és email küldése a `NotificationService`-en keresztül
|
||||
|
||||
#### Főbb Implementációk:
|
||||
|
||||
- **Atomis zárolás:** `WITH FOR UPDATE SKIP LOCKED` a párhuzamos feldolgozás biztonságához
|
||||
- **Integráció a meglévő rendszerekkel:** A `billing_engine` és `notification_service` modulok használata
|
||||
- **Hibatűrés:** Egyéni felhasználóhibák nem akadályozzák a teljes folyamatot, statisztikák gyűjtése
|
||||
- **Logolás:** Dedikált logger (`subscription-worker`) a folyamat nyomon követéséhez
|
||||
|
||||
#### Futtatás:
|
||||
|
||||
```bash
|
||||
docker exec sf_api python -m app.workers.system.subscription_worker
|
||||
```
|
||||
|
||||
#### Függőségek:
|
||||
|
||||
- **Bemenet:** User modell (`subscription_expires_at`, `subscription_plan`, `is_vip`)
|
||||
- **Kimenet:** Módosított User rekordok, FinancialLedger bejegyzések, InternalNotification és email értesítések
|
||||
|
||||
---
|
||||
|
||||
*Megjegyzés a jövőbeli fejlesztésekhez:* A billing engine most már magas szintű funkciókat biztosít, amelyek elfedik a komplex atomis tranzakciós logikát. A jövőbeli kártyáknak ezeket a funkciókat kell használniuk, nem pedig közvetlenül manipulálniuk a wallet-eket vagy naplóbejegyzéseket.
|
||||
@@ -1,23 +1,24 @@
|
||||
# Service Finder Projekt Alkotmány
|
||||
# 🌍 GLOBAL SYSTEM RULES & WORKFLOW (Minden módra érvényes!)
|
||||
|
||||
## 1. Működési Alapelvek
|
||||
- **Elsődleges Igazság (2A):** A forráskód a mérvadó. A Wiki.js dokumentációnak követnie kell a kódot.
|
||||
- **Munkafolyamat (1B):** Terv (Architect) -> Jóváhagyás -> Megvalósítás (Code) -> Tesztelés -> Dokumentálás.
|
||||
- **Granularitás (3A):** Minden logikai egység (robot funkció) külön Focalboard kártyát kap.
|
||||
Te a Service Finder projekt egy specifikus AI ágense vagy. Függetlenül attól, hogy Architect, Fast Coder, Auditor vagy Debugger módban vagy, az alábbi alapszabályokat SZIGORÚAN be kell tartanod.
|
||||
|
||||
## 2. Eszközhasználati Szabályok
|
||||
- **Focalboard:** Minden munkafázist (Doing, Testing, Done) itt kell követni.
|
||||
- **Gitea:** Minden sikeres teszt után kötelező a commit, a kártya sorszámával a leírásban.
|
||||
- **Postgres:** A Wiki.js (postgres-wiki) tartalmát minden módosítás után ellenőrizni és frissíteni kell.
|
||||
## 🛡️ 1. KRITIKUS ADATBÁZIS BIZTONSÁG (DATA SAFETY)
|
||||
- **SOHA ne törölj éles (dev) adatot!** A `data`, `finance`, `identity` sémák az éles fejlesztői adatbázis részei.
|
||||
- **Tesztek futtatása:** Bármilyen tesztet (pl. Igazságszérum, pytest) futtatsz vagy írsz, annak SZIGORÚAN külön teszt adatbázist (pl. SQLite in-memory vagy `service_finder_test`) kell használnia.
|
||||
- **TILOS** a `DROP SCHEMA`, `DROP TABLE`, `TRUNCATE` vagy `Base.metadata.drop_all` parancsok használata az éles `DATABASE_URL` kapcsolaton!
|
||||
|
||||
## 3. Minőségbiztosítás (4-igen)
|
||||
- Nincs késznek jelentett kód automatizált tesztelés nélkül.
|
||||
- A terminálban futtatott tesztek kimenetét csatolni kell a feladat lezárásához.
|
||||
- A dokumentációs lánc kötelező elemei:
|
||||
1. Technikai leírás (kódban)
|
||||
2. Felhasználói manual vázlat (chatben)
|
||||
3. Wiki.js frissítés (Postgres-en keresztül).
|
||||
## ✅ 2. KÖTELEZŐ KÁRTYA LEZÁRÁSI RITUÁLÉ (TASK COMPLETION WORKFLOW)
|
||||
Mielőtt egy feladatot (Gitea issue/kártya) "Kész"-nek nyilvánítasz a felhasználó felé, KÖTELEZŐ végrehajtanod ezt a két lépést:
|
||||
|
||||
## 4. Architect vs. Code elkülönítés
|
||||
- **Architect (Reasoner R1):** Tervez, auditál, adatbázist elemez, Mermaid diagramokat rajzol, és `/plans/plan.md` fájlokat hoz létre.
|
||||
- **Code (Fast Coder/Chat):** Szigorúan a `/plans` mappából dolgozik, kódot ír, tesztel és commitol.
|
||||
1. **Dokumentáció frissítése:** Írj egy rövid, műszaki összefoglalót a megvalósított logikáról a `.roo/history.md` fájl végére.
|
||||
|
||||
2. **Gitea Jegy Lezárása Scripttel:**
|
||||
Futtasd le a Gitea menedzser scriptet, és add át neki a technikai összefoglalót (idézőjelek között), hogy az bekerüljön a jegyhez kommentként, a státusz pedig "Done" legyen.
|
||||
*Parancs formátuma:*
|
||||
`python3 /opt/docker/dev/service_finder/.roo/scripts/gitea_manager.py finish <KÁRTYA_SZÁMA> "<Rövid technikai összefoglaló arról, mit csináltál>"`
|
||||
|
||||
## 🤖 3. SZEREPKÖRÖK EGYÜTTMŰKÖDÉSE (ROLE INTEGRATION)
|
||||
- **Orchestrator:** Te bontod le a Gitea kártyákat kisebb feladatokra. Használd a `gitea_manager.py create` parancsot.
|
||||
- **Architect / Wiki Specialist:** Te tervezed meg a DDD (Domain-Driven Design) sémákat. A terveket a `history.md`-be vagy a megfelelő wiki/specifikációs fájlba írd.
|
||||
- **Fast Coder:** Te írod a kódot a `logic_spec_*.md` alapján. Mielőtt bezárod a kártyát, ellenőrizd, hogy a szintaxis hibátlan-e.
|
||||
- **Auditor / Debugger:** Te ellenőrzöd a Coder munkáját. Ha hibát találsz, javítod. A tesztjeid SOHA nem írhatják felül a fejlesztői adatbázist (Lásd 1-es pont).
|
||||
@@ -1,7 +1,22 @@
|
||||
"Read Before Write" (Olvasd el, mielőtt írsz): Mielőtt bármilyen meglévő kódot módosítanál, KÖTELEZŐ bekérned vagy beolvasnod a releváns fájlokat. Sose dolgozz feltételezések alapján!
|
||||
# 🧠 CORE BEHAVIOR & ANTI-HALLUCINATION PROTOCOL
|
||||
|
||||
Clean Code & No Harm: Ne okozz kárt a meglévő, jól működő kódbázisban. Csak a célzott problémára fókuszálj.
|
||||
Ez a te legmélyebb viselkedési szabályzatod. Semmilyen más instrukció nem bírálhatja felül ezeket az alapelveket. Célunk a 100%-os pontosság, a 0% találgatás és a kód maximális biztonsága.
|
||||
|
||||
Gondolatmenet (Thought Process): Mielőtt legenerálod a kódot, 2-3 mondatban vázold fel a logikádat, hogy lássam, jó irányba indultál-e el.
|
||||
## 🚫 1. ZÉRÓ HALLUCINÁCIÓ ÉS TALÁLGATÁS
|
||||
- **Soha ne mondd, hogy valami "Kész" vagy "Sikeres", amíg nem láttad a terminál kimenetén!** - Ha egy tesztet vagy kódot futtatsz, KÖTELEZŐ megvárnod és elemezned a terminál válaszát. Ha hibát dob (pl. Stack Trace, Exception), azonnal állj meg, és jelezd a felhasználónak.
|
||||
- **Soha ne találd ki egy fájl elérési útját!** Ha nem vagy 100%-ig biztos benne, hol van egy fájl, használd a `find . -name "fájlneve.py"` parancsot a kereséshez, mielőtt megpróbálod szerkeszteni.
|
||||
|
||||
## ❓ 2. A "3x KÉRDEZZ, 1x JAVASOLJ" SZABÁLY
|
||||
- Ha egy feladat leírása hiányos, vagy egy hibaüzenetből nem egyértelmű a probléma gyökere, **TILOS vakon kódot módosítanod!**
|
||||
- Először tedd fel a szükséges tisztázó kérdéseket a felhasználónak (pl. "Újraindítottad a konténert?", "Létezik ez a teszt user az adatbázisban?").
|
||||
- Csak akkor írj vagy módosíts kódot, ha már pontosan érted a kontextust. A stabil, átgondolt logika sokkal fontosabb, mint a gyors, de hibás kódolás.
|
||||
|
||||
## 🕵️ 3. "TRUST, BUT VERIFY" (Adatbázis és Állapot ellenőrzés)
|
||||
- Mielőtt adatbázis műveletet (CRUD) írsz, KÖTELEZŐ ellenőrizned a meglévő adatbázis sémát (használd az SQL `information_schema` lekérdezését, vagy nézd meg a modelleket a kódban).
|
||||
- Ha arra kérnek, hogy elemezz egy hibát, mindig kérd le a releváns Docker logokat (pl. `sudo docker logs --tail 50 <konténer>`), ne csak az elméletedet oszd meg.
|
||||
|
||||
## 🛑 4. KÁRTEVÉS MEGELŐZÉSE
|
||||
- Meglévő, működő kódot csak akkor módosíthatsz, ha az kifejezetten a feladat része. A módosításokat (Surgical Coding) a lehető legkisebb beavatkozással végezd el.
|
||||
- Mielőtt egy nagy fájlt felülírsz, mindig készíts róla mentést, vagy olvasd el alaposan, hogy megértsd az eredeti logikát, nehogy véletlenül kitörölj egy fontos függőséget.
|
||||
|
||||
Nyelv: Magyar nyelven kommunikálj velem.
|
||||
@@ -1,3 +1,7 @@
|
||||
# 🏛️ PROJECT ARCHITECTURE & ENVIRONMENT MAP
|
||||
|
||||
Ez a fájl tartalmazza a projekt fizikai felépítését és a futtatási környezet szigorú szabályait. Keresés (`find`) előtt MINDIG ezt a térképet használd iránymutatásként!
|
||||
|
||||
Tech Stack: FastAPI (v2, aszinkron), SQLAlchemy (Async), PostgreSQL (Izolált hálózaton), Docker Compose V2.
|
||||
|
||||
AI & OCR: Hibrid AI Gateway (Helyi Ollama: 14B Qwen szövegre, Llama Vision képekre. Fallback: Gemini/Groq).
|
||||
@@ -6,7 +10,30 @@ Identity & Auth: "Dual Entity" modell (Person = hús-vér ember, User = technika
|
||||
|
||||
Deduplikáció (MDM): Csak akkor van merge, ha a make, a technical_code és a hengerűrtartalom egyezik. N/A és UNKNOWN fallback kódok generálása az SQL kényszerek miatt.
|
||||
|
||||
## 5. SQL és Adatbázis Hibakezelés (Error Handling)
|
||||
## 🐳 1. KÖRNYEZET ÉS DOCKER SZABÁLYOK (ENVIRONMENT)
|
||||
- **Operációs rendszer:** Ubuntu/Linux környezetben dolgozunk.
|
||||
- **Docker Compose (KRITIKUS):** A rendszer az új Docker Compose V2-t használja.
|
||||
- **TILOS** a kötőjeles `docker-compose` parancs használata!
|
||||
- **KÖTELEZŐ** a szóközös `docker compose` használata (pl. `sudo docker compose restart sf_api`).
|
||||
- **Jogosultságok:** Ha egy Docker parancs `permission denied` hibát dob, próbáld meg automatikusan `sudo`-val az elején (pl. `sudo docker exec ...`), de először kérdezz rá, ha bizonytalan vagy.
|
||||
- **Backend keretrendszer:** FastAPI (Python), aszinkron (async/await) megközelítéssel, SQLAlchemy 2.0+ (asyncpg) adatbázis kapcsolattal.
|
||||
|
||||
## 🗺️ 2. PROJEKT TÉRKÉP (DIRECTORY STRUCTURE)
|
||||
A projekt mappa-szerkezete az alábbi logikát követi. Keresd a fájlokat ezekben a mappákban a funkciójuk szerint:
|
||||
|
||||
- **`/backend/app/models/`**: Itt találhatók az adatbázis modellek (SQLAlchemy). Ne feledd a sémákat (identity, finance, data, audit, system)!
|
||||
- **`/backend/app/api/endpoints/`** (vagy `api/v1/`): Itt vannak a FastAPI végpontok (routerek, endpointok).
|
||||
- **`/backend/app/services/`**: Itt van az üzleti logika és a "motorok" (pl. `billing_engine.py`, `notification_service.py`).
|
||||
- **`/backend/app/core/`**: Rendszerbeállítások, konfigurációk, biztonság (pl. `config.py`).
|
||||
- **`/backend/app/test_in/`**: Belső tesztek, amiket a konténeren belülről, a többi modullal együttműködve futtatunk.
|
||||
- **`/backend/app/test_outside/`**: Külső integrációs tesztek és szkriptek (pl. a `verify_financial_truth.py`). Ezek futtatása gyakran speciális adatbázis-kezelést igényel.
|
||||
- **`/.roo/scripts/`**: Az AI és a fejlesztést támogató szkriptek (pl. a `gitea_manager.py`).
|
||||
|
||||
## 🧩 3. KÓDOLÁSI ALAPELVEK (ARCHITECTURE RULES)
|
||||
- **Szeparáció (DDD):** Az adatbázis modellek szigorúan sémákra vannak bontva. Ne keverd a `finance` és a `vehicle` domainek adatait!
|
||||
- **Aszinkronitás:** Minden I/O és adatbázis művelet aszinkron (`await session.execute(...)`). Ne használj szinkron blokkoló hívásokat a FastAPI végpontokban.
|
||||
|
||||
## 4. SQL és Adatbázis Hibakezelés (Error Handling)
|
||||
- **Unique Constraint hibák:** Ha a PostgreSQL `InvalidColumnReferenceError` vagy `UniqueViolation` hibát dob az `ON CONFLICT` miatt, TILOS találgatni a mezőket!
|
||||
- **A kötelező megoldás:** Használd az `ON CONFLICT ON CONSTRAINT [korlát_neve] DO NOTHING` vagy `DO UPDATE` szintaxist.
|
||||
- A pontos korlát (constraint) nevét mindig a pgAdmin-ból vagy a `\d+ táblanév` lekérdezéssel kell kideríteni módosítás előtt.
|
||||
@@ -1,3 +1,35 @@
|
||||
Feladatkezelés: A projektmenedzsmenthez MCP Focalboard-ot vagy a projekt gyökerében található KANBAN_AUDIT.md fájlt használunk. Minden munkamenet elején ellenőrizd ezeket, hogy tudd, mi a feladat (Todo) és mi van már kész (Done).
|
||||
|
||||
Jelenlegi Fókusz: A következő időszak fő feladata a "Historical Data" (múltbéli költségek, szervizek) bevezetése az occurrence_date mezővel, és a flottavezetőknek szóló AnalyticsService (TCO/km) kidolgozása.
|
||||
Jelenlegi Fókusz: A következő időszak fő feladata a "Historical Data" (múltbéli költségek, szervizek) bevezetése az occurrence_date mezővel, és a flottavezetőknek szóló AnalyticsService (TCO/km) kidolgozása.
|
||||
|
||||
1. Adatbázis Migrációk (Alembic)
|
||||
|
||||
Ha az AI (az Architect vagy a Coder) módosít egy adatbázis modellt a models/ mappában, hogyan vezesse át az adatbázison? Az AI hajlamos csak megírni a Python kódot, és elfelejteni az SQL-t, vagy nyers SQL-lel próbálkozni.
|
||||
|
||||
Mit adj meg: A pontos parancsot a migrációhoz.
|
||||
|
||||
Példa szabály: "Ha módosítasz egy SQLAlchemy modellt, KÖTELEZŐ legenerálnod a migrációs fájlt az Alembic segítségével a konténeren belül: sudo docker exec sf_api alembic revision --autogenerate -m "Leírás", majd futtatnod kell: sudo docker exec sf_api alembic upgrade head. Soha ne módosíts táblaszerkezetet nyers SQL-lel!"
|
||||
|
||||
2. Csomagkezelés (Dependencies)
|
||||
|
||||
Ha a Roo Code-nak szüksége van egy új Python csomagra (pl. egy új Stripe modulra vagy egy adatbázis driverre), hogyan telepítse?
|
||||
|
||||
Mit adj meg: Hol tartod a függőségeket (requirements.txt, Pipfile, vagy pyproject.toml?), és hogyan települjenek.
|
||||
|
||||
Példa szabály: "Ha új Python csomagra van szükséged, TILOS csak úgy a host gépen pip install-t futtatni. Add hozzá a csomagot a backend/requirements.txt (vagy megfelelő) fájlhoz, és jelezd a felhasználónak, hogy újra kell építenie a konténert (docker compose build)."
|
||||
|
||||
3. Környezeti Változók és Titkok (Secrets & .env)
|
||||
|
||||
Az AI-k hajlamosak "lusták" lenni, és teszteléskor vagy fejlesztéskor keménykódolni (hardcode) a jelszavakat, API kulcsokat a fájlokba.
|
||||
|
||||
Mit adj meg: A konfiguráció kezelésének módját.
|
||||
|
||||
Példa szabály: "SOHA ne hardkódolj API kulcsokat (Stripe, Ollama, Groq), jelszavakat vagy adatbázis URL-eket a kódba! MINDIG a backend/app/core/config.py (Pydantic BaseSettings) fájlt használd, az adatokat pedig a .env fájlból olvasd ki. Ha új környezeti változó kell, írd bele a .env.example fájlba is!"
|
||||
|
||||
4. Naplózási Szabvány (Logging)
|
||||
|
||||
Főleg a háttérfolyamatoknál (mint a robotok vagy a 20-as kártya Cron-jobja), a sima print() nem elég egy Docker konténerben, mert nehéz nyomon követni.
|
||||
|
||||
Mit adj meg: Milyen loggert használsz? (Beépített logging, loguru, stb.)
|
||||
|
||||
Példa szabály: "Ne használj sima print() utasításokat a végleges kódban! Használd a projekt beépített loggerét (pl. import logging vagy from app.core.logger import logger). A háttérfolyamatokat részletesen logold (INFO szinten a lépéseket, ERROR szinten a kivételeket Stack Trace-szel)."
|
||||
@@ -1,4 +1,3 @@
|
||||
#/opt/docker/dev/service_finder/.roo/scripts/gitea_manager.py TOKEN = "783f58519ee0ca060491dbc07f3dde1d8e48c5dd"
|
||||
#!/usr/bin/env python3
|
||||
import requests
|
||||
import sys
|
||||
@@ -79,22 +78,26 @@ def create_issue(title, body, categories, milestone_id=None):
|
||||
def start_issue(issue_num):
|
||||
now = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
|
||||
set_issue_state(issue_num, "Status: In Progress")
|
||||
# Gitea Stopper elindítása
|
||||
requests.post(f"{BASE_URL}/repos/{OWNER}/{REPO}/issues/{issue_num}/stopwatch/start", headers=HEADERS)
|
||||
add_comment(issue_num, f"▶️ **Munka megkezdve:** {now}")
|
||||
print(f"Siker: A #{issue_num} időmérése elindult.")
|
||||
|
||||
def finish_issue(issue_num):
|
||||
def finish_issue(issue_num, custom_message=None):
|
||||
now = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
|
||||
set_issue_state(issue_num, "Status: Done")
|
||||
# Gitea Stopper leállítása
|
||||
requests.post(f"{BASE_URL}/repos/{OWNER}/{REPO}/issues/{issue_num}/stopwatch/stop", headers=HEADERS)
|
||||
requests.patch(f"{BASE_URL}/repos/{OWNER}/{REPO}/issues/{issue_num}", headers=HEADERS, json={"state": "closed"})
|
||||
add_comment(issue_num, f"✅ **Munka befejezve:** {now}\n⏱️ *A ráfordított időt a Gitea 'Time Tracking' modulja rögzítette.*")
|
||||
print(f"Siker: A #{issue_num} lezárva, időmérés megállítva.")
|
||||
|
||||
# Itt adjuk hozzá az egyedi AI összefoglalót, ha van
|
||||
if custom_message:
|
||||
comment_body = f"✅ **Munka befejezve:** {now}\n\n**Technikai Összefoglaló:**\n{custom_message}\n\n⏱️ *A ráfordított időt a Gitea rögzítette.*"
|
||||
else:
|
||||
comment_body = f"✅ **Munka befejezve:** {now}\n⏱️ *A ráfordított időt a Gitea rögzítette.*"
|
||||
|
||||
add_comment(issue_num, comment_body)
|
||||
print(f"Siker: A #{issue_num} lezárva, időmérés megállítva. Komment mentve.")
|
||||
|
||||
def get_issue(issue_num):
|
||||
"""Lekéri a Gitea API-ból az issue adatait és kiírja a címét és leírását."""
|
||||
url = f"{BASE_URL}/repos/{OWNER}/{REPO}/issues/{issue_num}"
|
||||
res = requests.get(url, headers=HEADERS)
|
||||
|
||||
@@ -124,11 +127,9 @@ if __name__ == "__main__":
|
||||
if len(sys.argv) < 3:
|
||||
print("Használat: python3 gitea_manager.py [start|finish|create|get] ...")
|
||||
print(" start <issue_num>")
|
||||
print(" finish <issue_num>")
|
||||
print(" finish <issue_num> [\"Custom summary message\"]")
|
||||
print(" get <issue_num>")
|
||||
print(" create \"<title>\" \"<body>\" [milestone_id] [category1 category2 ...]")
|
||||
print(" - milestone_id: opcionális, szám (pl. 5)")
|
||||
print(" - categories: opcionális, címkék (pl. \"Scope: Backend\" \"Type: Feature\")")
|
||||
sys.exit(1)
|
||||
|
||||
action = sys.argv[1].lower()
|
||||
@@ -136,22 +137,20 @@ if __name__ == "__main__":
|
||||
if action == "start":
|
||||
start_issue(sys.argv[2])
|
||||
elif action == "finish":
|
||||
finish_issue(sys.argv[2])
|
||||
# Ha van 3. paraméter (az üzenet), adjuk át
|
||||
custom_msg = sys.argv[3] if len(sys.argv) > 3 else None
|
||||
finish_issue(sys.argv[2], custom_msg)
|
||||
elif action == "create":
|
||||
title = sys.argv[2]
|
||||
body = sys.argv[3]
|
||||
milestone_id = None
|
||||
categories = []
|
||||
# Ha van 4. paraméter, ellenőrizzük, hogy milestone_id lehet-e
|
||||
if len(sys.argv) > 4:
|
||||
arg4 = sys.argv[4]
|
||||
# Ha az arg4 szám (lehet milestone_id), akkor milestone_id-nek vesszük
|
||||
if arg4.isdigit():
|
||||
milestone_id = arg4
|
||||
# A többi paraméter (5. és további) categories
|
||||
categories = sys.argv[5:] if len(sys.argv) > 5 else []
|
||||
else:
|
||||
# Ha nem szám, akkor az arg4 is categories, és a többi is
|
||||
categories = sys.argv[4:]
|
||||
create_issue(title, body, categories, milestone_id)
|
||||
elif action == "get":
|
||||
|
||||
Reference in New Issue
Block a user