Planlanan şirket ve depo hiyerarşisi

Uygulanmamış tasarım

Planlanan veri hiyerarşisi Company → Warehouse → Order idi. Kullanıcıların bu ağacın içine gömülmemesi, hangi şirkette veya depoda çalışabileceklerinin ayrı bir çalışma izni kaydıyla belirlenmesi önerildi.

Bugün nasıl?

Bugünkü şemada bu hiyerarşi örtük ve iki farklı modele dağılmış durumda:

Bugünkü kurgu	Sorun
`Warehouse.adminId` her depoyu tek bir `Admin`'e bağlıyor, `onDelete: Cascade` ile — admin silinirse depo da silinir.	Kullanıcı kaydı (kim admin) ile depo sahipliği aynı FK'de birleşmiş.
`Admin.warehouses` bir admin'in birden fazla depoya sahip olabildiğini gösteriyor.	`Admin` böylece hem "yönetici rolündeki kullanıcı" hem örtük bir "tenant sahibi" gibi davranıyor — iki farklı kavram tek modelde.
`Permission` / `UserPermission` düz bir yetki listesi: kullanıcı hangi işlemi yapabilir.	"Nerede" (hangi depoda/şirkette) çalışabileceği bilgisini taşımıyor; depo ataması `AdminOfficer` gibi ayrı join tablolarıyla dolaylı yürüyor.

Planlanan hedef nasıldı?

Company yeni bir üst model — bugünkü Admin.warehouses ilişkisinin yerini alır. Bir Company birden fazla Warehouse'a sahip olabilir.
Warehouse, adminId yerine companyId taşır. Depo artık bir kullanıcıya değil, bir şirkete bağlı.
Order, bugün olduğu gibi Warehouse'a bağlı kalır — bu seviyede değişiklik yok.
Kullanıcılar bu ağaca FK ile gömülmüyor. Karar: çalışma izni her zaman Warehouse seviyesinde — Company ayrıca atanabilir bir seviye değil. Bir kullanıcının "hangi şirketlerde çalıştığı", atandığı depoların bağlı olduğu şirketlerden türetilir (birden fazla depo aynı şirkete bağlıysa, o şirket bir kez görünür). Aynı kullanıcı birden fazla depoda (farklı şirketlere bağlı olsa bile) çalışma izni taşıyabilir.

Planlanan aktif depo bağlamı: HTTP header

Bu tasarımda bir kullanıcının birden fazla depoda çalışma izni olabileceği için, her istekte hangi depo bağlamında işlem yaptığı belirlenmeliydi. Önerilen seçim akışı: kullanıcı önce atandığı depoların bağlı olduğu şirketleri görür → bir şirket seçer → o şirketin depolarını görür → bir depo seçer.

Öneri, seçimi her endpoint'e ayrı companyId/warehouseId parametresi olarak eklemek yerine bir HTTP header ile taşımaktı (ör. X-Warehouse-Id). Sunucu tarafında bu header'ın bir guard tarafından doğrulanması ve controller'lara @GetWarehouseContext() benzeri bir decorator ile verilmesi düşünülüyordu.

Bu header ve decorator v2'de uygulanmış değildir.

v2 bugün ne yapıyor?

Muhasebe yüzeyinde rol ve depo kapsamı sunucuda çıkarılır:

Yazma ve onay controller'ları @FinanceRoles() ile ADMIN veya desteklenen finans personeli rolünü ister.
Bu dekoratör kullanıldığında RolesGuard, OFFICER rolünü token'dan değil güncel personel kaydından okur.
depotOf(userId), kullanıcının yönettiği veya AdminOfficer üzerinden bağlı olduğu depoları belirler.

Bugün @FinanceRoles() tarafından desteklenen finans personeli rolü MANAGER'dır. Cari, kasa ve banka, tahsilat, havale, POS, fatura içe aktarma ve stok yazmaları bu daraltmayı kullanır. Bazı yeni okuma uçları (/finance/accounts, /finance/invoices) ADMIN ile bütün OFFICER tiplerini controller seviyesinde kabul eder; taşınmış v1 uçları da kendi uyumluluk sınırlarını korur. Dolayısıyla “bütün muhasebe uçları yalnız MANAGER memura açıktır” genellemesi doğru değildir.

