ADMIN — SİSTEM YÖNETİMİ

Tüm ERP’nin kontrol merkezi. Kullanıcı kimlikleri, yetkiler, kimlik doğrulama, yazıcı donanımı, yazdırma kuyruğu izleme, AI asistan yapılandırması ve aktivite denetimi — sistemi güvenli, yapılandırılmış ve gözlemlenebilir tutan her şey.

Şubat 2026 • Solen Kablo • Yaşayan Doküman

1. ADMIN NE YAPAR

Admin modülü, tüm ERP sisteminin bağlı olduğu altı soruyu yanıtlar:

1.1 Üç Kullanıcı Tipi

Sistem, her biri farklı erişim kapsamına ve farklı fiziksel kullanım bağlamına sahip üç temel kullanıcı tipi tanır:

1.2 Hibrit Yetki Modeli

Yetki sistemi aynı anda iki katmanda çalışır:

Her iki katman, check_permission_smart adında geriye uyumlu bir fonksiyon aracılığıyla bir arada bulunur. Önce eski rol tabanlı sistemi kontrol eder, sonra granüler JSON sistemine düşer. Super admin’ler her ikisini de atlar — her zaman geçerler.

1.3 Kullanıcı Yönetiminin Ötesinde

Admin sadece kullanıcılarla ilgili değildir. Fiziksel donanımı (fabrika zeminindeki ağ yazıcıları) yöneten, gerçek zamanlı operasyonel izleme (yazdırma kuyruğu panosu) sağlayan ve diğer kullanıcıların etkileşimde bulunduğu AI asistanı kontrol eden tek modüldür. Ayrıca user_activity_logs tablosuna yazan tek modüldür ve sistemde alınan her yönetimsel eylemin denetim izini oluşturur.

2. VERİ AKIŞI

Admin’in veri akışları, Hammadde veya Teknik gibi üretim modüllerinden temelden farklıdır. Bu modüllerin doğrusal bir hattı vardır (tedarikçi → sipariş → giriş → envanter). Admin ise bir göbek-ve-kol (hub-and-spoke) desenine sahiptir: merkezde oturur ve diğer her modül ona bağlıdır.

2.1 Kimlik Doğrulama Akışı

Bundan sonraki tüm sistemdeki her API çağrısı, Authorization: Bearer başlığında JWT erişim token’ını taşır. Token, kullanıcının ID’sini, kullanıcı adını, user_type’ını ve yetkilerini içerir — bu da her modüldeki her route’un ek bir veritabanı sorgusu olmadan kimliği doğrulayabileceği ve yetkileri kontrol edebileceği anlamına gelir.

2.2 Yetki Uygulama Akışı

Önyüzde aynı kontrol proaktif olarak çalışır: route’lar menüden gizlenir, butonlar devre dışı bırakılır veya görünmez yapılır ve doğrudan URL erişimi denenirse tüm sayfalar kullanıcının izin verilen panosuna yönlendirilir.

2.3 Yazdırma İşi Akışı

Yazdırma işleri diğer modüller tarafından oluşturulur (Hammadde Girişi teslimat kaydettikten sonra QR etiketleri yazdırır, Hammaddeler Listesi talep üzerine etiket yeniden yazdırır) ancak kuyruğun kendisi Admin’de yaşar. Yazdırma İzleme, super admin’lere dört fabrika yazıcısındaki tüm işlerin gerçek zamanlı görünümünü, başarısız işleri yeniden deneme ve kuyruktakileri iptal etme yeteneğiyle sağlar.

2.4 AI Etkileşim Akışı

Her AI etkileşimi kapsamlı olarak günlüğe kaydedilir: kullanıcının sorgusu, algılanan dil, kullanılan AI modeli, akıl yürütme adımları, araç çağrıları, API yanıtları, zamanlama metrikleri ve güvenlik bayrakları. Bu, AI’nın ne yaptığının ve nedeninin tam bir adli izini oluşturur.

2.5 Göbek-ve-Kol Bağımlılığı

3. VERİTABANI KATMANI

Admin modülü 10 veritabanı tablosuna sahiptir, bu diğer tüm modüllerden fazladır. Bu tablolar dört gruba ayrılır: kimlik, oturumlar, donanım ve denetim.

3.1 Kimlik Tabloları

3.2 Oturum Tablosu

Oturumlar sadece token doğrulama için değildir. Tam bir giriş geçmişi sağlarlar: hangi cihaz kullanıldı, hangi IP’den, ne zaman giriş yapıldı, ne zaman çıkış yapıldı (veya oturum süresi doldu mu). users ilişkisindeki cascade delete, bir kullanıcıyı silmenin tüm oturumlarını otomatik olarak temizlemesi anlamına gelir.

3.3 Donanım Tabloları

3.4 Denetim Tabloları

3.5 Varlık-İlişki Özeti

4. BACKEND MİMARİSİ

Admin backend’i beş route grubu, bir temel servis, bir güvenlik modülü ve bir yetki yardımcı katmanı olarak organize edilmiştir. Tek bir route dosyasına sahip üretim modüllerinin aksine, Admin birden fazla dosyaya yayılır çünkü sorumlulukları birbirinden temelden farklıdır.

4.1 Route Grupları

4.2 Kimlik Doğrulama Endpoint’leri (5)

4.3 Kullanıcı Yönetimi Endpoint’leri (9)

4.4 Yazıcı & Yazdırma Kuyruğu Endpoint’leri (10)

4.5 AI Endpoint’leri (12)

4.6 Temel Servisler

AuthenticationService

Merkezi kimlik doğrulama motoru. Beş operasyon yürütür:

• authenticate_user — Kullanıcıyı kullanıcı adı veya e-posta ile bulur, şifreyi bcrypt ile doğrular, last_login zaman damgasını günceller.
• create_user_session — JWT erişim ve yenileme token’ları üretir. Kritik detay: operatör hesapları 6 aylık token süresi alır (yeniden giriş gerektirmemesi gereken kiosk telefonlar için), diğer tüm hesaplar standart 12 saatlik süre alır.
• get_user_by_token — JWT’yi çözer, süre dolumunu doğrular, kullanıcının hala var olup olmadığını ve aktif olup olmadığını kontrol eder.
• logout_user — Oturum kaydını sonlandırır, çıkış zamanını damgalar.
• refresh_token — Yenileme token’ını doğrular, yeni bir oturum oluşturmadan yeni erişim token’ı verir.

SecurityManager

Düşük seviye kriptografik operasyonlar: bcrypt şifre hashleme ve doğrulama, yapılandırılabilir süreli JWT oluşturma, imza doğrulamalı JWT çözme ve token süre dolumu doğrulama. Yapılandırılabilir gizli anahtar ile HS256 algoritması kullanır.

Yetki Yardımcıları

Sistemdeki her modül tarafından kullanılan yetki kontrol omurgasını oluşturan dört fonksiyon:

