حذف یک نقش

reassignTo به صورت پارامتر کوئری می‌رود نه در بدنه. بدنه روی DELETE قانونی است و به‌طور گسترده پشتیبانی نمی‌شود (چند رانتایم و شماری از پراکسی‌ها آن را دور می‌اندازند)، و reassignTo دورانداخته‌شده از reassignToای که هرگز فرستاده نشده تشخیص‌پذیر نیست، که دقیقاً همان حالتی است که این اندپوینت ردش می‌کند به جای آنکه حدسش بزند.

همین که کسی آن نقش را داشته باشد الزامی می‌شود: بدون آن، role_in_use، یک 409 که param: "reassignTo" را با خود دارد، و این خودِ راه‌حل است. ستون زیرین ON DELETE RESTRICT است، پس مسیری نیست که در آن حذف یک نقش بی‌صدا کارهایی را که کسی می‌تواند بکند تغییر دهد.

کلیدهای API دوباره نشانه‌گذاری می‌شوند نه یتیم، و نیمهٔ ظریف ماجرا همین است. کلیدی که نقشش ناپدید شود به سقف NULL می‌افتد، و سقف null گسترده‌تر از نقشی است که همین حالا رفته، پس حذف یک نقش محدودکننده وگرنه بی‌صدا هر کلیدی را که محدود می‌کرد ارتقا می‌داد.

دو شمارش جدا هستند چون دو چیز متفاوت‌اند که باید بروید و بررسی‌شان کنید: reassigned آدم‌هایند، که متوجه می‌شوند، و keysReassigned برنامه‌هایند، که نمی‌شوند.

نقش owner را نمی‌توان حذف کرد (role_undeletable، یک 409) چون نام حسابی است که فضای کاری بر پایه‌اش کلید خورده نه شغلی که کسی انجام می‌دهد. هر نقش دیگری می‌تواند برود، Admin، Member، Viewer، Developer و Billingِ از پیش کاشته‌شده به همان اندازهٔ نقشی که کسی خودش نوشته: آن‌ها نقطهٔ شروع‌اند، و فضای کاری‌ای که هیچ یکپارچه‌سازی ندارد به سطر Developerی که اجازهٔ خلاص‌شدن از آن را ندارد نیازی ندارد. پیش از نمایش دکمه deletable را بررسی کنید؛ تنها owner پاسخ false می‌دهد.

حذف یک نقش از پیش کاشته‌شده دائمی نیست، پس متن دیالوگ را طوری ننویسید که انگار هست. GET /roles هر سطر الگویی را که نباشد دوباره می‌کارد، و حذف هیچ سنگ‌قبری برجا نمی‌گذارد، پس خواندن فهرست بعدی Developer را با یک id تازه برمی‌گرداند. تغییر نامش همان کاری است که جلوی بازگشتش را می‌گیرد (سطری که نامش عوض شده builtin خود را نگه می‌دارد و همچنان با seed تعارض دارد)، یا اینکه نقشی دیگر آن نام را بگیرد، چون seeder از سطری که نامش گرفته شده می‌گذرد.