# Nadogradnja na v3.22.0 — F/DS poslovne uloge

## Status

Production-ready data migration i aplikacioni patch za postojeću v3.21.3 instalaciju. Migracija ne menja šemu baze, ali mora biti izvršena pre nego što se DS role koriste u aplikaciji.

## Model

Sistem ostaje jedna aplikacija i jedna baza. Organizacijska pripadnost je deo postojećeg `role_code` obrasca:

- Fondacija: `USERF`, `OFCF`, `VHCF`, `ICTF`, `OTHF`
- Dečije selo: `USERDS`, `OFCDS`, `VHCDS`, `ICTDS`, `OTHDS`

`tickets.responsible_role_code` je autoritativni organizacijsko-funkcionalni routing ključ. `ticket_categories.responsible_role_code` ostaje kanonsko funkcionalno mapiranje sa F kodom; backend ga pri kreiranju/promeni tiketa mapira na F ili DS varijantu.

## Redosled deployment-a

1. Napraviti backup aplikacionih fajlova i kompletan DB backup.
2. U maintenance prozoru pokrenuti `upgrade_v3_22_0.sql`.
3. Verifikovati da postoji svih 10 role kodova i da su aktivni.
4. Deploy-ovati fajlove iz v3.22.0 patch paketa.
5. U administratorskom interfejsu dodeliti `USERDS` i odgovarajuće DS processing role samo korisnicima Dečijeg sela.
6. Uraditi smoke test kreiranja F i DS tiketa, queue pristupa, dodele i evidencije.

Preporučeni verifikacioni SQL nakon migracije:

```sql
SELECT role_code, name, is_active, sort_order
FROM roles
WHERE role_code IN ('USERF','USERDS','OFCF','OFCDS','VHCF','VHCDS','ICTF','ICTDS','OTHF','OTHDS')
ORDER BY sort_order, role_code;
```

Očekivanje: 10 redova; postojeći F kodovi ostaju nepromenjeni, a DS kodovi postoje i aktivni su.

## Integritet i bezbednost

- Ne menjaju se postojeći korisnici ni njihove `user_roles` veze.
- Ne menjaju se postojeći tiketi ni njihovi `responsible_role_code` podaci.
- Ne menjaju se postojeći role ID-jevi.
- `ICTF` i `ICTDS` nisu ekvivalentni u access SQL-u; pristup processing queue-u i upravljanje tiketom koriste tačan role kod.
- `eligible_assignees()` i `notify_responsible_role()` takođe koriste tačan role kod.
- Administrator ne može korisniku istovremeno snimiti `USERF` i `USERDS`, jer bi organizaciona pripadnost novih tiketa bila dvosmislena.

## Rollback

Najbezbedniji rollback je restore DB backup-a i prethodnog v3.21.3 aplikacionog paketa.

Ako DS role još nisu dodeljene nijednom korisniku i nijedan tiket nema DS `responsible_role_code`, DS role se mogu ukloniti nakon provere referenci, a zatim vratiti prethodni aplikacioni paket. Ne brisati DS role ako postoje reference iz `user_roles`, `tickets` ili drugih FK tabela.

Ako je sistem već počeo da koristi DS role/tikete, ne raditi parcijalni rollback samo aplikacionih fajlova. Pre povratka na v3.21.3 prvo je potrebno kontrolisano migrirati DS reference ili vratiti kompletan pre-v3.22.0 DB backup.

## Maintenance napomena

Naming convention za nove organizacione jedinice ostaje `<FUNCTION><UNIT>`. Ako broj organizacionih jedinica značajno poraste, tada ima smisla razmotriti normalizaciju u posebno `organization_unit` polje/tabelu. Za trenutne dve jedinice to bi bio nepotreban širok refaktor i drugi izvor istine.
