Onay akışı
Roller, bağlantı tanımlamaları ve bir sorgu talebinin gönderimden onaya, maskelenmiş ve denetlenmiş sonuca uzanan yaşam döngüsü.
Güncelleme:
QueryProxy’de her şey tek bir nesnenin etrafında döner: sorgu talebi. Bu kılavuz kimin ne yapabildiğini ve bir talebin her adımda başına gelenleri anlatır.
Roller
| Rol | Yetkileri |
|---|---|
| Admin | Sistem genelinde her şey: takımlar, kullanıcılar, tüm ayarlar. Kullanıcı bazında verilir (is_admin). |
| DBA | Bağlantıları ve maskeleme kurallarını yönetir, erişim tanımlar, talepleri onaylar/reddeder. |
| Developer | Tanımlanmış bağlantılar üzerinden sorgu gönderir, kendi (maskelenmiş) sonuçlarını görür. |
| Auditor | Denetim günlüğüne ve talep geçmişlerine salt-okunur erişim. |
Admin globaldir; DBA, Developer ve Auditor takım bazındadır. Bir kullanıcı birden çok takımda farklı rollerle yer alabilir. Bağlantılar, talepler, maskeleme kuralları ve denetim günlükleri takım sınırını asla aşmaz.
Bağlantılar ve tanımlamalar
DBA’ler hedef veritabanlarını Connections altında kaydeder. Kimlik bilgileri (host, port, veritabanı, kullanıcı adı, parola) AES-256 ile şifreli saklanır ve kaydedildikten sonra bir daha gösterilmez — günlüklere veya hata mesajlarına da düşmez.
Bir geliştirici, bir bağlantıyı ancak DBA kendisine tanımladıktan sonra görür (Connections → Grants). Tanımlanmamış bağlantılar Query Studio’da görünmez.
Talebin yaşam döngüsü
pending ──▶ approved ──▶ queued ──▶ running ──▶ completed
│ │
├──▶ rejected (gerekçe zorunlu) └──▶ failed
└──▶ cancelled (talep sahibi tarafından)- Gönderim. Geliştirici Query Studio’da SQL yazar. SQL korumaları gönderimden önce doğrular — kural ihlal eden talep kuyruğa hiç girmez.
- Bekleme. Talep, biri karar verene kadar süresiz bekler; otomatik zaman aşımı yoktur. Takım DBA’leri portalda ve yapılandırıldıysa Slack / Teams üzerinden bilgilendirilir.
- Onay / Red. Takımın herhangi bir DBA’i karar verebilir — kendi talepleri hariç: kendine onay engellidir. Admin’ler bu engeli aşabilir; aşım denetim günlüğünde işaretlenir. Red için yazılı gerekçe zorunludur.
- Çalıştırma. Onaylanan talepler kuyruğa girer ve işçi tarafından alınır. Okumalar veritabanı cursor’ı üzerinden sonuç dosyasına akar; her satıra yazılmadan önce maskeleme uygulanır. Yazmalar etkilenen satır sayısını raporlar; çok ifadeli talepler atomik çalışır ve herhangi bir ifade başarısız olursa tamamı geri alınır.
- Sonuçlar. Talep sahibi (ve takımın DBA/denetçileri) sonuçları sayfa sayfa görüntüleyebilir ya da CSV indirebilir. Sonuç dosyaları yapılandırılan saklama süresi sonunda otomatik silinir.
Bildirimler
Talep sahipleri, talepleri karara bağlandığında ve çalıştırma bittiğinde; DBA’ler yeni gönderimlerde bilgilendirilir. Bildirimler portalın zil menüsünde ve yapılandırıldıysa sohbet kanalınızda görünür.
Denetim izi
Yukarıdaki her adım bir denetim kaydı yazar: gönderim, karar (kanal ve aşım işaretiyle), çalıştırma başlangıcı/bitişi (süre ve etkilenen satırlarla), sonuç indirmeleri; ayrıca girişler, tanımlamalar ve yapılandırma değişiklikleri. Denetim kayıtları değiştirilemez — model katmanı güncelleme ve silmeyi reddeder. Denetçiler izi filtreleyebilir ve CSV olarak dışa aktarabilir.