• is_permitted_user(user, required_types) — Eski rol kontrolü. Super admin her zaman geçer.
• check_user_permission(user, page_id, button_id) — Granüler JSON yetki kontrolü. Kullanıcının permissions alanını ayrıştırır, pages[page_id].buttons[button_id]’ye gider.
• has_special_permission(user, permission) — hard_delete veya manage_users gibi özel bayrakları kontrol eder.
• check_permission_smart(user, required_types, page_id, button_id) — Birleşik giriş noktası. Önce rol tabanlıyı dener, sonra granülere düşer. Çoğu route’un gerçekte çağırdığı budur.

4.7 FastAPI Bağımlılıkları

Admin, sistemdeki her modülün içe aktardığı dört enjekte edilebilir bağımlılık tanımlar:

5. ÖNYÜZ

Admin önyüzü, beş ayrı sayfa ile tüm uygulamadaki her sayfayı etkileyen kesmesel bir yetki katmanından oluşur.

5.1 Sayfa Envanteri

Dört admin sayfasının tümü /admin route öneki altında oturur ve görünürlüğü super admin kullanıcılarla sınırlayan canAdmin erişim korumasını paylaşır. Giriş sayfası, tüm uygulamadaki tek herkese açık sayfadır.

5.2 Yetki Katmanı (Kesmesel)

Admin’in önyüze en etkili katkısı kendi sayfaları değildir — diğer her sayfanın kullandığı yetki altyapısıdır. Bu üç dosyada yaşar:

5.3 Giriş Sayfası

Giriş sayfası üç senaryoyu yönetir:

1. Standart giriş: “Beni hatırla” onay kutusuyla kullanıcı adı/şifre formu. JWT token’larını ve kullanıcı verilerini localStorage’da saklar (solen_auth_token, solen_refresh_token, solen_current_user).
2. Kiosk otomatik giriş: Fully Kiosk Browser’ı user agent string’i üzerinden algılar. Algılandığında, otomatik olarak operatör hesabıyla giriş yapar ve /production’a yönlendirir. İnsan etkileşimi gerekmez.
3. Gizli URL token’ı: Herhangi bir tarayıcıdan otomatik girişi tetiklemek için URL parametresi olarak ?kiosk=SOLEN_FACTORY_2024_KIOSK_SECRET kabul eder. Bu, yeni kiosk cihazlarının montajı için fabrika zemine özel bir kolaylıktır.

5.4 Kullanıcı Yönetimi Sayfası

Admin modülündeki en karmaşık sayfa. Üç sekmeli modal ile kullanıcı hesapları için tam bir CRUD arayüzü sağlar:

• Sekme 1 — Temel Bilgiler: Kullanıcı adı, e-posta, tam ad, kullanıcı tipi (super_admin, lab_user, operator, teknik_user, bakim_user ve özel tiplerle dropdown), durum, şifre (yeni kullanıcılar için), şifre değiştirmeyi zorla toggle’ı.
• Sekme 2 — Yetkiler: Granüler yetki editörü. Tam yetki manifestini bir ağaç olarak çizer: her sayfa bir switch (erişim açık/kapalı) ve her sayfa altında bireysel butonlar onay kutularıdır. Dört hızlı doldurma şablonu içerir: Tam, Boş, Operatör Varsayılan, Lab Kullanıcı Varsayılan.
• Sekme 3 — Önizleme: Kaydettikten sonra kullanıcının neye erişebileceğinin salt okunur özetini gösterir — hangi modüller, hangi sayfalar, hangi butonlar.

Modalın ötesinde sayfa şunları sağlar: kullanıcı adı/e-posta/tam ad üzerinden arama, user_type ve duruma göre filtreleme, şifre sıfırlama (yeni şifreyi üretir ve görüntüler), askıya al/etkinleştir toggle’ı, onaylamalı silme ve Turkey/Istanbul saat dilimi dönüştürmesiyle son giriş görüntüleme.

5.5 Yazıcı Yönetimi Sayfası

Fabrika etiket yazıcıları için CRUD arayüzü. Her yazıcının: ad, açıklama, IP adresi, port, konum, durum ve atanmış malzemeleri (malzeme tiplerinden çoklu seçim: raw_copper, raw_tin, raw_plastic, vb.) vardır. Yazıcının ağda erişilebilir olduğunu doğrulamak için backend’in /printers/{id}/test endpoint’ine ulaşan bir “Bağlantı Testi” butonu içerir.

5.6 Yazdırma İzleme Sayfası

Gerçek zamanlı izleme panosu. Üst bölüm dört istatistik kartı gösterir: Bekleyen (mavi), Yazdırılan (turuncu), Tamamlanan (yeşil), Başarısız (kırmızı). Altında sütunlarla tüm yazdırma işlerini gösteren bir ProTable vardır: QR kod, malzeme tipi, lot numarası, tedarikçi, yazıcı, durum, talep eden, talep tarihi, tamamlanma tarihi, hata mesajı. Yeniden deneme (başarısız işleri yeniden kuyruğa ekler) ve iptal (kuyruktaki işleri kaldırır) destekler. Tüm zaman damgaları Turkey/Istanbul saat dilimindedir.

5.7 AI Ayarları Sayfası

Dört sekmeli yapılandırma arayüzü:

• Genel Bakış: AI durumu (aktif/inaktif), bugünkü sorgu sayısı, toplam sorgular, ortalama yanıt süresi, başarı oranı görselleştirmesi ve bağlantı testi butonu.
• API Anahtarları: Üç sağlayıcı için (Gemini, OpenAI, Anthropic) API anahtarlarını kaydet, test et ve sil. Anahtarlar arayüzde maskelenir ve sunucunun .env dosyasında saklanır.
• Model Ayarları: AI’yı etkinleştir/devre dışı bırak, model seç (sağlayıcıya göre gruplandırılmış cascader: Gemini 3 Flash/Pro, GPT-5.2/Mini, Claude Sonnet/Opus/Haiku), maks token (1024–8192) ve sıcaklık (0.1–0.9) yapılandır.
• Denetim Günlüğü: AI etkileşimlerinin tam geçmişi. Orijinal sorguyu ve AI yanıtını gösteren genişletilebilir satırlı ProTable. Kullanıcı, araç, durum, IP adresine göre filtrelenebilir. Yanıt süresi metrikleri içerir.

5.8 Ortak Önyüz Desenleri

5.9 API Katmanı

Önyüz, dağıtım bağlamına göre backend URL’sini dinamik olarak çözen merkezi bir API yardımcısı (src/utils/api.ts) aracılığıyla backend ile iletişim kurar:

• HTTPS modu: /api proxy kullanır (reverse proxy yönlendirmeyi yönetir).
• HTTP localhost: http://localhost:8000/api (geliştirme).
• HTTP yerel ağ: http://{hostname}:8000/api (fabrika LAN erişimi).
• Özel geçersizleme: Özel dağıtımlar için window.BACKEND_URL.

Her API çağrısı, localStorage’dan alınan Authorization: Bearer {token} başlığını içerir. Kimlik doğrulama servisi (src/services/realAuth.ts), tüm sayfaların içe aktardığı login(), logout(), getCurrentUser() ve getToken() fonksiyonlarını sağlar.

6. ALT MODÜLLER

