roa2web-service-auto/docs/service-auto/week1-notes.md

# Săpt 1 Notes — Oracle POC

**Date**: 2026-04-11

## Conectivitate

- Server: `central` (10.0.20.121:1521/ROA, CONTAFIN_ORACLE) — PORT OPEN, direct (no tunnel needed)
- Sync connect: **33ms** | Queries: 0.6-3.3ms ✅
- Async connect_async: **22ms** | Queries: 0.2-0.3ms ✅

## Gate Correction 9 — Decizie

**Decizie: sync-facade pattern** (consistent cu `oracle_pool.py` existent)

Motivare: `oracle_pool.py` folosește deja `oracledb.create_pool()` (sync) + `pool.acquire()` (sync) + `with cursor` (sync) în `async def`. Serviciile service_auto vor urma același pattern pentru consistență arhitecturală. `connect_async` funcționează dar nu aduce beneficii față de sync-facade la latențele măsurate.

## Schema Access

- `MARIUSM_AUTO.DEV_ORDL` — acces OK
- `MARIUSM_AUTO.DEV_TIP_DEVIZ` — enum confirmat (7 tipuri, inch_validare corect)

## Next Steps (Săpt 3)

- Audit grants `ROA_WEB` pe `MARIUSM_AUTO.*`
- Creare SP `SP_CREEAZA_COMANDA_PROTOTIP` în MARIUSM_AUTO (template în tabele-service-auto.md §12.2)
- Auth path: adaugă `MARIUSM_AUTO` company în `.env` + test login JWT end-to-end

---

# Săpt 3 — Execution Log

## Task #1 — Grants audit (2026-04-11, oracle-agent)

- `ROA_WEB` user **nu există** în instanța `ROA` (toate cele 4 dicționare — DBA_USERS, DBA_TAB_PRIVS, DBA_SYS_PRIVS, DBA_ROLE_PRIVS — întorc 0 rânduri).
- `CONTAFIN_ORACLE` are `DBA` role → acces la MARIUSM_AUTO e via `SELECT/INSERT/UPDATE/DELETE/EXECUTE ANY ...`, fără grants explicite. Asta explică de ce Săpt 1 a funcționat fără DBA work.
- Decizie: **fază A (Săpt 3) folosește CONTAFIN_ORACLE direct** — nu e nevoie de DBA. Fază B (Săpt 4+) va crea ROA_WEB cu grants scope-limited pentru a proba ipoteza #3 (access blocat direct, permis doar via SP).
- Findings complete + script creare ROA_WEB: `docs/service-auto/grants-audit.md`.

## Task #3 — SP_CREEAZA_COMANDA_PROTOTIP (2026-04-11, oracle-agent)

### SP source
- Locație: `docs/service-auto/SP_CREEAZA_COMANDA_PROTOTIP.sql`
- Signature: `(p_tip IN, p_id_masiniclient IN, p_solicitari IN VARCHAR2, p_id_firma IN, p_id_ordl OUT, p_nrord OUT)`
- Nrord generation: `SEQ_NR_LUCRARE.NEXTVAL` (existing, unused — `last_number=1`) + prefix `P<id_firma>-<seq>` → primul prototype produce `P01-1`.
- Body: duplicate-check (paritate cu `pack_auto`) + INSERT NOM_LUCRARI (`id_mod=1200`, id_lucrare auto via `TRG_NOM_LUCRARI_BEFOINS` + `SEQ_NOM_LUCRARI`) + INSERT DEV_ORDL (coloane NOT NULL + client link).
- Coloane sărite conștient: `id_inspector`, `id_asigurator`, `nr_dosar`, `kmint`, `termen`, `proc_tvav`, `id_part_ref`, `observatii`, `defectiuni` — toate nullable, OK pentru prototype.

### Execution
- `CREATE OR REPLACE PROCEDURE` via `cursor.execute(body)` (trailing `/` stripped în Python pentru a nu fi trimis ca SQL statement invalid) → **VALID** fără compile errors.
- Test call:
  ```
  tip=1 (POST GARANTIE), id_masiniclient=2, solicitari="Prototype test — rollback imediat după verificare.", id_firma=1
  → OUT p_id_ordl=411, p_nrord='P01-1'
  → verificare pre-rollback: rând în DEV_ORDL + NOM_LUCRARI cu id_lucrare=721, id_mod=1200, an=2026, luna=4
  → conn.rollback()
  → post-rollback: 0 rows în ambele tabele ✅
  ```
- Confirmă: ipoteza #1 (oracledb → OUT NUMBER + OUT VARCHAR2 prin `cursor.var()`), ipoteza #2 (SP cu RETURNING INTO peste două INSERT-uri cu trigger-uri BEFOINS), tranzacționalitate completă.

### Note
- `SEQ_NR_LUCRARE` **nu se roll-back-uie** (standard Oracle) — următorul test va produce `P01-2`, `P01-3`, etc. Util pentru cleanup: prototype rows sunt ușor de identificat prin prefix `P`.
- `DBMS_LOB.SUBSTR` folosit în verificare pentru a citi CLOB-ul `solicitari_client` — implicit VARCHAR2→CLOB conversion la INSERT a mers fără probleme (inclusiv diacritice).

### Test #2 — Confirmare (2026-04-11, oracle-agent, săpt 3 exec)

```
tip=3 (REGIE, inch_validare=1), id_masiniclient=200 (CT-85-ROD), p_id_firma=1
→ SP call: 5.9ms ✅
→ OUT p_id_ordl=412, p_nrord='P01-2'
→ NOM_LUCRARI: id_lucrare=722, nrord='P01-2', id_mod=1200 ✅
→ DEV_ORDL: id_ordl=412, id_lucrare=722, id_tip=3, luna=4, an=2026 ✅
→ conn.rollback() → post-rollback: 0 rows ✅
```

