نقش‌ها

use OpenEmail\Constants\ApiScopes; $page = $client->roles->list();echo count($page), PHP_EOL; $role = $client->roles->get('role_8b1f4c2e9a7d3b60e5f1a2c4');echo $role['name'], PHP_EOL; $support = $client->roles->create([    'name' => 'Support',    'description' => 'Answers the shared inboxes and nothing else.',    'permissions' => [ApiScopes::EMAILS_SEND, ApiScopes::THREADS_WRITE, ApiScopes::LABELS_WRITE],]); echo implode(', ', $support['permissions']), PHP_EOL; $client->roles->update($support['id'], ['permissions' => [...$support['permissions'], ApiScopes::TEMPLATES_READ]]); $client->roles->delete($support['id'], reassignTo: $role['id']); $vocabulary = $client->roles->listPermissions();echo implode(', ', array_column($vocabulary, 'id')), PHP_EOL;

$support['permissions'] شش مدخل دارد نه سه: emails:send همراه خود emails:read را می‌آورد، threads:write همراه خود threads:read را و labels:write همراه خود labels:read را. به‌جای فرض کردن، فهرست را دوباره بخوانید.

list یک OpenEmail\Result\Page برمی‌گرداند، listAll همهٔ نقش‌ها را در یک آرایه برمی‌گرداند، و iterate یک Generator برمی‌گرداند که هر بار یک نقش را yield می‌کند. نقش به‌صورت یک آرایه با کلیدهای camelCase برمی‌گردد، پس $role['permissions'] فهرست را می‌خواند. create و update بدنه را به‌صورت یک آرایه با نام‌های API می‌گیرند، در حالی که delete، reassignTo: را به‌صورت آرگومان نام‌دار می‌گیرد.

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

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

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

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