Admin modülü dört alt modül olarak organize edilmiştir, operasyonel akışa göre: yazdırma işleri izlenebilmeden önce yazıcılar yapılandırılmalı, AI ayarları bağımsız durur ve kullanıcı yönetimi her şeye erişimi yönetir.

6.1 Yazıcı Yönetimi (Printer Management)

6.1.1 Amaç ve İş Bağlamı

Fabrikaya giren her hammadde, QR kodu, ağırlık, tedarikçi, lot numarası ve giriş tarihi içeren basılı bir A6 etiket alır. Bu etiketler malzemenin fiziksel kimliğidir — aşağı akıştaki her istasyonda (lab testi, üretim, stok) taranır. Etiket yazıcıları, belirli konumlara yerleştirilmiş endüstriyel ağ cihazlarıdır (TCP port 9100 / IPP port 631): laboratuvar ve üç üretim hattı. Yazıcı Yönetimi, bu fiziksel cihazların yapılandırıldığı, test edildiği ve malzeme türlerine atandığı kayıt defteridir.

Bu alt modül olmadan sistem yazdırma işlerini nereye göndereceğini bilemez. Dört soruyu yanıtlar: Hangi yazıcılar var? Neredeler? Çevrimiçiler mi? Her yazıcı hangi malzeme türlerini idare edebilir?

6.1.2 Veritabanı Şeması

Tek tablo: printers (model dosyası: 66 satır)

PrinterStatus Enum

class PrinterStatus(str, Enum):
    ONLINE      = "online"
    OFFLINE     = "offline"
    ERROR       = "error"
    MAINTENANCE = "maintenance"

Varsayılan Yazıcılar (Migration Tohum Verisi)

6.1.3 API Sözleşmesi — 5 Endpoint

6.1.4 CRUD Akışı

Oluştur:

1. Araç çubuğunda “Yeni Yazıcı Ekle” butonuna tıkla
2. Modal (600px) 7 alanla açılır: ad (zorunlu), açıklama, konum, IP adresi (zorunlu), port (varsayılan 9100), atanmış malzemeler (çoklu seçim: A=Bakır, B=Kalay, C=Plastik, D=Katalizör, E=Boya, F=Antirodent), durum
3. Gönderimde: POST /api/printers/create
4. Backend is_active=true, status=online ile kayıt oluşturur, assigned_materials dizisini JSON string’e dönüştürür
5. Başarıda: toast “Yazıcı ‘{ad}’ eklendi” → modal kapanır → tablo yenilenir
6. Not: Yeni yazıcının arka plan yazdırma işçisinin başlaması için uygulama yeniden başlatılmalıdır

Oku:

1. Sayfa yüklenir → GET /api/printers/list
2. ProTable (11 sütun) render eder: ID, ad, açıklama, IP (mavi etiket), port, konum, durum (renk kodlu etiket), atanmış malzemeler (harf etiketleri), aktif (onay/çarpı ikon), işlemler
3. İstemci tarafı arama, ad, açıklama, IP, konum, durum, port ve ID üzerinde aynı anda filtreler

Güncelle:

1. İşlemler sütunundaki düzenle ikonuna tıkla
2. Aynı modal mevcut değerlerle dolu olarak açılır
3. Alanları değiştir → “Güncelle”ye tıkla
4. PUT /api/printers/update/{id} → backend yalnızca gönderilen alanları günceller, updated_at damgalar
5. Başarıda: toast “Yazıcı ‘{ad}’ güncellendi” → modal kapanır → tablo yenilenir

Sil:

1. İşlemler sütunundaki sil ikonuna (tehlike butonu) tıkla
2. Onay modalı: “{ad} yazıcısını silmek istediğinize emin misiniz?”
3. Onayda: DELETE /api/printers/{id}
4. Backend bekleyen yazdırma işlerini (QUEUED veya PRINTING durumu) kontrol eder
5. Bekleyen işler varsa: silme engellenir, hata “Bu yazıcının {n} bekleyen işi var. Önce işleri tamamlayın veya iptal edin.”
6. Bekleyen iş yoksa: yazıcı silinir → toast → tablo yenilenir

Bağlantı Testi:

1. İşlemler sütunundaki test ikonuna (ApiOutlined) tıkla
2. POST /api/printers/{id}/test
3. Backend PrintService.test_printer_connection() çağırır, alt süreç üzerinden lpstat -p {yazıcı_adı} çalıştırır
4. Olası sonuçlar: “connected” (boşta), “busy”, “not_found”, “timeout”, “error”
5. Backend printer.status’ü (ONLINE veya OFFLINE) ve last_checked’ı günceller
6. Başarıda: yazıcı adıyla toast → tablo yenilenir (durum sütunu yeni durumu yansıtır)
7. Başarısızlıkta: uyarı mesajı → tablo yenilenir (durum “Çevrimdışı” kırmızı görünür)

6.1.5 Yazdırma Servisi — Etiket Üretim Motoru

Dosya: app/services/print_service.py (576 satır). A6 etiketleri üreten ve yazdıran çekirdek servis.

Etiket Özellikleri

Etiket İçerik Düzeni

1. Ortalanmış QR kod (300px) ve altında QR metni
2. Lot numarası (varsa)
3. Ağırlık (kg)
4. Malzeme türü / ürün adı
5. Tarih ve saat (Türkiye saat dilimi)
6. “Oluşturan” kullanıcı adı
7. Notlar (varsa)

Temel Servis Metotları

Font Geri Dönüş Zinciri

Servis fontları platform sırasıyla dener: macOS (/System/Library/Fonts/) → Linux (/usr/share/fonts/) → Windows (C:/Windows/Fonts/) → PIL varsayılan. Bu, etiket üretiminin tüm geliştirme ve üretim ortamlarında çalışmasını sağlar.

6.1.6 Yazdırma İşçisi — Arka Plan İş İşleme

Dosya: app/services/print_worker.py (292 satır). Her aktif yazıcı kendine ait bir arka plan işçi thread’i alır.

Mimari

İşçi Yaşam Döngüsü

1. Başlatma: IP’den CUPS yazıcı adı üretir (örn. Printer_192_168_0_182), yazıcıyı lpadmin ile CUPS’a kaydeder, lpoptions ile A6’yı varsayılan medya olarak ayarlar
2. Yoklama döngüsü: Her 1 saniyede bu yazıcı için sıradaki QUEUED işi sorgular (requested_at’a göre sıralı — FIFO)
3. İş işleme: Durumu PRINTING yapar → started_at damgalar → malzeme + kullanıcı verisini çeker → print_label_with_quantity() çağırır
4. Başarıda: Durum → COMPLETED, completed_at damgalanır
5. Başarısızlıkta: retry_count < 3 ise: artır, QUEUED’a geri al. retry_count ≥ 3 ise: durum → FAILED

CUPS Otomatik Kayıt

Bir işçi başladığında, yazıcı CUPS’a kayıtlı değilse işçi otomatik olarak ekler:

# Yazıcıyı CUPS’a otomatik kaydet
lpadmin -p Printer_192_168_0_182 -E -v ipp://192.168.0.182:631/ipp/print -m everywhere
lpoptions -p Printer_192_168_0_182 -o media=A6

6.1.7 Malzeme Atama Sistemi