Panelin açılabilir yüzey ve depo bilgisi GET /auth/me yanıtından gelir. İstemci genel bir X-Warehouse-Id bağlamı göndermez.

Planlanan kapsam: bütün alanlar

Eski tasarımda çalışma izninin admin/officer atamasına özel olmaması, warehouse'a bağlı veriyi okuyan veya yazan her endpoint'te uygulanması planlanmıştı:

Alan	Warehouse'a bağlı örnek
Admin	Yetkili ataması, alıcı CRM'in destek konuşmalarındaki görünürlüğü (bkz. v1 mesajlaşma analizi)
Satış	`WarehouseProduct` (depoya özel fiyat/stok kartı), depoya göre katalog görünürlüğü
Lojistik	`stock`, `transfer`, `warehouse`'un kendisi
Muhasebe	`FinancialAccount.warehouseId`, depo bazlı fatura sırası

Bu genel katman bugün yoktur. v2'nin depotOf kapsamı önce muhasebe yüzeyinin somut ihtiyacı için uygulanmıştır.

Planlanan permission ilişkisi

Eski tasarımda iki sistemin ayrı kalıp birlikte okunması öngörülüyordu:

Permission / UserPermission (mevcut, değişmiyor) → kullanıcının ne yapabildiğini tanımlar (yetki kodu).
Çalışma izni (yeni) → kullanıcının nerede (hangi Warehouse'da; Company oradan türetilir) çalışabildiğini tanımlar.

Bir işlemin yetkisi kontrol edilirken ikisi birlikte sorgulanır: "bu işlemi yapabiliyor mu" + "bu depoda/şirkette çalışıyor mu."

Uygulanırsa etkilenecek v1 yapıları

Aşağıdaki liste Company/Warehouse modelinin kendisinden doğrudan etkilenenler — çalışma izninin genel kapsamı için yukarıdaki bölüme bakın, bu tablo kapsayıcı değil.

Modül	Etki
`warehouse`	`Warehouse.adminId` kalkar, `companyId` gelir. Yeni bir `Company` CRUD yüzeyi gerekir.
`admin`	`Admin` modelinin "tenant sahibi" anlamı kalkar — sadece yönetici rolündeki kullanıcıyı temsil eder. v1 modül alan haritası'ndaki "üç ayrı iş bir arada" notunu kısmen çözer.
`officer`	Depo ataması bugünkü `AdminOfficer` yerine yeni çalışma izni kaydına taşınabilir.
`financial`	Hesaplar bugün depo bazlı (`FinancialAccount.warehouseId`); şirket bazlı konsolide görünüm ihtiyacı doğabilir — açık soru.
`invoice`	Fatura sıra numarası (`InvoiceSequence`) bugün hangi seviyede tanımlı, Company eklenince aynı kalıp kalmayacağı netleşmeli.

Açık noktalar

Company'nin kendi alanları ne olacak (isim, adres, vergi no, vb.)?
FinancialAccount ve InvoiceSequence company bazında mı, warehouse bazında mı kalacak?
Bugünkü Warehouse.adminId / Admin.warehouses verisi Company modeline nasıl göç edecek?
X-Warehouse-Id header'ı hiç gönderilmezse (veya kullanıcının o depoda izni yoksa) ne olacak — istek reddedilecek mi, yoksa kullanıcının tek/ilk deposuna mı düşecek?
Web/yönetim paneli tarafında depo seçimi nasıl saklanacak (oturum başına mı, her cihazda ayrı mı)?

Durum

Prisma şema taslağı, Company modeli ve veri geçişi hazırlanmadı. Bu tasarım ertelenmiş bir alternatif olarak durur; çalışan v2 kapsamı için v2 mimarisi, veri ve şema sınırı için Geçiş ve veri sahipliği sayfaları geçerlidir.