پرش به مستندات
API

به‌روزرسانی یک نقش

همهٔ فیلدها اختیاری‌اند، و `permissions` کل فهرست را جایگزین می‌کند.

PATCHapi.openemail.uk/roles/{id}

فراخوانی واقعی را با کلید خودتان روی فضای کاری شما اجرا می‌کند.

PATCH /roles/{id}

همهٔ فیلدها اختیاری‌اند، و permissions کل فهرست را جایگزین می‌کند.

نمونه

نیازمند roles:write است. نیاوردن یک فیلد آن را دست‌نخورده می‌گذارد، و معنای PATCH همین است.

curl
curl -X PATCH "$OE/roles/role_2b81de079c1f0a4b7e05d386" -H "$AUTH" \  -H "Content-Type: application/json" \  -d '{ "permissions": ["emails:read", "threads:read", "labels:read", "contacts:read"] }'
پاسخ
{  "object": "role",  "id": "role_2b81de079c1f0a4b7e05d386",  "name": "Support",  "description": "Answers the shared inboxes and nothing else.",  "permissions": ["emails:read", "threads:read", "labels:read", "contacts:read"],  "builtin": null,  "editable": true,  "deletable": true,  "members": 3,  "apiKeys": 1,  "createdAt": "2026-08-30T10:41:02.000Z",  "updatedAt": "2026-08-30T13:02:19.000Z"}

permissions کل فهرست را جایگزین می‌کند. فراخوانی‌ای برای اعطای یکی وجود ندارد و نخواهد داشت: این فهرست است که بازبینی می‌شود، و patch نشانی‌شده با ایندکس همان لحظه که دو تب باز باشد یک به‌روزرسانی گم‌شده است. نقش را بخوانید، مدخلی را که منظورتان بوده تغییر دهید، همه را پس بفرستید. فرستادن یک مجوز، مجوزی نمی‌افزاید. نقش را با دقیقاً همان یکی به‌علاوهٔ هر چه مستلزمش است رها می‌کند.

description علاوه بر اختیاری‌بودن nullable هم هست، و همهٔ نکتهٔ یک patch همین تفاوت است: نیاوردنش جملهٔ ذخیره‌شده را نگه می‌دارد، فرستادن null پاکش می‌کند. بدون nullable راهی برای حذف یک توضیح نبود جز جایگزین‌کردنش با یک فاصله.

owner تنها نقشی است که یک PATCH ردش می‌کند، و هر فیلدی از آن را رد می‌کند: role_immutable، یک 409 با param: "roleId". هر نقش دیگری نام تازه را به همان آسانی فهرست مجوز تازه می‌پذیرد، از جمله نقش‌های کاشته‌شده. builtin ثبت می‌کند یک نقش از کجا آمده، نه اینکه چه کاری می‌توان با آن کرد. نامی که نقشی دیگر پیش‌تر دارد به جایش role_name_taken است، یک 409 با param: "name".

این ویرایش روی درخواست بعدی هر کسی که آن نقش را دارد می‌نشیند، از جمله کلیدهای API، چون سقف به ازای هر درخواست حل می‌شود نه اینکه کش شود. پس تنگ‌کردن یک نقش لغو دسترسی زنده‌ای است که بدون چرخاندن کلیدهای زیرش اثر می‌کند. گسترده‌کردنش هم زنده است، و همان نیمه‌ای است که به‌یادسپردنش می‌ارزد.