نقش‌ها

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] شش مدخل دارد نه سه: emails:send همراه خود emails:read را می‌آورد، threads:write همراه خود threads:read را و labels:write همراه خود labels:read را. به‌جای فرض کردن، فهرست را دوباره بخوانید.

list یک OpenEmail::Page برمی‌گرداند، list_all همهٔ نقش‌ها را در یک Array برمی‌گرداند، و iterate هر نقش را به یک بلاک yield می‌کند یا بدون بلاک یک Enumerator برمی‌گرداند. نقش به‌صورت یک Hash با کلیدهای Symbol برمی‌گردد، پس role[:permissions] فهرست را می‌خواند. create و update فیلدهای بدنه را به‌صورت کلیدواژه یا یک Hash می‌گیرند، در حالی که delete، reassign_to: را می‌گیرد، کلیدواژه‌ای snake_case که gem نامش را برای API تغییر می‌دهد.

یک نقش می‌گوید کسی چه «کاری» می‌تواند بکند. اینکه روی کدام «نشانی‌ها»، محور دیگری است و روی client.members قرار دارد: grant_address و revoke_address را در صفحهٔ «اعضا» ببینید. «می‌تواند ایمیل بفرستد» و «می‌تواند از invoices@ بفرستد» دو جملهٔ متفاوت‌اند، و فضای کاری‌ای که کارشناس پشتیبانی دومی استخدام می‌کند دومی را تغییر می‌دهد بی‌آنکه به اولی دست بزند. یک مجوز به هر دو پاسخ می‌دهد: نقشی که addresses:all دارد بدون هیچ اعطایی به همهٔ نشانی‌ها می‌رسد، از جمله نشانی‌هایی که بعداً افزوده می‌شوند، و فقط یک شخص در برنامه می‌تواند آن را روی یک نقش بگذارد.

به‌جای builtin یا نام، روی editable و deletable شاخه بزنید. هر دو تنها برای مالک false هستند، که فهرستش «هر مجوزی، از جمله مجوزهایی که سال آینده ساخته می‌شوند» است و محاسبه می‌شود نه ذخیره. هر نقش دیگری به هر دو true پاسخ می‌دهد، از جمله همان پنج نقشی که فضای کاری با آن‌ها آغاز می‌شود. نقشی که کسی نامش را عوض کرده همچنان به هر دو درست پاسخ می‌دهد، و نامش دیگر چیزی به شما نمی‌گوید.

کلیدی که برای یک نقش صادر شده، فقط «اشتراکِ» اسکوپ‌های خودش با مجوزهای آن نقش را می‌تواند انجام دهد، که در هر درخواست در مرز سیستم محاسبه می‌شود. پس باریک کردن یک نقش، دسترسی کلیدهایش را در لحظه پس می‌گیرد، بی‌آنکه هیچ‌کدام چرخانده شوند. کلیدی که نقشی ندارد اصلاً سقفی ندارد، و همین roleId برابر nil را گسترده‌ترین وضعیتی می‌کند که یک کلید می‌تواند داشته باشد، نه باریک‌ترین.

به همین دلیل هم هست که roles.delete اصرار دارد جایی برای انتقال کلیدها وجود داشته باشد. بی‌سرپرست گذاشتنشان سقفشان را یکسره برمی‌داشت و هر اعتبارنامه‌ای را که آن نقش محدودش می‌کرد بی‌صدا ارتقا می‌داد.