Roller
`roles.list`, `list_all`, `iterate`, `get`, `create`, `update`, `delete` ve `list_permissions`.
Her yöntem
page = client.roles.listputs page.items.size role = client.roles.get("role_8b1f4c2e9a7d3b60e5f1a2c4")puts role[:name] support = client.roles.create( name: "Support", description: "Answers the shared inboxes and nothing else.", permissions: ["emails:send", "threads:write", "labels:write"]) p support[:permissions] client.roles.update(support[:id], permissions: [*support[:permissions], "templates:read"]) client.roles.delete(support[:id], reassign_to: role[:id]) vocabulary = client.roles.list_permissionsp vocabulary.map { |permission| permission[:id] }support[:permissions] üç değil, altı kayıt tutar: emails:send beraberinde emails:read, threads:write beraberinde threads:read, labels:write ise beraberinde labels:read getirir. Listeyi varsaymak yerine geri okuyun.
list bir OpenEmail::Page döndürür, list_all tüm rolleri tek bir Array içinde döndürür, iterate ise her rolü bir bloğa verir ya da blok olmadan bir Enumerator döndürür. Bir rol Symbol anahtarlı bir Hash olarak döner; bu yüzden role[:permissions] listeyi okur. create ve update gövde alanlarını anahtar kelimeler ya da tek bir Hash olarak alır; delete ise gem'in API için yeniden adlandırdığı snake_case bir anahtar kelime olan reassign_to: alır.
Bir rol, birinin ne YAPABİLECEĞİNİ söyler. Bunu hangi ADRESLER üzerinde yapabileceği diğer eksendir ve client.members üzerindedir: Üyeler sayfasındaki grant_address ve revoke_address metotlarına bakın. “Posta gönderebilir” ile “invoices@ adresiyle gönderebilir” farklı cümlelerdir ve ikinci bir destek temsilcisi işe alan bir çalışma alanı birinciye dokunmadan ikinciyi değiştirir. Tek bir izin ikisini birden yanıtlar: addresses:all iznine sahip bir rol, sonradan eklenenler dahil her adrese ayrıca yetki verilmeden ulaşır ve bu izni bir role yalnızca uygulamadaki bir kişi ekleyebilir.
Dallanmayı builtin ya da ada göre değil, editable ve deletable değerlerine göre yapın. İkisi de yalnızca sahip rolünde false'tur; onun listesi “gelecek yıl icat edilecekler dahil her izin” anlamına gelir ve saklanmaz, hesaplanır. Bir çalışma alanının başlangıçta aldığı beş rol dahil diğer her rol ikisine de true yanıtı verir. Birinin yeniden adlandırdığı bir rol ikisine de hâlâ doğru yanıt verir, adı ise artık size hiçbir şey söylemez.
update izin listesinin YERİNİ ALIR. Tek bir izin veren bir çağrı yoktur; bu yüzden rolü okuyun, kastettiğiniz kaydı değiştirin ve yukarıdaki [*support[:permissions], "templates:read"] gibi hepsini geri gönderin. Tek bir izin göndermek, rolü tam olarak o izinle ve onun gerektirdikleriyle bırakır.
Rolü biri üstlendiği anda delete için reassign_to: gerekir. Gem bunu reassignTo sorgu parametresi olarak gönderir, çünkü DELETE isteğindeki bir gövde birçok çalışma ortamı ve bir dizi proxy tarafından atılır; hiçbir şey geçirmediğinizde parametreyi göndermez. Sonuç reassigned ve keysReassigned değerlerini ayrı ayrı bildirir; böylece bir betik istediğini değil, yaptığını günlüğe kaydedebilir.
list_permissions, tam olarak bir rol kimliğinin geleceği yerde duran sabit bir yol olan GET /roles/permissions çağrısıdır. Gem bu sözcüğü get üzerinden geçirmek yerine o yolu doğrudan çağırır ve bir OpenEmail::Page değil, düz bir Array döndürür: her izin için id, label, group ve scope içeren bir Hash. scope: false, hiçbir anahtarın asla sahip olamayacağı kayıtları işaretler. Bu sözcüğü get metoduna kendiniz geçirmeyin. client.roles.get("permissions") aynı yolu oluşturur; bu yüzden aynı isteği gönderir ve bir rol ya da 404 yerine izin sözlüğünü geri alır.
Rol, bir anahtarın tavanıdır
Bir role karşı verilmiş bir anahtar, kendi kapsamlarının o rolün izinleriyle KESİŞİMİNİ yapabilir ve bu, sınırda her istek için hesaplanır. Bu yüzden bir rolü daraltmak, anahtarlarının hiçbiri döndürülmeden onların yetkilerini anında geri alır. Rolü olmayan bir anahtarın hiçbir tavanı yoktur; bu da nil bir roleId değerini bir anahtarın bulunabileceği en dar değil, en geniş durum yapar.
roles.delete'in anahtarları taşıyacak bir yer konusunda ısrar etmesinin nedeni de budur. Onları öksüz bırakmak tavanlarını tamamen kaldırır ve rolün sınırladığı her kimlik bilgisini sessizce terfi ettirir.
GET /keys/self ve GET /ping, geçerli scopes değerinin yanında roleId ve grantedScopes değerlerini bildirir. “Anahtarımda emails:send var ama insufficient_scope alıyorum” sorusu böyle yanıtlanır: grantedScopes içinde olup scopes içinde olmayan her şeyi rol almıştır. client.me.get ve client.me.ping ikisini de Hash'lerinde döndürür; bu yüzden key[:grantedScopes] - key[:scopes] rolün aldıklarını listeler. Reddin kendisi, scope_missing? değeri true olan bir OpenEmail::PermissionError'dır.
Parametreler
nameStringzorunlu- Çalışma alanının role verdiği ad: 1 ile 48 karakter arası, saklanmadan önce boşlukları kırpılır. Adlar her çalışma alanında büyük/küçük harf gözetmeksizin benzersizdir; bu yüzden ikinci bir “Support” ilkinin yanında oluşturulmaz, `OpenEmail::ConflictError` olarak fırlatılan `role_name_taken` (409) ile reddedilir.
descriptionString- Rolün ne için olduğunu söyleyen bir cümle; boşlukları kırpılır ve en fazla 240 karakterdir. Kırpıldıktan sonra boş kalan bir dize nil olarak saklanır; bu yüzden boşluklardan oluşan bir açıklama gönderdiğiniz hâliyle değil, nil olarak geri gelir. `create` üzerinde nil geçirmek yerine alanı belirtmeyin: gem nil'i olduğu gibi gönderir ve `create` onu 422 ile reddeder. `update` üzerinde `description: nil` açıklamayı temizler.
permissionsArray<String>zorunlu- Rolün verdiği izinler; `list_permissions` çağrısının sunduğu sözlükten alınır. Sözlükte olmayan bir dize sessizce atılmaz; `param` değeri `permissions` olan bir `OpenEmail::ValidationError` olarak fırlatılan, `permissions` üzerinde bir 422 verir. Böylece bir yazım hatası size bir öğleden sonraya mal olmak yerine bildirilir. Liste girişte GENİŞLETİLİR (`templates:write` yanında `templates:read` saklar), tekrarlardan arındırılır ve standart sıraya konur; bu yüzden saklanan listeyi, gönderdiğinizle aynı olduğunu varsaymak yerine yanıttan okuyun.
Yanıt
objectString- Her zaman `role`. Silme kaydı da aynı değerle, rolün `id` değeri, `deleted: true` ve iki yeniden atama sayısıyla yanıt verir; aşağıdaki diğer alanların hiçbirini içermez.
idString- Rolün kimliği, `role[:id]` olarak okunur. Bir üyenin `roleId` değerinin belirttiği, bir API anahtarının tavanının işaret ettiği ve başka bir rol silinip sahipleri bu role taşındığında `reassign_to:` değerinin aldığı kimlik budur.
nameString- Çalışma alanının role verdiği ad; boşlukları kırpılmış ve büyük/küçük harf gözetmeksizin benzersiz. Başlangıçta gelenler dahil, sahip rolü dışındaki her rol yeniden adlandırılabilir (`builtin` bir satırın nereden geldiğini söyler, nasıl adlandırılmak zorunda olduğunu değil); bu yüzden “Admin” adını rolün neye sahip olduğuna dair bir söz olarak okumayın. Başka bir rolün zaten kullandığı bir ad `role_name_taken` (409, `param` değeri `name`) verir. Sahibi yeniden adlandırmak, onun diğer her düzenlemesi gibi `role_immutable` (409) verir.
descriptionString or nil- Rolü açıklayan cümle; verilmediyse nil. Boş girdi hem oluşturmada hem güncellemede nil olarak saklanır; bu yüzden bu alan asla boş bir dize olmaz.
permissionsArray<String>- Rolün verdiği her şey; zaten genişletilmiş ve birinin yazdığı sırada değil, standart sırada. Bu sıralama önemlidir: aynı izinlere sahip iki rol eşit Array'ler tutar ve bir ayarlar ekranının Kaydet düğmesinin etkin olup olmayacağına karar vermek için onları `==` ile karşılaştırabilmesini sağlayan budur.
builtinString or nil- Bu satırın başlangıçta gelen altı rolden hangisinden geldiği: `owner`, `admin`, `member`, `viewer`, `developer` ya da `billing`; çalışma alanının kendisinin yazdığı bir rol için nil. Bir durumu değil, kökeni kaydeder: başlangıçta gelen bir rol de diğerleri gibi yeniden adlandırılır, izinleri değiştirilir ve silinir. Dallanmayı buna göre değil, `editable` ve `deletable` değerlerine göre yapın. Birinin “Admin” adını verdiği bir rolün başlangıçta gelen rol olması gerekmez; başlangıçta gelen rol de artık öyle adlandırılmıyor olabilir.
editableBoolean- `builtin != "owner"` olarak hesaplanır; bu yüzden yalnızca sahip rolünde false'tur ve o rolün her `update` çağrısı `role_immutable` (409) ile reddedilir. Bir çalışma alanının başlangıçta aldığı beş rol dahil diğer her rol tamamen (ad, açıklama ve izinler) düzenlenebilir.
deletableBoolean- `builtin != "owner"` olarak hesaplanır: yalnızca `role_undeletable` (409) ile dönen sahip rolünde false, başlangıçta gelenler dahil diğer her rolde true'dur. Bunu retten sonra değil, düğmeyi sunmadan önce denetleyin. Hâlâ birinin üstlendiği bir rol için ayrıca `reassign_to:` gerekir; aksi hâlde silme `role_in_use` (409) verir. İki ret de `OpenEmail::ConflictError` olarak fırlatılır ve onları `code` ayırt eder.
membersInteger- Bu rolü kaç kişinin üstlendiği; çalışma alanının üye satırlarından sayılır. Sahip bunların arasında değildir: üye satırı yoktur ve ona rol verilemez; bu yüzden üye listesi onu gösterse de Sahip rolü sıfır kişi bildirir.
apiKeysInteger- Bu rolün sınırladığı etkin API anahtarlarının sayısı. İptal edilmiş anahtarlar sayıma dahil edilmez, ancak bir silme işlemi role işaret eden her anahtar satırını, iptal edilmişler dahil, yeniden yönlendirir. Rol kaldırılmadan önce taşınması gereken ikinci gruptur ve kimsenin fark etmediği gruptur: anahtarlar programdır ve bir program şikâyet etmez.
createdAtString- Rol satırının yazıldığı an, bir ISO 8601 String'i olarak. Yerleşik satırlar çalışma alanı oluşturulurken değil, bir şey onlara ilk kez ihtiyaç duyduğunda (örneğin bir rol listesi okuması, bir rol oluşturma ya da API anahtarı ekranı) tembel olarak oluşturulur. Bu yüzden yerleşik bir rolün zaman damgası çalışma alanının oluşturulduğu anı değil, o ilk isteğin geldiği anı gösterir.
updatedAtString- Rolün en son değiştiği an, bir ISO 8601 String'i olarak. Bir alanı zaten sahip olduğu değere ayarlayan dahil, kabul edilen her `update` onu ilerletir.