Problem
Birden fazla kuruluşun destek taleplerini aynı uygulamada yönetirken kuruluşlar arası veri erişimini engellemek gerekiyordu. Müşterilerin ortak kuruluş kuyruğunu görebilmesi, personele özel notların ise müşteri görünümüne çıkmaması hedeflendi.
Kişisel katkım
Java 21, Spring Boot, React ve TypeScript ile talep oluşturma, atama, durum geçişleri, yorumlar ve iç notlar geliştirdim. Kuruluş ve rol kontrollerini API'de uyguladım. PostgreSQL/Testcontainers entegrasyon testleri, GitHub Actions kontrolleri ve dağıtım/kurtarma belgeleri ekledim.
Mimari
Şema, tek sunuculu uygulamanın temel veri akışıdır.
React / TypeScript
→ HTTPS / Nginx
→ Spring Boot API
→ Kuruluş + rol kontrolü
→ PostgreSQL
├─ Ticket değişikliği
└─ Audit / geçmiş kaydı
(aynı transaction)
Flyway → şema geçişleri
Testcontainers → PostgreSQL entegrasyon testleri
Bir karar ve karşılığı
Talep değişikliği ile audit kaydını aynı transaction içinde tuttum: geçmiş kaydı yazılamazsa ana işlem de geri alınır. Böylece izsiz değişiklik oluşmaz; karşılığında audit yazımındaki hata kullanıcı işlemini de durdurur. Optimistic locking, çakışan güncellemelerde HTTP 409 üretir.
Kanıt
Herkese açık depo, kodu, örnek ekranları ve kurulum adımlarını içerir. doğrulama raporu, 24 backend ve 9 frontend testini o tarihe ait geçmiş kanıt olarak kaydeder ve ilgili sürümün başarılı CI çalışmasına bağlanır. Bunlar bugün yeniden çalıştırılmış test sonuçları değildir.
Yayındaki uygulama özel hesap gerektirir. İnceleme için herkese açık kaynak kod ve README'deki gerçek ekran görüntüleri kullanılabilir.
Sınırlar
Bu, küçük ekipler için tek sunuculu bir MVP'dir. SSO, SLA otomasyonu, dosya yükleme ve yüksek erişilebilirlik tamamlanmış özellikler değildir. Müşteriler kuruluş içindeki tüm talepleri paylaşır; kişiye özel gelen kutusu sunulmaz. Yorum ve geçmiş için tam sayfalama da takip işidir.