Sınır arayüzde değil, API’de
Portal kullanıcısının kim olduğu, hangi tenant’a bağlı olduğu ve hangi firmayı görebildiği tek bir yetki kapısında çözülür: getPortalUser. Kod haritasında bu fonksiyonun 72 çağıranı var, yani yetki kararı uç noktalara dağılmış değil. Talep gönderilirken firma kimliği isteğin gövdesinden hiç okunmaz, oturumun kendi kapsamından alınır; tarayıcıda başka bir firma kimliği göndermek işe yaramaz. Seçilen cihaz o firmanın envanterinde bulunmuyorsa istek “Seçilen cihaz bu müşterinin envanterinde bulunamadı” diye reddedilir.
Dört ekran, fazlası yok
Destek grubunda Genel bakış ve Talepler, Cihazlarım grubunda envanter, Yardım grubunda Bilgi Bankası durur. Son kullanıcıya iç ekip menüsü, operasyon ekranları, satış grubu veya yönetim sekmeleri gösterilmez. Kurum modunda bile son kullanıcı, kurumun PolariStar Op’a gönder ekranını görmez.
Yanıt budanmış döner
Portala giden cihaz kaydında seri numarası, IP adresi, MAC adresi, firmware sürümü ve konum alanları boş gönderilir; kalan kısım müşterinin işine yarayan ad, tür, marka, model, durum, zimmetli kişi ve yaşam döngüsü izni varsa lisans, support ile garanti adları ve bitiş tarihleridir. Satış fiyatı, maliyet, brüt kâr, komisyon ve tedarikçi alış fiyatı portal yüzeyinde bulunmaz. İç teknik not alanı boş gönderilir, ekip listesi ise boş döner. Başka bir müşterinin kimliği, cihazı, talebi veya raporu da yok.
Talep önce gelen kutusuna düşer
Portaldan gönderilen kayıt doğrudan ticket olmaz. Kanalı Portal olarak işaretli biçimde gelen kutusuna, incelenecekler arasına düşer ve ekibe bildirim gider. Müşteriye verilen cevap da bunu açıkça söyler: destek ekibi içeri al deyince ticket oluşur, o ana kadar talep listesinde görünmez. Böylece ticket kuyruğu dışarıdan gelen her mesajla şişmez.
Dört izin, dört ayrı anahtar
Müşteri rolünün yetkisi tek bir açık-kapalı değil: talep görüntüleme, talep açma, belge görüntüleme ve yaşam döngüsü görüntüleme ayrı ayrı verilir. Lisans, support ve garanti tarihleri yalnız yaşam döngüsü izni açıksa görünür; aynı izin bitişe 90, 30 ve 7 gün kala giden bildirimlerin kime gideceğini de belirler. Talep açma izni yoksa portal salt-okuma bir pencere olarak kalır.
Çözüm onayı müşteride, kapatma ekipte
Müşteri portaldan “bende düzeldi” diyebilir; bu kaydı kapatmaz, kapanmaya hazır işaretler. Nihai kapanış, kapanış özetini yazan iç ekip yetkisindedir. Böylece müşterinin iyimser onayı ile ekibin doğrulaması tek adıma sıkıştırılmaz.
Davetli hesap, önce MFA
Müşteri kendi hesabını oluşturmaz; yönetici Kullanıcılar ekranından açar, rolü ve izinlerini seçer. Geçici bilgiler ekranda yalnız bir kez gösterilir ve güvenli bir kanaldan iletilir. Davet edilen kullanıcı ilk girişte kendi kullanıcı adını ve en az 12 karakterlik parolasını belirler; Authenticator ile MFA kurulumu tamamlanmadan portal verilerine erişemez.
Kimlik kurulumda, erişim tenant’ta
Bir portal kullanıcısının firma erişimi tenant, kullanıcı ve firma üçlüsünde tekil tutulur; oturum da bağlı olduğu tenant ile birlikte saklanır. Kullanıcı adı ise kurulum genelinde tekildir. Aynı e-posta iki ayrı PolariStar kurulumunda bulunabilir, ama bunlar aynı kimlik değildir ve birindeki yetki diğerine geçmez.
Kurum modunda müşteri denmez
Aynı motor, farklı dil. Kurum yüzeyinde portal departman kullanıcısının talep yüzeyidir: müşteri yerine departman, müşteri çözüm onayı yerine kullanıcı çözüm onayı, teknik ekip yerine BT ekibi konuşulur. Alanlar ve akış değişmez, yalnız etiketler değişir.