Dzēst lomu

reassignTo ceļo kā VAICĀJUMA parametrs, nevis pieprasījuma pamattekstā. Pamatteksts uz DELETE ir likumīgs un plaši neatbalstīts (vairākas izpildvides to izmet, tāpat arī virkne starpniekserveru), un nomests reassignTo nav atšķirams no tāda, kas nekad nav nosūtīts, un tieši šo gadījumu šis galapunkts atsaka, nevis mēģina uzminēt.

Tas ir obligāts brīdī, kad lomu kāds tur: bez tā — role_in_use, 409, ar param: "reassignTo", kas arī ir īstais risinājums. Zem tā kolonna ir ON DELETE RESTRICT, tāpēc nav ceļa, kurā lomas dzēšana klusi mainītu to, ko kāds var darīt.

API atslēgas tiek pārvirzītas, nevis atstātas bāreņos, un tā ir smalkākā puse. Atslēga, kuras loma pazuda, atkristu pie NULL griestiem, bet null griesti ir PLAŠĀKI nekā tikko pazudusī loma, tāpēc ierobežojošas lomas dzēšana citādi klusi paaugstinātu katru atslēgu, ko tā ierobežoja.

Abi skaitļi ir atsevišķi, jo tās ir divas dažādas lietas, ko iet pārbaudīt: reassigned ir cilvēki, kuri pamanīs, bet keysReassigned ir programmas, kuras nepamanīs.

Īpašnieka lomu nevar izdzēst (role_undeletable, 409), jo tā nosauc kontu, uz kuru piesaistīta darbvieta, nevis darbu, ko kāds dara. Katra cita loma var aiziet — gan sākotnēji izveidotās Admin, Member, Viewer, Developer un Billing, gan tādas, ko kāds uzrakstījis pats: tās ir sākumpunkts, un darbvietai bez integrācijām nav vajadzības pēc Developer rindas, no kuras tai neļauj atbrīvoties. Pārbaudiet deletable, pirms piedāvājat pogu; ar false atbild tikai īpašnieks.

SĀKOTNĒJI IZVEIDOTAS lomas dzēšana nav neatgriezeniska, tāpēc neformulējiet dialogu tā, it kā tā būtu. GET /roles no jauna izveido jebkuru trūkstošo sagataves rindu, un dzēšana neatstāj kapakmeni, tāpēc nākamā saraksta nolasīšana atliek Developer atpakaļ ar jaunu id. Tā pārdēvēšana ir tas, kas liek tai vairs neatgriezties (pārdēvēta rinda patur savu builtin un turpina konfliktēt ar sagatavi), vai arī to izdarīs cita loma, kas paņem šo nosaukumu, jo sākotnējās aizpildes process izlaiž rindu, kuras nosaukums jau ir aizņemts.