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

{"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:

# 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).