API

Szerepkör törlése

Bármely szerepkör a tulajdonosin kívül, és csak miután megmondtad, hová kerüljenek a birtokosai.

DELETEapi.openemail.uk/roles/{id}

A valódi hívást futtatja le a munkaterületén, a saját kulcsával.

DELETE /roles/{id}

Bármely szerepkör a tulajdonosin kívül, és csak miután megmondtad, hová kerüljenek a birtokosai.

Példa

roles:write szükséges. A reassignTo azt a szerepkört nevezi meg, amelyre ennek minden tagja és minden API kulcsa átkerül.

curl

curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \  -H "$AUTH"

Válasz

{  "object": "role",  "id": "role_2b81de079c1f0a4b7e05d386",  "deleted": true,  "reassigned": 3,  "keysReassigned": 1}

A reassignTo QUERY paraméterként utazik, nem törzsben. A DELETE kérés törzse megengedett, de széles körben nem támogatott (több futtatókörnyezet és számos proxy is eldobja), és egy eldobott reassignTo megkülönböztethetetlen attól, amelyet el sem küldtek, és pontosan ezt az esetet utasítja el ez a végpont, ahelyett hogy találgatna.

Abban a pillanatban kötelező, amint bárki rendelkezik a szerepkörrel: nélküle role_in_use, 409, param: "reassignTo" értékkel, ami a tényleges javítás. Az oszlop alatta ON DELETE RESTRICT, így nincs olyan útvonal, ahol egy szerepkör törlése csendben megváltoztatná, mit tehet valaki.

Az API kulcsok átirányításra kerülnek, nem maradnak gazdátlanul, és ez a kényes fele. Egy kulcs, amelynek szerepköre eltűnt, NULL plafonra esne vissza, és a null plafon SZÉLESEBB, mint az imént törölt szerepkör, így egy korlátozó szerepkör törlése különben csendben előléptetné az összes általa korlátozott kulcsot.

A két számláló azért külön, mert két különböző dolgot kell ellenőrizni: a reassigned emberek, akik észre fogják venni, a keysReassigned programok, amelyek nem.

A tulajdonosi szerepkör nem törölhető (role_undeletable, 409), mert azt a fiókot nevezi meg, amelyhez a munkaterület kötve van, nem egy munkakört, amelyet valaki betölt. Minden más szerepkör törölhető, a kezdetben létrehozott Admin, Member, Viewer, Developer és Billing ugyanúgy, mint egy valaki által írt: ezek kiindulópontok, és egy integrációk nélküli munkaterületnek nincs szüksége egy Developer sorra, amelytől nem szabadulhat meg. Ellenőrizd a deletable értéket, mielőtt felkínálod a gombot; csak a tulajdonos ad false-t.

Egy KEZDETBEN LÉTREHOZOTT szerepkör törlése nem végleges, ezért ne úgy fogalmazd meg a párbeszédablakot, mintha az volna. A GET /roles újra létrehozza a hiányzó sablonsort, és a törlés nem hagy nyomot, így a következő listaolvasás új id-vel visszateszi a Developer szerepkört. Az átnevezés akadályozza meg a visszatérését (egy átnevezett sor megtartja a builtin értékét, és továbbra is ütközik a kezdeti sorral), vagy ha egy másik szerepkör veszi fel a nevet, mert a létrehozó kihagyja azt a sort, amelynek neve már foglalt.