Access Model (Erişim Modeli)

TotalApp bir add-on ekranını kimin açabileceğine nasıl karar verir: tek gerçek kaynak (SSoT), Level-1 paket kontrolü ve Level-2 kullanıcı-rolü kontrolü — hata yerine tatlı ekranlar olarak render edilir.

Tek Gerçek Kaynak (SSoT)

Her erişim kararı tek bir yetkili yerden okunur — birbirinden ayrışabilecek kopya veya "gölge" izin dosyası yoktur:

Soru	Nereden okunur
Tenant bu add-on paketini aktifleştirdi mi?	`entitlements/entitlements.json` (tenant başına) — admin'in yazdığı aynı dosya.
Hangi roller ve capability'ler var?	`roles/roles.json` (tenant başına, tüm domainler tek depoda).
Bu kişi hangi rolleri taşıyor?	`Employee.assignedRoles[]`.
Bu kullanıcı yönetici mi?	Erişim kararlarının verildiği her yerde kullanılan paylaşımlı yönetici-durumu kontrolü.

Tek depo neden önemli

Bir yöneticinin tenant için aktifleştirdiği şey, uygulamanın erişim guard'ının okuduğu şeyle tamamen aynıdır — admin paneli ve çalışan uygulama asla çelişmez, çünkü ikisi de aynı tenant dosyalarını gösterir.

Guard — İki Katman

Her add-on ekranı (Roles, Staff ve tüm operasyonel master-data ekranları) uygulama layout'u içinde render edilen iki katmanlı bir kapıdan geçer; böylece engellenen ekran temiz bir Upsell veya Access-Denied paneli gösterir — asla boş sayfa veya 500 hatası değil.

Add-on ekranını aç → Level 1: Paket aktif mi? → Level 2: Kullanıcı yetkili mi? → Ekranı render et

Level 1 — Paket Yetkilendirme (Paywall)

Guard önce sorar: bu tenant add-on'un paketini aktifleştirmiş mi? Paket tenant'ın aktif listesinde değilse, ekran bir Upsell / Upgrade paneliyle değiştirilir:

Upsell ekranı

"[Modül] modülü aboneliğinize dahil değil. Planınızı yükseltin veya aktifleştirmek için yöneticinizle iletişime geçin." — Upgrade eylemiyle birlikte.

Bu, kullanıcının kim olduğundan bağımsız, şirket (tenant) düzeyinde bir karardır.

Level 2 — Kullanıcı Rolü (RBAC)

Paket aktifse, guard şunu sorar: bu kullanıcı modülü açabilir mi? Cevap, ekranın governance mı operasyonel master-data mı olduğuna bağlıdır:

System / Governance veri

Roles ve add-on'un Staff Master ekranı. Sadece yöneticilere açık — bunlar güvenlik, yetkilendirme ve ekip üyeliğini kontrol eder.

Operational veri

Jobsites, zones, work centers, fields, nodes, assets, kataloglar… O add-on'da rol taşıyan herkese (veya admin'e) açık. Bir saha mühendisi TenantAdmin gerekmeden bir zone ekleyebilmelidir.

Kullanıcı	Governance (Roles/Staff)	Operational
Yönetici (veya local/demo)	Girer	Girer
Domain rolü olan kullanıcı	403 Reddedildi	Girer
Domain rolü olmayan kullanıcı	403 Reddedildi	403 Reddedildi
Paket aktif değil	Paywall (Level 1)	Paywall (Level 1)

Kim yönetici sayılır?

Yönetici durumu, her yerde (guard, sidebar, My Apps) kullanılan tek bir paylaşımlı kuraldan gelir; böylece davranış her zaman tutarlıdır:

Tenant Admin veya System Admin — her zaman yönetici.
Local / standalone oturumlar (onboarding atlanmış veya henüz tenant girişi yok) — uygulamayı değerlendirirken tam kullanılabilir olsun diye yönetici sayılır. Normal (admin olmayan) role sahip gerçek tenant kullanıcıları yönetici değildir.

Governance ekranları ayrıca gizlenir

Yönetici olmayanlarda governance ekranları yalnızca açılışta engellenmez — kartları sidebar veya My Apps'te hiç render edilmez. Normal kullanıcı yalnızca işini ilgilendiren operasyonel kurulumu görür.

Sık Sorulanlar

Level 1 ile Level 2 arasındaki fark nedir?

Level 1 şirket kararıdır — tenant modülü satın aldı/aktifleştirdi mi. Level 2 kişi kararıdır — bu kullanıcı açma hakkına sahip mi. Level 1 başarısızlığı Upsell, Level 2 başarısızlığı Access Denied gösterir.

Local'de neden hiç rol atamadan her ekranı açabiliyorum?

Local/standalone oturumların henüz tenant RBAC context'i yoktur, bu yüzden admin sayılır. Gerçek tenant kullanıcısı olarak giriş yaptığınızda iki katmanlı kontroller normal işler.

Admin paneli ile uygulama farklı erişim gösterebilir mi?

Hayır. İkisi de aynı tenant entitlement ve rol dosyalarını okur/yazar — ayrışacak ayrı merkezi depo yoktur.