PROJE Tenant YAPISI HAKKINDA

[thrhead]

✦ Bu proje, teknik yapısı ve iş mantığı açısından tek kiracılı (single-tenant) bir yapıya sahiptir. Yani sistem, tek bir ana organizasyonun (örneğin bir montaj firmasının) kendi saha ekiplerini,
projelerini ve müşterilerini yönetmesi için tasarlanmıştır.

Mimari Yapı Özeti

1. Tek Kiracılı (Single-Tenant) Yapı:

   • Veritabanı şemasında (schema.prisma) herhangi bir tenantId veya organizationId ayrımı bulunmamaktadır. Tüm veriler (işler, ekipler, kullanıcılar) aynı global kapsamda değerlendirilir.
   • Sistem, "SaaS" (yazılımı hizmet olarak sunan ve binlerce farklı firmanın her birinin kendi izole alanına sahip olduğu yapı) mantığından ziyade, kurumsal bir iç araç veya özel bir B2B platformu
     karakterindedir.

2. Hiyerarşik Yetkilendirme (RBAC):
   Proje, kullanıcı rollerine dayalı katı bir hiyerarşi üzerine kuruludur:

   • Admin: Sistem geneli tam yetki.
   • Manager: Operasyon yönetimi, iş atama ve maliyet onayı.
   • Team Lead: Sahadaki ekibin koordinasyonu.
   • Worker: Mobil uygulama üzerinden iş adımlarını tamamlama, fotoğraf yükleme ve masraf girişi.
   • Customer: Sadece kendi işlerini izleme yetkisine sahip dış paydaş.

3. Teknoloji Yığını (Tech Stack):

   • Frontend: Web tarafında Next.js, mobil tarafta React Native (Expo) kullanılmaktadır.
   • Backend: Next.js API Routes üzerinden sunucu tarafı mantığı yönetilir.
   • Veritabanı: PostgreSQL ve Prisma ORM ikilisiyle tip güvenli veri erişimi sağlanır.
   • Gerçek Zamanlı İletişim: Bildirimler ve anlık mesajlaşma için Socket.IO entegrasyonu vardır.

4. Kritik Özellikler:

   • Offline Mode: Hem web hem mobil tarafında gelişmiş bir çevrimdışı çalışma desteği (SyncManager, QueueService) bulunur. İnternet yokken yapılan işlemler kuyruğa alınır ve bağlantı geldiğinde
     senkronize edilir.
   • E2E Mesajlaşma: Saha ekipleri ve yönetim arasında uçtan uca şifreli mesajlaşma modülü mevcuttur.
   • Süreç Takibi: İşler (Jobs), Adımlar (Steps) ve Alt Adımlar (Sub-steps) şeklinde detaylandırılmıştır ve her adım için fotoğraf kanıtı istenebilir.

Özetle; Structra (Assembly Tracker), saha operasyonlarını tek bir merkezden yönetmek isteyen bir kuruluşun tüm iş akışını dijitalleştiren, hibrit (Web + Mobil) ve tek kıracılı bir sistemdir.

---

✦ Bu sistemi çok kiracılı (multi-tenant) bir yapıya dönüştürmek, yani farklı şirketlerin (kiracıların) birbirinin verisini görmeden aynı uygulama üzerinden hizmet almasını sağlamak için mimaride köklü
değişiklikler yapılması gerekir.

İzlenebilecek iki ana yol vardır:

1. Mantıksal Ayrıştırma (Paylaşımlı Veritabanı - SaaS Yaklaşımı)
   En yaygın ve ölçeklenebilir yöntem budur. Tüm kiracılar aynı veritabanını kullanır ancak her veri satırı bir "kiracı kimliği" (tenantId veya organizationId) ile işaretlenir.

Yapılması Gerekenler:

• Veritabanı Şeması (schema.prisma):
  • Yeni bir Organization veya Tenant modeli eklenmelidir.
  • Neredeyse tüm tablolara (User, Job, Team, Customer, JobTemplate, Notification vb.) bir organizationId alanı eklenmeli ve bu alan üzerinden ilişkiler kurulmalıdır.
• Kimlik Doğrulama (Auth):
  • src/lib/auth.ts dosyasında, kullanıcı login olduğunda hangi organizasyona ait olduğu Session/JWT içine eklenmelidir.
• Veri Erişim Katmanı:
  • Yazılan tüm Prisma sorguları where: { organizationId: session.user.organizationId } filtresini içerecek şekilde güncellenmelidir. (Prisma Middleware veya Client Extensions kullanılarak bu
    otomatik hale getirilebilir).
• Dosya Depolama:
  • Yüklenen fotoğraflar (StepPhoto), depolama alanında (S3, Vercel Blob vb.) organizasyon bazlı klasörlere (/tenant-uuid/job-id/photo.jpg) ayrıştırılmalıdır.
• URL Yapısı:
  • Opsiyonel olarak her kiracıya bir alt alan adı (subdomain) verilebilir: firma1.structra.io, firma2.structra.io.

2. Fiziksel Ayrıştırma (Her Kiracıya Ayrı Instance)
   Eğer kiracı sayısı azsa veya verilerin fiziksel olarak ayrı durması (güvenlik/regülasyon gereği) isteniyorsa bu yol tercih edilebilir.

Yapılması Gerekenler:

• Deployment Otomasyonu:
  • Her yeni müşteri için uygulamanın ve veritabanının yeni bir kopyası (container/instance) ayağa kaldırılır.
• Merkezi Yönetim (Control Plane):
  • Hangi müşterinin hangi veritabanına/URL'ye gideceğini bilen merkezi bir yönlendirici (Router) veya yönetim paneli gerekir.

---

Mevcut Proje İçin Pratik Öneri
Eğer amacınız hızlıca bu sistemi farklı bir firmaya kurmaksa, şu anki haliyle 2. yöntemi (ayrı kurulum) kullanmak en mantıklısıdır:

1. Yeni bir veritabanı oluşturun.
2. Projeyi yeni bir ortam değişkeni (DATABASE_URL) ile ayrı bir domainde (örn: musteri2.structra.io) deploy edin.

Ancak gerçek bir SaaS platformu kurmak istiyorsanız, 1. yöntemi uygulayarak kod tabanını "Tenant-Aware" (Kiracı Bilinçli) hale getirecek bir refactoring sürecine girmeniz gerekir.

[github-actions]

🤖 Hi @thrhead, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.

[github-actions]

🤖 I'm sorry @thrhead, but I was unable to process your request. Please see the logs for more details.