Bir rolü sil

reassignTo gövdede değil QUERY parametresi olarak gider. DELETE üzerinde gövde yasaldır ama yaygın biçimde desteklenmez (birkaç çalışma zamanı ve bazı proxy'ler onu düşürür) ve düşürülmüş bir reassignTo, hiç gönderilmemiş olandan ayırt edilemez; bu uç nokta da tam olarak bu durumu tahmin etmek yerine reddeder.

Rolü biri taşıdığı anda zorunlu olur: onsuz, asıl çözümü gösteren param: "reassignTo" taşıyan bir 409, role_in_use döner. Altta sütun ON DELETE RESTRICT'tir; dolayısıyla bir rolü silmenin birinin yapabileceklerini sessizce değiştirdiği bir yol yoktur.

API anahtarları sahipsiz bırakılmaz, yeniden yönlendirilir; işin ince yarısı budur. Rolü kaybolan bir anahtar NULL bir tavana düşerdi ve null bir tavan, az önce silinen rolden DAHA GENİŞTİR; dolayısıyla kısıtlayıcı bir rolü silmek, aksi hâlde onun sınırladığı her anahtarı sessizce yükseltirdi.

İki sayı ayrıdır, çünkü gidip kontrol edilecek iki farklı şeydir: reassigned fark edecek olan insanlardır, keysReassigned ise fark etmeyecek olan programlardır.

Owner rolü silinemez (role_undeletable, bir 409), çünkü birinin yaptığı bir işi değil çalışma alanının bağlı olduğu hesabı adlandırır. Diğer her rol silinebilir; hazır gelen Admin, Member, Viewer, Developer ve Billing de birinin yazdığı bir rol kadar silinebilir: bunlar bir başlangıç noktasıdır ve hiç entegrasyonu olmayan bir çalışma alanının, kurtulmasına izin verilmeyen bir Developer satırına ihtiyacı yoktur. Düğmeyi sunmadan önce deletable değerini kontrol edin; yalnızca owner false yanıtını verir.

HAZIR GELEN bir rolü silmek kalıcı değildir; bu yüzden onay penceresini öyleymiş gibi yazmayın. GET /roles eksik olan şablon satırını yeniden oluşturur ve silme geride mezar taşı bırakmaz; dolayısıyla bir sonraki liste okuması Developer'ı yeni bir id ile geri getirir. Geri gelmesini durduran şey onu yeniden adlandırmaktır (yeniden adlandırılan satır builtin değerini korur ve şablonla çakışmayı sürdürür) ya da adı başka bir rolün almasıdır, çünkü oluşturucu adı alınmış bir satırı atlar.