**Ipoteze confirmate Săpt 3:**
- H1 ✅ — `oracledb.cursor.callproc()` + `cursor.var(NUMBER)` / `cursor.var(STRING)` pentru OUT params
- H2 ✅ — SP cu dual INSERT (NOM_LUCRARI → DEV_ORDL) + trigger BEFOINS RETURNING + tranzacționalitate completă
- H3 ⏳ — amânat Săpt 4 (necesită creare ROA_WEB via DBA; script ready în `grants-audit.md`)

## Task #5 — MARIUSM_AUTO în backend/.env (2026-04-11, oracle-agent)

### Modificări .env

Adăugat entry `mariusm_test` în `ORACLE_SERVERS` JSON în toate cele 3 fișiere env:
- `backend/.env` — activ imediat
- `backend/.env.prod` — pentru viitoarea producție
- `backend/.env.test` — pentru runul de test

```json
{"id":"mariusm_test","name":"MARIUSM AUTO (service-auto prototype)",
 "host":"10.0.20.121","port":1521,
 "user":"CONTAFIN_ORACLE","service_name":"ROA"}
```

**Reasoning** (fază A): `mariusm_test` are aceleași parametri de conectare ca și `central` (același server Oracle, același user DBA), dar ID distinct pentru:
1. Pool separat per modul service_auto (pool sizing independent)
2. Swap atomic la faza B: schimbăm `mariusm_test` → user=ROA_WEB, fără modificări cod

Parola: `backend/secrets/mariusm_test.oracle_pass` (copie din `central.oracle_pass`)

### Verificare conectivitate via config

```
Config parsed: 4 servers (romfast, central, mariusm_test, vending) ✅
mariusm_test: password loaded (len=11) ✅
Direct connect: 22.1ms ✅
DEV_TIP_DEVIZ count=7 ✅
SP_CREEAZA_COMANDA_PROTOTIP STATUS=VALID ✅
```

### Test JWT login — backend offline

Backend nu rulează (verificat via `curl http://localhost:8000/health`). 
Pentru a testa login JWT end-to-end:

```bash
# 1. Pornește backend în mod test
./start.sh test

# 2. Testează login JWT cu credențialele de test (din CLAUDE.md)
curl -s -X POST http://localhost:8000/api/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"MARIUS M","password":"123","company_id":1}' | jq .

# 3. Verifică că token-ul JWT are câmpul companies[] cu MARIUSM_AUTO
# 4. Fă un request autentificat la viitorul endpoint service_auto:
# GET /api/service-auto/comenzi sau POST /api/service-auto/comanda

# 5. Oprește backend
./start.sh test stop
```

**Blocat de**: backend offline + task #4 stubs în progres (router/service TODO NotImplementedError)
**Next step Săpt 3+**: după ce backend-agent completează Task #4 (router live), rulează secvența de mai sus.

### Verificare Oracle-side a path-ului de login (oracle-agent, 2026-04-11)

Independent de backend, am mirror-at exact cele 3 interogări din
`backend/modules/telegram/routers/auth_codes.py:292-349` direct pe Oracle
`central` pentru a de-risca testul JWT pending:

```
Step 1 — pack_drepturi.verificautilizator('MARIUS M', '123')
  → return: 803  (≠ -1 → autentificare validă, session id)

Step 2 — SELECT id_util, utilizator FROM UTILIZATORI WHERE UPPER(utilizator)='MARIUS M'
  → id_util=8, utilizator='MARIUS M'

Step 3 — SELECT ID_FIRMA,FIRMA,SCHEMA FROM V_NOM_FIRME
         WHERE ID_FIRMA IN (SELECT ID_FIRMA FROM VDEF_UTIL_FIRME WHERE ID_UTIL=8 AND ID_PROGRAM=2)
  → 6 rows:
      238  AXN                            schema=ACN
      237  DANUBE GRAIN SERVICES           schema=DANUBE
      251  EMS                             schema=EMS
      110  MARIUSM AUTO                    schema=MARIUSM_AUTO  ← TARGET
      167  MARIUSM AUTO SUC 1 ...          schema=MARIUSM_AUTO
      169  MARIUSM AUTO SUC 2              schema=MARIUSM_AUTO
```

**3 rânduri** în V_NOM_FIRME au `schema='MARIUSM_AUTO'` pentru MARIUS M, toate
cu `cod_fiscal='RO1879855'` (același CUI, rapoarte separate):

| id_firma | firma | rel |
|---|---|---|
| 110 | MARIUSM AUTO | parent (mama, `id_mama=null`) |
| 167 | MARIUSM AUTO SUC 1 ... | sucursală (`id_mama=110`) |
| 169 | MARIUSM AUTO SUC 2 | sucursală (`id_mama=110`) |

**Concluzie**: path-ul Oracle pentru login este 100% funcțional înainte de
pornirea backend-ului. Prototype-ul poate folosi default `id_firma=110` în
frontend. Testul JWT HTTP (listat mai sus) e singurul pas care necesită backend
pornit; toate dependențele Oracle sunt verificate.

**Decizie separată — pool `mariusm_test` vs. `central`**: cel care a adăugat
entry-ul `mariusm_test` în ORACLE_SERVERS a ales izolare pool per-modul + swap
atomic la ROA_WEB în fază B. E compatibil cu path-ul de login: service_auto
folosește `mariusm_test` pool pentru queries/SP către schema `MARIUSM_AUTO`, în
timp ce login-ul rămâne pe `central` (sau pe `mariusm_test`, echivalent — same
credențiale în fază A).