Belgelere geç
Bilgi bankası

Roller ve izin düzeyleri

Bir rol birinin ne yapabileceğini söyler; bir adres yetkisi ise bunu neye yapabileceğini söyler.

Ayrıntılar

  • Kişi başına iki yetki ve bir şeyin olması için ikisinin de aynı yönde olması gerekir. Ayarlar → Üyeler'den belirlenen ROL, çalışma alanında ne YAPABİLECEKLERİNİ söyler: posta okumak, göndermek, şablon düzenlemek, alan adı eklemek, API anahtarı üretmek. Adres satırındaki Paylaş denetiminden belirlenen adres YETKİSİ ise bunu hangi ADRESLERE yapabileceklerini söyler; yalnızca okuma ya da okuma ve gönderme olarak. İçinde gönderme olan bir role sahip ama hiç adresi olmayan biri hiçbir yerden gönderemez; çalışma alanındaki her adresi yalnızca okuma yetkisiyle elinde tutan biri de hiçbirinden gönderemez.
  • Kimse oluşturmadan altı rol vardır ve her çalışma alanında aynı altı rol bulunur, böylece “Admin” burada da belgelerde ve API'de olduğu anlama gelir. Owner, Admin, Member ve Viewer bir merdivendir: her biri bir sonrakinin sahip olduğu her şeyi kapsar, dolayısıyla birini bir alt basamağa indirmek erişimini farklı bir dilimle değiştirmez, daraltır. Developer ve Billing bu merdivenin basamakları değildir. Developer entegrasyonlar kurar; API anahtarlarını, web kancalarını, şablonları ve göndermeyi elinde tutar ama çalışma alanının hiçbir postasını okumaz. Billing ise planı ve faturaları görür, planı ve üzerlerindeki ödeme bilgilerini değiştirebilir ve posta kutusu ayarlarını yazamadan okur. İzinleri düzenlenebilir: üyelerinin şablon yazmamasını tercih eden bir çalışma alanı onu işaretsiz bırakır ve değişiklik, o rolü AÇIKÇA elinde tutan birinin yaptığı bir sonraki istekte geçerli olur. Rolü hâlâ roller var olmadan önce verilmiş bir adres yetkisinden ima edilen biri, kendisine doğrudan bir rol verilene kadar gelen varsayılanları korur. Adları da öyle: Ops ve On-call ile çalışan bir çalışma alanı onları yeniden adlandırdığında kendini tarif etmiş olur ki mesele de budur.
  • Owner her yönden istisnadır: düzenlenemez, silinemez, atanamaz. Çalışma alanının bağlı olduğu hesabı tarif eder ve sonraki bir sürümde eklenenler dâhil her izne sahiptir; listesinin saklanmak yerine hesaplanmasının nedeni budur. Çalışma alanını başka birine devretmek bir rol değişikliği değil bir devirdir ve burada bunu yapan bir şey yoktur.
  • Bunların ötesinde bir çalışma alanı, aynı gruplanmış matristen izinleri işaretleyerek toplam 24'e kadar kendi rollerini yazar. İşaretlemek ima eder: “şablonları düzenle”, yanına “şablonları oku”yu da kaydeder, çünkü açamadığı bir şablonu düzenleyebilen bir rol, birinin kastettiği bir politika değil unuttuğu bir onay kutusudur. İnsanların ya da API anahtarlarının sahip olduğu bir rolü silmek, onların nereye taşınacağını sorar ve tahmin etmek yerine reddeder. Rolü ortadan kalkan bir anahtar hiçbir tavana sahip olmamaya düşerdi ki bu, az önce giden rolden daha geniştir.
  • Bir API anahtarı bir role karşı verilebilir ve rol ikinci bir yetki değil bir tavandır: anahtarın yapabilecekleri, kendi kapsamlarının rolün izinleriyle kesişimidir ve her istekte yeniden çözülür. Üzerinde gönderme olan ama Viewer ile sınırlandırılmış bir anahtar gönderemez ve bir rolü daraltmak, anahtarın döndürülmesine gerek kalmadan yetkiyi canlı olarak geri alır. Asistan da aynı listeye tabidir ve MCP sunucusu bir istemcinin araçlarını çağıranın izinlerinden kurar, böylece bir Viewer'ın istemcisinde hiç gönderme aracı bulunmaz; kapsam denetimli her araç da girişte yeniden kontrol eder, çünkü bir oturum liste kurulduktan sonra posta kutusu değiştirebilir.