Her yazıcıya assigned_materials JSON dizisi aracılığıyla belirli malzeme türleri atanabilir. Altı malzeme türü kodu, fabrikanın QR kod harf sistemine karşılık gelir:

Lab yazıcısı (ID 1) tüm malzeme girişlerini idare ettiği için altı türe de atanmıştır. Üretim yazıcılarının boş atamaları vardır — üretim aşaması etiketleme için kullanılırlar.

6.1.8 Frontend Mimarisi

Tek dosya: src/pages/Admin/PrinterManagement/index.tsx (527 satır). Rota: /admin/printer-management.

Bileşen Yapısı

İstemci Tarafı Arama

Arama girdisi tüm görünür sütunlarda aynı anda filtreler: ad, açıklama, IP adresi, konum, durum (İngilizce ve Türkçe terimler), port ve ID. Bu tamamen frontend filtrelemededir — tam veri seti her zaman çekilir.

WebSocket Entegrasyonu Yok

Diğer modüllerin aksine, Yazıcı Yönetimi gerçek zamanlı güncellemeler için WebSocket kullanmaz. Tablo yenilemeleri her mutasyondan (oluştur, güncelle, sil, test) sonra manuel actionRef.current?.reload() ile gerçekleşir.

6.1.9 Yetki Modeli

Sayfa ID: admin.yazici_yonetimi

Backend rol tabanlı uygular: yalnızca super_admin oluşturabilir/güncelleyebilir/silebilir, super_admin + lab_user test edebilir. Frontend bu 7 granüler yetkiyi yetki editörünün keşfetmesi için buttonRegistry’ye kaydeder.

6.1.10 Yazıcı Yönetimi Sistemin Geri Kalanına Nasıl Bağlanır

6.2 Yazdırma İzleme (Print Job Monitor)

6.2.1 Amaç ve İş Bağlamı

Her malzeme etiket yazdırması bir iş kuyruğundan geçer. İş, kullanıcı Hammadde Girişi veya Hammaddeler Listesi’nde “Yazdır”a tıkladığı anda oluşturulur ve bir arka plan işçisi bir saniye içinde onu alır. Yazdırma İzleme, bu görünmez boru hattını görünür kılan gerçek zamanlı panodur: kaç iş bekliyor, hangileri şu anda yazdırılıyor, hangileri başarılı oldu, hangileri başarısız oldu ve neden.

İki amaca hizmet eder: izleme (yazıcılar yetişebiliyor mu? başarısızlık var mı?) ve müdahale (başarısız bir işi yeniden dene, kuyruktakini iptal et). Bu alt modül olmadan, başarısız bir yazdırma 3 denemeden sonra sessizce kaybolur ve kimse bir malzemenin etiketinin eksik olduğunu bilmez.

6.2.2 Veritabanı Şeması

Tek tablo: print_jobs (model dosyası: 69 satır)

PrintJobStatus Enum (5 durum)

class PrintJobStatus(str, Enum):
    QUEUED    = "queued"      # Kuyrukta bekliyor
    PRINTING  = "printing"    # İşçi şu anda yazdırıyor
    COMPLETED = "completed"   # Etiket başarıyla yazdırıldı
    FAILED    = "failed"      # 3 denemeden sonra başarısız
    CANCELLED = "cancelled"   # Admin tarafından manuel iptal

İş Yaşam Döngüsü

Denormalizasyon Stratejisi

Üç sütun (material_type, lot_number, supplier_name) bilinçli olarak raw_materials ve suppliers’dan denormalize edilmiştir. Bu, izleme panosunun tablolar arası pahalı join’ler olmadan tüm iş verilerini göstermesini sağlar — 500’e kadar iş listeleyen bir sayfa için kritiktir.

6.2.3 API Sözleşmesi — 5 Endpoint

6.2.4 CRUD Akışı

Oluştur (Yazdırma İşi Kuyruğa Al):

