Şirket, depo, sipariş hiyerarşisi

Hedef yapının ilk kararı

v2'nin veri hiyerarşisi şöyle kurulacak: Company → Warehouse → Order. Kullanıcılar (admin, yetkili, vb.) bu ağacın içine gömülmüyor — hangi şirkette veya depoda çalışabileceklerini ayrı bir çalışma izni kaydı belirliyor.

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.

Hedefte nasıl?

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.

Aktif depo bağlamı nasıl taşınır: HTTP header

Bir kullanıcının birden fazla depoda çalışma izni olabildiği için, her istekte hangi depo bağlamında işlem yaptığı belirlenmeli. Seçim akışı: kullanıcı önce atandığı depoların bağlı olduğu şirketleri görür (türetilmiş liste) → bir şirket seçer → o şirketin depolarını görür → bir depo seçer.

Karar: Bu seçim, her endpoint'e ayrı companyId/warehouseId parametresi olarak eklenmek yerine — tıpkı JWT token'ın zaten öyle taşınması gibi — bir HTTP header ile taşınacak (ör. X-Warehouse-Id). Sunucu tarafında bu header, mevcut AtGuard'a benzer bir guard tarafından okunur; kullanıcının o depoda gerçekten çalışma izni olup olmadığı doğrulanır; controller'lara @GetCurrentUserId()'ye benzer bir @GetWarehouseContext() decorator'ıyla enjekte edilir. Company, header'daki depodan türetilir — ayrıca taşınmasına gerek yok.

Bu, her endpoint imzasına iki ekstra parametre eklemek yerine, kimlik doğrulamayla aynı katmanda çözülen tek bir cross-cutting concern haline getiriyor.

Kapsam: sadece admin/officer'a özel değil, bütün alanlarda geçerli

Karar: Çalışma izni admin/officer atamasına özel bir kontrol değil — warehouse'a bağlı veriyi okuyan/yazan her endpoint, hangi alanda olursa olsun bu kontrolden geçmeli. Dört alanın hepsinde karşılığı var:

Alan	Warehouse'a bağlı örnek
Admin	Yetkili ataması, alıcı CRM'in destek konuşmalarındaki görünürlüğü (bkz. Satış alanı detayı)
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ı

Yani @GetWarehouseContext() guard'ı, tek bir modüle özgü bir özellik değil — kimlik doğrulama (AtGuard) gibi, warehouse'a bağlı veri okuyan/yazan hemen her controller'da kullanılacak standart bir katman olarak tasarlanmalı.

Permission ile ilişkisi

İki sistem ayrı kalıyor, birlikte okunuyor:

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."

Etkilenecek modüller

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. 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ı)?

Sıradaki adım

Bu karar onaylandıktan sonra Prisma şema taslağı (Company modeli, Warehouse.companyId, yeni çalışma izni tablosu) ve mevcut veriden geçiş sırası planlanacak.