1. Hammaddeler Listesi’nde bir malzeme satırındaki yazdır ikonuna tıkla (palet/makara için devre dışı)
2. Yazıcı seçim modalı açılır: QR kodu, etiket sayısı (material.quantity veya 1) ve GET /api/printers/list?active_only=true’den çekilen aktif yazıcıların açılır listesini gösterir
3. Yazıcı seç → “Yazdır”a tıkla
4. POST /api/print-queue/queue/{material_id}?printer_id=X
5. Backend malzemenin var olduğunu doğrular, ilişkiden tedarikçi adını alır, malzemenin reddedilip reddedilmediğini kontrol eder (QR’ye “ - REDDEDILDI” ekler), tür/lot/tedarikçiyi iş satırına denormalize eder
6. Başarıda: toast “Yazdırma işi kuyruğa eklendi (#123)” → modal kapanır
7. Arka plan işçisi işi 1 saniye içinde alır ve yazdırmaya başlar

Oku (İşleri İzle):

1. /admin/print-monitor sayfasına git
2. Sayfa yüklenir → GET /api/print-queue/jobs?limit=200 + GET /api/print-queue/stats
3. Üstte 4 istatistik kartı render edilir: Bekleyen (gri), Yazdırılıyor (mavi), Tamamlanan (yeşil), Başarısız (kırmızı)
4. ProTable (16 sütun) tüm işleri render eder: ID, QR kod (mavi etiket), malzeme türü (renk kodlu Türkçe etiket), lot, tedarikçi, yazıcı (filtrelenebilir 1–4), adet (kalın), durum (renk kodlu etiket), deneme sayısı (X/3 uyarı etiketi > 0 ise), hata mesajı (kırmızı tooltip), kullanıcı, istek/başlangıç/bitiş zaman damgaları (Türkiye saat dilimi), süre (saniye), işlemler
5. İstemci tarafı arama QR kod, lot, tedarikçi, kullanıcı, durum, malzeme türü, ID ve yazıcı üzerinde — Türkçe çeviriler dahil — filtreler

Yeniden Dene (Başarısız → Kuyrukta):

1. Yeniden dene butonu (RedoOutlined) yalnızca “başarısız” durumlu satırlarda görünür
2. Yeniden dene’ye tıkla → POST /api/print-queue/jobs/{id}/retry
3. Backend sıfırlar: durum → QUEUED, retry_count → 0, error_message temizlenir, started_at ve completed_at null yapılır
4. Başarıda: toast “İş #{id} tekrar kuyruğa eklendi” → tablo + istatistikler yenilenir
5. İşçi sonraki yoklama döngüsünde (1 saniye içinde) işi yeniden alır

İptal (Kuyrukta → İptal Edildi):

1. İptal butonu (CloseCircleOutlined, tehlike) yalnızca “kuyrukta” durumlu satırlarda görünür
2. İptal’e tıkla → onay modalı: “İş #{id} iptal edilsin mi?” ile “İptal Et” (tehlike) / “Vazgeç”
3. Onayda: DELETE /api/print-queue/jobs/{id}
4. Backend işin PRINTING olmadığını doğrular (“Devam eden iş iptal edilemez” ile engeller), durum → CANCELLED, completed_at damgalanır
5. Başarıda: toast “İş #{id} iptal edildi” → tablo + istatistikler yenilenir

6.2.5 Arka Plan İşçisi — İşler Nasıl Gerçekten Yazdırılır

Bu izleme sayfası ile fiziksel yazdırma arasındaki bağlantı PrintWorker’dır (292 satır, 6.1.6’da açıklanmıştır). İşçi bir işi işlerken tam veri akışı:

material_data Dict (İşçi Tarafından Oluşturulur)

Hibrit yaklaşıma dikkat edin: bazı alanlar denormalize iş satırından gelir (hızlı, join yok), ağırlık, tarih, kullanıcı adı ve notlar ise DB’den canlı çekilir (her zaman güncel).

Yeniden Deneme Mantığı (Otomatik)

Otomatik 3 deneme tükendikten sonra, iş panoda “Başarısız” olarak “3/3” deneme sayısıyla görünür. Bir admin veya lab kullanıcısı daha sonra manuel olarak yeniden deneyebilir (sayacı 0’a sıfırlar).

6.2.6 Frontend Mimarisi

Tek dosya: src/pages/Admin/PrintJobMonitor/index.tsx (509 satır). Rota: /admin/print-monitor.

Bileşen Yapısı

Tarih Biçimlendirme

Tüm zaman damgaları veritabanında UTC olarak saklanır. Frontend bunları dayjs.utc(dateStr).tz('Europe/Istanbul') kullanarak dönüştürür ve D.MM.YYYY HH:mm:ss biçiminde gösterir (örn. “18.02.2026 14:30:45”).

Malzeme Türü Etiketleri (Renk Eşlemesi)

WebSocket Yok — Manuel Yenileme

ERP’deki diğer sayfaların aksine, Yazdırma İzleme gerçek zamanlı güncellemeler için WebSocket kullanmaz. Tablo ve istatistikler mutasyonlardan (yeniden dene, iptal) sonra actionRef.current?.reload() ile ve tablonun yerleşik yenile butonuyla yenilenir. Otomatik yoklama yoktur.

6.2.7 Yetki Modeli

Sayfa ID: admin.yazdirma_izleme

Backend uygular: super_admin her şeyi yapabilir. lab_user başarısız işleri yeniden deneyebilir. operator yalnızca yeni iş kuyruğa alabilir (Hammadde Girişi üzerinden) ancak izleme panosuna erişemez.

6.2.8 Yazdırma İzleme Sistemin Geri Kalanına Nasıl Bağlanır

6.3 AI Ayarları (AI Settings)

6.3.1 Amaç ve İş Bağlamı

ERP, şu anda API entegrasyonu üzerinden Google Gemini tarafından desteklenen (OpenAI ve Anthropic Claude tamamen entegre ve hazır) bir AI asistan içerir. Asistan, kullanıcılar adına dahili API’leri çağırarak siparişler, malzemeler, üretim ve envanter hakkında soruları yanıtlayabilir. AI Ayarları, bu asistanın yapılandırma ve izleme merkezidir: API anahtar yönetimi, model seçimi, parametre ayarlama, kullanım istatistikleri ve her AI etkileşiminin kapsamlı denetim izi.

Mevcut API tabanlı entegrasyon bir hızlı demo katmanıdır — uzun vadeli vizyon paralel olarak gelişirken anlık AI yetenekleri sağlar. Yol haritası, tüm fabrika genelinde özel, yerel olarak barındırılan modeller inşa etmek ve dağıtmaktır: üretim optimizasyonu, kalite kontrol, öngörücü bakım, anomali tespiti — esasen her şeyi sürekli izleyen ve kontrol eden görünmez AI ajanları. Dil/arama bileşeni için özellikle, ERP’ye özgü arama sorgusu anlaması için ince ayar yapılmış hafif ~1B parametreli bir model (Qwen veya benzeri) kullanılacak ve harici API bağımlılığı tamamen ortadan kaldırılacaktır. Bu ayarlar sayfasındaki çoklu sağlayıcı mimarisi bu geçiş göz önünde bulundurularak tasarlanmıştır — harici API’den yerel model endpoint’ine geçiş bir yeniden yazma değil, konfigürasyon değişikliğidir.

AI ajanının kendisi ana backend’den ayrı bir serviste (solen_ai_service) yaşar. Bu alt modül kontrol düzlemini sağlar — bir yöneticinin koda veya konfigürasyon dosyalarına dokunmadan AI’yı yönetmesini sağlayan düğmeler ve panolar.

6.3.2 Veritabanı Şeması — 47 Sütunlu Denetim Günlüğü

AI sistemi adli düzeyde denetim günlüğü için iki tablo kullanır:

ai_audit_logs (47 sütun)

Her tekil AI etkileşimi tam bağlamla kaydedilir. Sütunlar 8 gruba ayrılmıştır:

11 indeks sorguları optimize eder: user_id, username, session_id, ip_address, selected_tool, success, created_at üzerinde tekli; (user_id, created_at), (selected_tool, created_at), (success, created_at), (ip_address, created_at) üzerinde bileşik.

ai_audit_log_summaries (12 sütun)

Günlük toplu istatistikler: toplam/başarılı/başarısız/engellenen sorgular, benzersiz kullanıcılar ve IP’ler, en çok kullanılan araçlar, en çok kategori, ortalama yanıt süreleri, hata dağılımı. Günde bir satır. Şu anda API üzerinden sunulmuyor — gelecekteki analitik panoları için ayrılmış.

6.3.3 API Sözleşmesi — 12 Endpoint

6.3.4 CRUD Akışı

Oluştur / Güncelle (API Anahtarı):

1. “API Anahtarları” sekmesine git → 3 sağlayıcı kartı (Google Gemini, OpenAI, Anthropic Claude) her biri logo, durum etiketi ve şifre girdisi ile
2. Şifre alanına API anahtarını gir → “Kaydet”e tıkla
3. POST /api/ai/api-keys/save ile { provider, api_key }
4. Backend doğrular: boş değil, ≥ 20 karakter, önek kontrol (Gemini için AIza, OpenAI için sk-, Anthropic için sk-ant- — yalnızca uyarı, engelleme yok)
5. solen_ai_service/.env dosyasına yazar, çalışma zamanı os.environ’ı günceller, AI ajan singleton’ını sıfırlar
6. Başarıda: toast “API anahtarı kaydedildi” + varsa önek uyarısı → kartta maskeli anahtar gösterilir → durum yenilenir

Oku (Genel Bakış Panosu):

1. /admin/ai-settings sayfasına git → “Genel Bakış” sekmesi yüklenir
2. 4 istatistik kartı: AI durumu (aktif/pasif), bugünkü sorgular, toplam sorgular, ortalama yanıt süresi
3. Başarı oranı kartı: dairesel ilerleme grafiği + başarılı/başarısız sayıları
4. Bağlantı test kartı: durum, API anahtar durumu, mevcut modeli gösterir. “Bağlantıyı Test Et” butonu GET /api/ai/status çağırır

Model Ayarlarını Güncelle:

1. “Model Ayarları” sekmesine git
2. 4 alanlı form: AI etkin (switch), model (cascader: Sağlayıcı → Model, tier etiketleri ve önerilen yıldızlarıyla), maks token (seçim: 1024/2048/4096/8192), sıcaklık (seçim: 0.1/0.3/0.5/0.7/0.9)
3. “Ayarları Kaydet”e tıkla
4. POST /api/ai/config → ai_config.json’a kaydeder
5. POST /api/ai/reset → mevcut ajanı yok eder, sonraki sorguda yeni konfigürasyonla yeniden başlatılır
6. Toast: “Ayarlar kaydedildi - AI yeniden başlatıldı”

API Anahtarı Sil:

1. Sağlayıcı kartında “Sil” butonuna tıkla
2. Onay modalı
3. DELETE /api/ai/api-keys/{provider}
4. Backend anahtarı .env dosyasından ve os.environ’dan kaldırır
5. Toast: “API anahtarı silindi” → kart yapılandırılmamış duruma döner

API Anahtarı Test Et:

1. Yapılandırılmış sağlayıcı kartında “Test Et” butonuna tıkla
2. POST /api/ai/api-keys/test/{provider}
3. Backend test eder: Gemini istemci örnekleme ile, OpenAI GET https://api.openai.com/v1/models ile, Anthropic GET https://api.anthropic.com/v1/models ile
4. Başarı toast’u veya detaylı hata toast’u

6.3.5 AI Sağlayıcı Yapılandırması

Anahtar Saklama Mimarisi

API anahtarları solen_ai_service dizinindeki .env dosyasında saklanır (ana backend’den ayrı). Veritabanında asla saklanmazlar. Kaydetme sırasında anahtar, yeniden başlatma olmadan anlık kullanım için os.environ’da da ayarlanır. Anahtarlar API yanıtlarında asla döndürülmez — yalnızca maskeli önizlemeler (ilk 8 + “...” + son 4 karakter).

Konfigürasyon Saklama

Model ayarları (enabled, model_name, max_tokens, temperature) .env dosyasının yanındaki ai_config.json’da saklanır. Varsayılanlar: enabled=true, model=gemini-3-flash, max_tokens=4096, temperature=0.7.

6.3.6 AI Ajanı — Singleton Mimarisi

AI ajanı (SolenAIAgent) istekler arasında kalıcı bir singleton’dır. İlk AI sorgusunda başlatılır ve açıkça sıfırlanıncaya kadar yeniden kullanılır.

Ajan şu durumlarda sıfırlanır (yok edilir ve yeniden oluşturulur): API anahtarları kaydedildiğinde/silindiğinde, konfigürasyon ayarlar sayfası üzerinden güncellendiğinde veya POST /api/ai/reset çağrıldığında. Bu, ajanın her zaman en son konfigürasyonu kullanmasını sağlar.

Sohbet İstek Akışı

1. Kullanıcı POST /api/ai/chat ile { query, conversation_history, user_type } gönderir
2. Backend ai_config.json’ı kontrol eder — enabled: false ise “AI servisi şu an devre dışı” döndürür
3. Ajan singleton’ını alır veya oluşturur, JWT’den kullanıcı bilgisini çıkarır
4. agent.process_query(query, history, user_type, ip, username, user_id) çağırır
5. Ajan dahili olarak: sorguyu ön işler, araç seçer, dahili API çağırır, yanıt üretir, denetim günlüğü yazar
6. Backend yanıtı temizler (ham API hatalarını gizler), { success, response, tool_used, timing_ms } döndürür

6.3.7 Denetim Günlüğü — Adli Düzeyde İzleme

Her AI etkileşimi ai_audit_logs’a 47 sütun bağlamla bir satır yazar. Denetim günlüğü her sorgu hakkında 7 soruyu yanıtlar:

1. Kim? — user_id, username, user_type, oturum bilgisi, IP, cihaz, tarayıcı, işletim sistemi
2. Ne? — orijinal sorgu, dil, tür (arama/soru/komut), kategori (sipariş/malzeme/üretim), tespit edilen varlıklar
3. Nasıl? — AI model, akıl yürütme, güven skoru, seçilen araç, araç parametreleri, değerlendirilen alternatif araçlar
4. Nereye? — çağrılan API endpoint’i, metot, yanıt durumu, yanıt verisi, yanıt boyutu
5. Sonuç? — başarı/başarısızlık, hata türü ve mesajı, son yanıt metni, yanıt türü
6. Performans? — toplam ms, AI işleme ms, API çağrısı ms, yanıt üretme ms
7. Güvenlik? — enjeksiyon bayrakları, hız sınırı durumu, engelleme bayrağı ve nedeni

6.3.8 Frontend Mimarisi

Tek dosya: src/pages/Admin/AISettings/index.tsx (1.177 satır). Rota: /admin/ai-settings.

4 Sekmeli Düzen

6.3.9 Yetki Modeli

AI Ayarları manifest’te granüler buton düzeyinde yetkilere sahip değildir. Erişim modül düzeyinde canAdmin ile kontrol edilir — admin modülüne erişimi olan herhangi bir kullanıcı AI Ayarları’nı görüntüleyebilir. Backend endpoint’lerinde JWT kimlik doğrulaması ötesinde açık yetki kontrolü yoktur.

Bu bilinçli bir tasarım seçimidir: AI konfigürasyonu buton başına bir yetki değil, admin genelinde bir yetenek olarak kabul edilir. Pratikte yalnızca super admin’ler admin modülüne erişir.

6.3.10 AI Ayarları Sistemin Geri Kalanına Nasıl Bağlanır

6.4 Kullanıcı Yönetimi (User Management)

6.4.1 Amaç ve İş Bağlamı

Kullanıcı Yönetimi, tüm ERP’nin kimlik ve yetkilendirme omurgasıdır. Diğer tüm modüller — Hammadde, Teknik, Sipariş, Üretim, Stok, Lab, Admin — iki soruyu yanıtlamak için bu alt modüle bağımlıdır: “Bu kişi kim?” (kimlik doğrulama) ve “Ne yapmaya yetkili?” (yetkilendirme). Sistemdeki en karmaşık alt modüldür çünkü hibrit bir yetki modeli uygular: eski rol tabanlı erişimin üzerine katmanlanan, 8 modül, 26+ sayfa ve 200+ eylem üzerinde tek tek UI butonlarına kadar görünürlüğü kontrol eden granüler sayfa+buton yetki sistemi.

Fabrikada üç temel kullanıcı arketipi vardır: Süper Admin (tam sistem kontrolü, masaüstü), Lab Kullanıcısı (kalite testi, masaüstü) ve Operatör (makine kullanımı, mobil kiosk). Bunların ötesinde sistem, her biri elle hazırlanmış yetkilerle sınırsız özel kullanıcı tipini destekler.

6.4.2 Veritabanı Şeması — 6 Tablo, Joined-Table Kalıtım

users (17 sütun) — Temel Kimlik Tablosu

Joined-Table Kalıtım — Uzantı Tabloları

Her kullanıcı tipinin user_id FK → users.id (benzersiz, bire-bir) ile bağlanan özel bir uzantı tablosu vardır. Bunlar tipe özgü meta verileri saklar:

SQLAlchemy backref’ler navigasyon sağlar: user.super_admin_profile, user.lab_user_profile, user.operator_profile.

user_sessions (11 sütun)

user_roles (7 sütun)

Yeniden kullanılabilir yetki şablonları (rol tanımları). Her rol, kullanıcılara hızla uygulanabilen tam bir yetki JSON’ı saklar.

user_activity_logs (11 sütun)

Kullanıcılar üzerindeki her yönetim eylemi için denetim izi. username hızlı okuma için denormalize edilmiştir.

6.4.3 Kimlik Doğrulama Sistemi — JWT Token’lar ve Oturumlar

Token Mimarisi

6 aylık token sabit kodlanmış bir kontrolle tetiklenir: if user.username == 'operator'. Bu bilinçlidir — paylaşılan operator hesabı, aylarca oturum açık kalması gereken duvara monte telefonlarda kullanılır.

Şifre Sistemi

Uçtan Uca Giriş Akışı

1. Kullanıcı POST /auth/login’a kullanıcı adı + şifre gönderir
2. Backend kullanıcıyı kullanıcı adı veya e-posta ile sorgular (büyük/küçük harf duyarsız)
3. is_active == True ve status != "suspended" kontrol eder
4. Şifreyi bcrypt ile doğrular
5. last_login zaman damgasını günceller
6. user_id, username, user_type, permissions ile JWT payload oluşturur
7. Operatör hesabıysa: 6 ay süre; değilse 12 saat
8. UserSession satırı oluşturur (session_token, refresh_token, cihaz bilgisi, IP, süre)
9. { access_token, refresh_token, expires_in, user } döndürür
10. Frontend token’ları ve kullanıcıyı localStorage’a kaydeder (anahtarlar: solen_auth_token, solen_refresh_token, solen_current_user)
11. Operatörler /production’a, diğerleri /welcome’a yönlendirilir

Kiosk Otomatik Giriş

Giriş sayfası fabrika kiosk cihazlarını iki şekilde algılar:

1. User-Agent algılama: tarayıcı user-agent string’inde “FullyKiosk” kontrolü (Fully Kiosk Browser fabrika telefonlarında çalışan uygulamadır)
2. Gizli URL token’ı: URL’de ?kiosk=SOLEN_FACTORY_2024_KIOSK_SECRET kontrolü

Eşleşme olursa sayfa otomatik olarak operator / op123 ile giriş yapar ve /production’a yönlendirir — insan etkileşimi gerekmez.

Token Yenileme ve Çıkış

1. Yenileme: POST /auth/refresh ile yenileme token’ı → doğrular, yeni erişim token’ı üretir, yeni oturum oluşturmaz
2. Çıkış: POST /auth/logout ile erişim token’ı → oturum status = "terminated" ve logout_time ayarlanır → frontend localStorage’ı temizler

6.4.4 Yetki Sistemi — En Karmaşık Bölüm

Yetkilendirme sistemi, rota düzeyinden tek tek buton görünürlüğüne kadar erişimi kontrol eden 5 katmanlı bir mimaridir:

Katman 1: Yetki Manifesti (permissionManifest.ts, 565 satır)

Tüm ERP’deki her yetkilendirilebilir eylemin statik, merkezi tanımı. Modül → Sayfa → Buton hiyerarşisi:

Toplam: 8 modül, 26+ sayfa, 200+ buton.

Her butonun meta verisi vardır:

interface ButtonPermission {
  id: string;       // örn. "hard_delete_material"
  label: string;    // örn. "Kalıcı Silme"
  description: string; // örn. "Malzemeyi veritabanından tamamen siler"
  critical?: boolean; // true = yetki düzenleyicide kırmızı vurgulanmış
}

Manifest ayrıca yardımcı fonksiyonlar da export eder: createEmptyPermissions() (tümü false), createFullPermissions() (tümü true), getAllPages(), getAllButtons().

Katman 2: Buton Kayıt Defteri (buttonRegistry.ts, 130 satır)

Statik manifeste dinamik bir tamamlayıcı. Bileşenler çalışma zamanında registerPageButtons() ile butonlarını kaydedebilir. buildCompleteManifest() fonksiyonu statik manifest sayfalarını dinamik kayıt defteri butonlarıyla birleştirir. Bu, yeni sayfaların merkezi manifest dosyasını değiştirmeden yetkilerini kendilerinin kaydetmesine olanak tanır.

Katman 3: Erişim Kontrolü — Rota Korumaları (access.ts, 93 satır)

Her rota değişikliğinde çalışır. Mevcut kullanıcının permissions JSON’ını ayrıştırır ve routes.ts tarafından tüketilen boolean bayraklar döndürür:

return {
  canAdmin: canAccessModule('admin'),     // /admin/* rotalarını korur
  canLab: canAccessModule('lab'),         // /lab/* rotalarını korur
  canProduction: canAccessModule('production'),
  canHammadde: canAccessModule('hammadde'),
  canTeknik: canAccessModule('teknik'),
  canSiparis: canAccessModule('siparis'),
  canStok: canAccessModule('stok'),
  canDashboard: canAccessModule('dashboard'),
  // ... artı alt sayfa korumaları
};

canAccessModule(prefix), o modül altındaki herhangi bir sayfa access: true ise true döndürür. Rotalar bunları koruma olarak kullanır: rota konfigürasyonunda access: 'canAdmin'.

Katman 4: Yetki Yardımcıları — Bileşen Düzeyi (permissions.ts, 145 satır)

Tek tek bileşenler için ince ayar kontrolleri sağlar:

• canAccessModule(module) — modül etkin mi?
• canPerformAction(module, action) — belirli eylem izinli mi?
• hasSpecialPermission(permission) — örn. hard_delete

Ayrıca React sarıcı bileşenleri export eder:

• <PermissionButton module="hammadde" action="delete"> — yetkiye göre butonu göster/gizle
• <PermissionGuard module="admin" action="manage"> — herhangi bir bileşeni yetki kontrolüyle sar, reddedilirse fallback göster

Katman 5: Backend Zorlama (permission_checker.py, 200 satır)

Sunucu tarafı aynası. Bir kullanıcı frontend’i atlasa bile backend yetkileri zorlar:

Süper admin atlama: Her yetki fonksiyonu önce user.user_type == "super_admin" kontrol eder ve hemen True döndürür.

Yetki JSON Yapısı

users.permissions sütununda JSON string olarak saklanır. Frontend ve backend arasındaki sözleşme:

{
  "pages": {
    "hammadde.hammadde_girisi": {
      "access": true,
      "buttons": {
        "add_copper": true,
        "add_tin": false,
        "submit_form": true,
        "print_qr": true
      }
    },
    "production.planning": {
      "access": false,
      "buttons": {}
    }
  }
}

6.4.5 API Sözleşmesi — 14 Endpoint (9 Kullanıcı Yönetimi + 5 Auth)

Kimlik Doğrulama Endpoint’leri (5)

Kullanıcı Yönetimi Endpoint’leri (9)

6.4.6 CRUD Akışı

Oluştur (Yeni Kullanıcı):

1. “Yeni Kullanıcı” butonuna tıkla → 3 sekmeli modal açılır
2. Sekme 1 – Temel Bilgiler: kullanıcı adı (gerekli, alfanümerik + alt çizgi), e-posta (doğrulanmış), tam ad, şifre (isteğe bağlı — boşsa otomatik üretilir), kullanıcı tipi (seç veya satır içi özel tip oluştur), durum, şifre değiştirme zorunlu onay kutusu
3. Sekme 2 – Yetkiler: yetki düzenleyici — üstte 4 hızlı şablon (“Tüm Yetkiler”, “Hiçbiri”, “Operatör Varsayılan”, “Lab User Varsayılan”), ardından kaydırılabilir modül listesi. Her modül sayfaları gösterir, her sayfada: erişim switch’i, “Tümü”/“Hiçbiri” hızlı geçişler, tek tek buton onay kutuları. Kritik butonlar kırmızı vurgulanır. Bir butonu etkinleştirmek sayfanın erişimini otomatik etkinleştirir. Sayfa erişimini kapatmak tüm butonlarını kapatır.
4. Sekme 3 – Önizleme: salt okunur özet, erişilebilir modüller → sayfalar → etkin butonları renk kodlu etiketlerle gösterir
5. “Oluştur”a tıkla → POST /user-management/users/create ile { username, email, full_name, user_type, status, permissions, force_password_change, return_password: true }
6. Backend benzersizliği doğrular (kullanıcı adı, e-posta), şifreyi bcrypt ile hashler, kullanıcı + yetki JSON’ını saklar, aktivite kaydeder
7. Şifre otomatik üretildiyse: modal üretilen şifreyi “Bu şifreyi not edin, tekrar gösterilmeyecektir” uyarısıyla gösterir

Oku (Kullanıcı Listesi):

1. /admin/user-management’a git → ProTable GET /user-management/users/list ile yüklenir
2. 7 sütun: ID (sabit sol), Kullanıcı (kullanıcı adı + tam ad), E-posta, Tip (renkli etiket), Durum (renkli etiket), Son Giriş (UTC → Istanbul), İşlemler (sabit sağ)
3. İstemci tarafı arama kullanıcı adı, e-posta, tam ad, kullanıcı tipi ve durum üzerinde aynı anda filtreler
4. Sayfalama: sayfa başına 10/20/50/100
5. ProTable yoğunluk ve sütun ayarları kontrolleri

Güncelle (Kullanıcı Düzenle):

1. Kullanıcı satırındaki düzenle ikonuna (EditOutlined) tıkla → aynı 3 sekmeli modal açılır, kullanıcı verileriyle doldurulmuş
2. Mevcut yetkiler yüklenir ve ayrıştırılır (string JSON → nesne dönüşümünü yönetir)
3. Şifre alanı düzenleme modunda gizlidir (bunun için Şifre Sıfırla kullanın)
4. Herhangi bir alan veya yetkiyi değiştir → “Güncelle”ye tıkla
5. PUT /user-management/users/{id} ile değişen alanlar + tam yetki nesnesi
6. Backend doğrular, günceller, aktivite kaydeder

Sil (Kalıcı):

1. Kullanıcı satırındaki sil ikonuna (DeleteOutlined, tehlike) tıkla
2. Onay modalı: “Bu kullanıcıyı silmek istediğinizden emin misiniz?”
3. DELETE /user-management/users/{id}
4. Backend kendini silmeyi engeller (400 hatası). Kullanıcı kaydını kalıcı olarak siler. Aktivite kaydeder.

Askiya Al / Etkinleştir:

1. Kullanıcı satırındaki durdur ikonuna (StopOutlined) tıkla
2. POST /user-management/users/{id}/suspend
3. active ve suspended arasında durumu değiştirir. Askıya alınmış kullanıcılar giriş yapamaz.

Şifre Sıfırla:

1. Kullanıcı satırındaki anahtar ikonuna (KeyOutlined) tıkla
2. POST /user-management/users/{id}/reset-password
3. Backend kriptografik olarak güvenli 12 karakterlik şifre üretir, bcrypt ile hashler, force_password_change = True ayarlar
4. Modal yeni şifreyi uyarıyla bir kez gösterir. Admin şifreyi kullanıcıya bant dışından iletmelidir.

6.4.7 Kullanıcı Tipleri ve Farkları

Özel tipler (örn. teknik_user, bakim_user, data) doğrudan Kullanıcı Yönetimi modalında oluşturulabilir — kullanıcı tipi dropdown’ının altındaki bir girdi alanı yeni tip adı yazmaya olanak tanır. user_type alanı serbest bir String(50)’dir, enum değil, bu esnekliği sağlar.

6.4.8 Frontend Mimarisi

Tek dosya: src/pages/Admin/UserManagement/index.tsx (960 satır). Rota: /admin/user-management.

ProTable (7 sütun)

Yetki Düzenleyici (Modal’ın Sekme 2’si)

Tüm ERP’deki en karmaşık UI bileşeni. 8 modülün her biri için:

1. Modül başlığı: ikon ile modül adı
2. Sayfa kartları: her sayfa Card bileşeni olarak:
   • Başlık: sayfa erişimi için Switch + sayfa etiketi + “X/Y” etkin buton sayısı gösteren etiket
   • Hızlı eylemler: “Tümü” (tümünü etkinleştir) / “Hiçbiri” (tümünü kapat) metin butonları
   • Buton ızgarası: her buton için Row/Col düzeninde Checkbox bileşenleri
   • Kritik butonlar: kırmızı metin ve farklı stille vurgulanmış
3. Akıllı geçiş: herhangi bir butonu etkinleştirmek sayfanın erişimini otomatik etkinleştirir. Sayfa erişimini kapatmak tüm butonları kaskad olarak kapatır.

Hızlı Şablonlar

Önizleme Sekmesi (Sekme 3)

Card bileşenleri kullanan salt okunur özet. Yalnızca erişilebilir modülleri/sayfaları gösterir. Her sayfa etkin butonlarını Tag olarak listeler (kritik olanlar kırmızı). Kaydetmeden önce hızlı görsel onay sağlar.

6.4.9 Aktivite Günlüğü — Admin Denetim İzi

Her kullanıcı yönetimi eylemi log_activity() yardımcı fonksiyonu aracılığıyla user_activity_logs’a kaydedilir:

Günlükler GET /user-management/activity-logs ile user_id, module, action ve limit (varsayılan 200) filtreleriyle sorgulanabilir. Yalnızca süper adminler bu endpoint’e erişebilir.

6.4.10 Yetki Modeli

Kullanıcı Yönetimi sistemdeki en yüksek ayrıcalık düzeyini gerektirir:

Yetki manifestinde Kullanıcı Yönetimi’nin 9 kayıtlı butonu vardır: access_page, view_users, create_user, edit_user, manage_permissions, suspend_user, reset_password, delete_user, view_activity_logs.

Backend rol tabanlı erişim zorlar: /user-management/operators hariç her endpoint current_user.user_type != "super_admin" kontrol eder ve başarısız olursa 403 döndürür.

6.4.11 Kullanıcı Yönetimi Sistemin Geri Kalanına Nasıl Bağlanır